On 29 Dec 18:06, Albert Cervera i Areny wrote: > 2014-12-29 16:52 GMT+01:00 Cédric Krier <cedric.kr...@b2ck.com>: > > 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 don't see any explanation why my proposal is wrong. > 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. There will not be an infinite number of digits, we use Decimal. With the principle that almost (at least in Tryton DB) all currencies have 2 digits and that quantity is limited to 16 numbers, normally with a unit price with 18 digits it should managed all the cases. But as I explained, it can be reduced depending of the business and the usual quantity sold. > In the case of taxes included, tax calculation should always be at > line level (as recently added to tryton). This can be checked if the module is installed. > 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. I think this design is too much complicated and will lead to too much mess and bugs. It was the design of OpenERP (that I made) and it was a complete disaster. > 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). I don't see any problem here. Of course if the company works with tax included price, it has to deal with the different possible tax rules. But the idea is to have a price list for customer with which you want to work with price tax excluded and a price list for customer with price included. > 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. There will be no restriction to add a tax clause on the price list but that will be customization. > 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. No, I think it is a wrong idea. The combination of taxes that a sale line could have is too much big to be able to handle this way. When people purchase products with price tax included they don't care about the taxes applied because it is part of the concept of tax included. -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
