[16.0] sale_fixed_discount rounding issues

[CRogos]

In standard Odoo you cannot enter a discount of 70.000 on a price of 84.000 so that the subtotal is 14.000. It alsways turns into 14.002,80 because of rounding issues:

When we install sale_fixed_discount you can enter a discount of exactly 70.000 and everything in the SO looks good

Neverthelss as soon as you generate an invoice from this SO, you get this, which ends up in a wrong TAX calculation:

Any suggestions who to fix this? Should fixed discount overwrite the IsStored and always recompute the %(Disc) value?

@PieterPaulussen do you have any suggestion. This problem is new to v16

[PieterPaulussen]

@CRogos Not entirely sure this should be posted here though, should this bug report not be created in 'OCA/account-invoicing' instead?

Anyways, I specifically accounted for this behaviour when I redesigned the module. I also mention it specifically here that I need to account for the tax rounding in the core.
My original design was that the core discount field in Odoo was always the leading source of the computation.
Are you certain nothing else is affecting the calculation?

[CRogos]

Yes, 'OCA/account-invoicing' would have been better, I guess.

I am pretty sure this is the issue because 14000 * 15% = 2100 and 14002,8 * 15% = 2100,42 which are the exact numbers above.
And when you have a look into the database, the discount value in SaleOrder and Invoice is 83,33% and 84000 * 83,33% is 14002,8.

I totally agree that it would be the best that % disc should be the leading field. Nevertheless this should not lead to invoices with wrong taxes? Maybe we also could build an new module which is named advanced_discount_precision which fixes the bug in the core module? Maybe by adding a configurable amount on digits on the discount field while still printing only max 2 digits in the UI?

Changing the decimal accuracy on discount solves the issue. Nevertheless I think we should change the module in a way, that you cannot enter values to the fixed discount field, that do not fit to the used discount precision?

Maybe we could also add a warning that the value has been changed to x because of discount precision. Than the user is informed, that it cannot enter certain values before changing the precision.

Is there a module which extends decimal.precision by something like "printed precision" so that the web/pdf UI stays the same even though we change digits to 6 or more?

[PNurm]

We also have same rounding issues on invoice with these modules after the "refactoring" done between 14 and 16 versions. It's more of a bug though.

Steps to reproduce:

1. Create sale order with single order line: 870€, discount 70€
   

2. Create invoice from the sale order, tax is off by 1 cent, causing total amount to be 799,99€.
   

However when setting discount_fixed to zero after, and then back its fixed. There's a bug with creation of the invoice.