Hi Nan,
You can create many tax classes (several for every area) if one area
is bind to the product (us-high us-low uk-high uk-low uk-...) and
create a model for your tax processor with the necessary data. The
area part of the taxclass can be eventually automatically filled by a
custom Widget for Admin and pre_save signal of your product.
You
What is "Product Area"? (You sell houses?) It does ot matter. I think
it is not much typical requirement. How to say, that something is
unused in a toolbox by users?
More desiderable for Satchmo community I consider first to simplify:
- create a class BaseProcessor(object):
# which defines relations between derived methods and the method
by_price which is the only by_* which shold be defined by every
descendant class Processor(BaseProcessor)
def by_price(self, taxclass, price):
raise NotImplementedError()
# This can simplify the code without breaking the compatibility
and it would be easier to create a new tax module.
One class can be easier documented. Descendants need not it. You are
right, the name by_price is not inuitive
- a documented example module with more functionality than 'no' or
'percent' and simpler than 'area' or 'us_sst', with less database
queries.
'by_product' can be defined by 'by_price', but not viceversa.
The Product is a complicated model with submodules. Method
taxer.by_price is called also from productvariation_details. With
taxer.by_product it would be not as easy to say that it can not cause
any recursion, memory cycle etc. Simpler is often better.
Hynek
On Mar 15, 4:53 pm, Nan <[email protected]> wrote:
> Hi folks...
>
> I'm building a custom tax processor for a store where each product has
> both an Area and a Tax Class, and tax on that product depends on both
> (rather than on the store's or the purchaser's location).
>
> The trouble is that a lot of tax calculations in Satchmo seem to
> depend on the by_price method, which passes in the Tax Class for the
> product, but not the product object itself -- so the processor has no
> way to determine the product's Area; most tax calculations will
> therefore fail.
>
> The by_product method seems to exist on most tax processors but
> remains essentially unused[1]. I'm considering patching Satchmo to
> use by_product in most places where by_price is used to calculate tax
> specifically on a product. Would there be any broader community
> interest in such a patch?
>
> Thanks,
> -Nan
>
> [1]http://groups.google.com/group/satchmo-users/browse_thread/thread/6bb...
--
You received this message because you are subscribed to the Google Groups
"Satchmo users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/satchmo-users?hl=en.
