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

Scale and precision inconsistencies in some locations #495

Open
thenmaster opened this issue Dec 5, 2023 · 0 comments
Open

Scale and precision inconsistencies in some locations #495

thenmaster opened this issue Dec 5, 2023 · 0 comments
Labels

Comments

@thenmaster
Copy link
Member

In various locations, BillyMathContext and BillyMathContext.SCALE are used when performaing calculations on BIgDecimal instances that represent the amount of an entry/invoice/etc. with or without taxes to determine other values relevant for the billing process(ex: calculating the tax amount when the amount given for an entry already includes the tax value). However there are some inconsistencies that can lead to some problems in runtime.

Most of these problems are independent from each other so they can/should be addressed separately to reduce complexity and
facilitate testing.

  • com.premiumminds.billy.portugal.services.export.qrcode.TupleContextTypeAmount#taxToTupleContextTypeAmount
    • When calculating the tax amount on a percentage tax, the following operation is done
taxAmount = amountWithoutTaxes.multiply(taxValue.divide(new BigDecimal(100)));

which due to lack of a math context when perfoming the division can throw an exception if the result cannot be represented(ex: non-terminating decimal expansion). In reality this most likely will never happen but best be sure. Sidenote: the BigDecimal(100) is being created by passing the number 100 and not the string "100" as is done in other cases. Should not be a problem but making it consistent with the rest wouldn't hurt.

  • com.premiumminds.billy.core.services.builders.impl.GenericInvoiceBuilderImpl#validateValues
    • The comparison of the (amount with taxes - tax amount) and amount without taxes is done after settting the scale of both values to 7. This might not be accurate since we were allowing for a precision of 34 digits when performing calculations and this does not necessarily mean that the scale used is 7.
@thenmaster thenmaster added the bug label Dec 5, 2023
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

1 participant