2014-12-29 16:52 GMT+01:00 Cédric Krier <[email protected]>: > Hi, > > I'm trying to solve a problem for price with tax included. > Generally, when companies work this way they store the price with tax > included on the product for example (could be the list price field). > So the problem is how to make it works on the current sale design. > > Here is my idea, we could create a new module > sale_price_list_tax_included (name to be reworked) which will add a flag > on the price list to announce it will return a unit price that should be > considered as tax included. > On the sale, when such price list is used, we reverse compute the unit > price without tax using the tax on the line (for which the tax rule has > been applied). > Normally, if we have enough decimal on the unit price, it should always > be possible to find such unit price. The number of decimal needed will > depend on the rate of the taxes of course and the quantity sold. > So if we change tryton's module to use a configuration parameter for the > digits (instead of the hard coded 4), a good value could be defined for > each company according to their use case. > > So what do you think about such module?
I don't think it is the right approach and I think it is better to do the expected operations: When taxes are not included one must make this operation: tax = round(base * tax_percent) total = base + tax And with taxes included one must make this one: base = round(total - (total / tax_percent)) tax = total - base I think the right way to go about this is to add a parameter to sales and invoices that determines how taxes are calculated. Working with taxes included one may need to print the unit price without taxes which cannot be printed with an infinite number of digits in an invoice, for example. In the case of taxes included, tax calculation should always be at line level (as recently added to tryton). So for me the first step is adapt the tax engine to be able to work both ways and then think of how a price list can be implemented with taxes included. Because for me, one can make a real mess if assigns a price_list with price included to two parties with different tax rules because that's most probably something he did not want to do (ok, we can say it's up to the user, but seems something stronger should be thought to avoid such cases). One possibility would be to add the tax (or taxes) to the matching part of the price list and only apply that price list line when taxes of the sale line are the same. So in this proposal, instead of adding a flag to the pricelist we could add a new field "tax_included_formula" that returns the price to be used when the sale is working with taxes included. -- Albert Cervera i Areny Tel. 93 553 18 03 @albertnan www.NaN-tic.com
