> 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.
With products in almost every US state, we'd need a Tax Class for every product class in every state PLUS a Tax Rate for each Tax Class for each state, AFAICT. It's just too confusing, when the tax processor itself should be able to simply select the Tax Rate based on an attribute of the product. Then we can have just a few tax classes (e.g. virtual goods, clothing, other), and a tax rate for each of those for each state. > 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? Yes, it's rare, but real estate is probably similar. We sell tourism products, and have been advised that each product needs to be taxed according to the location it relates to. > 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 trouble is that (a) by_price doesn't receive any data about the product other than its tax class and a price; and (b) calls to by_price are *hard-coded* into a lot of places in Satchmo where by_product would be equally appropriate. I need a way to pass the product to the tax processor, and the only way for me to do that is to call by_product instead of by_price. Working around this without patching Satchmo itself would basically mean copy-pasting a quarter of satchmo's code, replacing single method calls in a couple dozen places, and then finding awkward ways to hook it in. In the tax processors distributed with Satchmo, by_product simply calculates the price and then calls by_price. So patching Satchmo to change those calls shouldn't mean any disruption to people using those processors. -- 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.
