Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[16.0] sale_fixed_discount rounding issues #3115

Open
CRogos opened this issue May 2, 2024 · 2 comments
Open

[16.0] sale_fixed_discount rounding issues #3115

CRogos opened this issue May 2, 2024 · 2 comments
Labels

Comments

@CRogos
Copy link
Contributor

CRogos commented May 2, 2024

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:

image

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

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

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

@CRogos CRogos added the bug label May 2, 2024
@PieterPaulussen
Copy link
Contributor

@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
Copy link
Contributor Author

CRogos commented May 2, 2024

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?
image

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants