odoo
[IMP] account,*: Fully manage the round globally
The creation of tax lines is made with 2 duplicated mechanisms: _get_generation_dict_from_base_line is the method saying the granularity of your tax lines. This method is used by everyone using the compute_taxes method. Since V16, a custom similar mechanism has been duplicated on invoices in _compute_all_tax in account_move_line.py => We should have only one mechanism.
Then, another problem is the whole logic to compute the round_globally is wrong.
Instead of:
- compute the tax values per grouping key per tax repartition line per line
- aggregate the amounts
- round
we should:
- compute the tax values per tax and per line
- round
- dispatch the amounts to the repartition lines.
Let's take some examples: Suppose 3 lines of: price_unit = 33.33, tax = 10% price_unit = 33.33, tax = 10% price_unit = 33.34, tax = 10%
Using round_per_line, each line will compute 3.33 as tax so a total of 9.99. Using round_globally, each line will respectively compute a tax amount of 3.333, 3.333, 3.334 so a total of 10.0. However, depending the current grouping key to compute the tax lines (each one corresponding to a repartition line), the computation could be different. Suppose the analytic checkbox is ticked on the tax and the base lines are: price_unit = 33.33, tax = 10%, analytic_distribution = 100% on account_A price_unit = 33.33, tax = 10%, analytic_distribution = 100% on account_B price_unit = 33.34, tax = 10%, analytic_distribution = 100% on account_C
In this specific case, the total of taxes will be 3 x 3.33 = 9.99 because it will generate 3 tax lines, one for each analytic distribution.
Another problem is when dealing with price included taxes. Suppose two lines: price_unit = 21.53, tax = 21% incl price_unit = 21.53, tax = 21% incl
Each line will compute a tax excluded amount of round(21.53 / 1.21) = 17.79 So the total untaxed amount is computed as 17.79 x 2 = 35.58. However, since the tax is included in price, the untaxed amount should be round(21.53 * 2 / 1.21) = 35.59 It means there is 0.01 that need to be distributed on invoice's journal items.
task-id: 3725705
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Upgrade exception #384 added.
Waiting the forward-port of this pr, the exception will be applied on all builds, and create an inconsistent state for migrations. Please forward port this asap up to master without change. Exception should be forward-ported before the end of the week.
PRs adding fields/models should be merged at the beginning of the week and all the forward ports should be merged in the same week.
If you need to apply any change before it reaches master, please notify runbot team.
Details:
field:account.tax.has_negative_factor
cc @KangOl @nseinlet @aj-fuentes
@smetl @d-fence linked pull request(s) odoo/enterprise#69952 not ready. Linked PRs are not staged until all of them are ready.
@smetl @d-fence staging failed: ci/runbot (view more at https://runbot.odoo.com/runbot/build/68927943)
