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.
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.
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.
In various locations,
BillyMathContext
andBillyMathContext.SCALE
are used when performaing calculations onBIgDecimal
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
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