We’ve found some special case regarding tax rules with tax included. The fact is that the customer has a tax rule that adds a non direct tax (recargo de equivalencia or IRPF). So the sale line have two taxes:
One for the normal VAT amount (from the product)
Another for the Recargo (added from the tax rule)
As tryton reads both taxes, the resulting prices is lower than with a single tax (customer without tax rules).
I will expect that the same price list returns the same unit_price for the product no mather what tax rule has the party. An with this amount we compute the taxes special for the customer. The reasoning here is that normally you only take in account the product taxes when desiging the price lists (as you can not control other taxes).
For example if you have a tax rate of 10%, and a public list price of 11 (including taxes) the current behaviour is the following:
Without tax rule, the unit_price is 10.0
With an introcomunitary tax rule (tax is replaced to 0%), the unit_price is 11.0
With additional tax of 5%: the unit_price is 9.6552 (11/ 1.15)
I will expect that in all cases the unit_price is 10.0, and the correct taxes for the customer are applied.
I’ve discusses this case with some Spain Integrators and we all agreed that this behaviour is what is expected in Spain.
But that’s against the principal design of the module which is that the price list give the final price the customer will pay.
If you always reverse compute with the same taxes, there is no point to make the computation as it will always be the same result. So use a price list tax excluded so you will always have the same unit price.
I can see one case with the Recargo. As it is not really a tax, I could understand that such customer would expect that the price tax included would be without it.
This could be solved by defining that such tax should be removed from the taxes context in _get_context_sale_price. This may be done using a flag on the tax or by adding a list of tax to exclude on the price list.