[
https://issues.apache.org/jira/browse/FINERACT-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Wargulak updated FINERACT-2955:
-------------------------------------
Description:
When a transaction partly pays a loan charge that has a tax group,
LoanJournalEntryPosterImpl (convertToAccountingBridgeTransaction) prorates each
tax component as tax × paidAmount / chargeAmount using
MoneyHelper.getMathContext(). That MathContext limits precision (significant
digits), not scale, and the result is never rounded to the currency's decimal
places. The value goes unchanged into acc_gl_journal_entry.amount, so the
tax-liability line and the net fee/penalty income line carry sub-unit amounts.
Example, 2-decimal currency: a fee of 1000.00 with a 23% tax-inclusive group
(tax 186.991870). A repayment of 400.00 towards it posts 74.796748 to tax
liability and 325.203252 to fee income. A repayment of 0.01 posts a tax line of
0.001870, although the rounded tax is 0.00.
The same split feeds cash-based repayments, accrual-based repayments with
income from fees, and accrual / accrual-adjustment transactions. All other
portions of a loan journal entry come from Money and are already at the
currency's scale, so this is the only place sub-unit amounts reach the GL.
Proposed fix: compute the tax cumulatively over the charge's earlier
transactions of the same kind (payments, or accruals), round that cumulative
figure to the currency's scale with the configured rounding mode, and post the
difference from what those earlier transactions already posted. Every line is
then a valid currency amount, and the lines of a fully paid charge sum exactly
to its tax rounded to the currency's scale. Rounding each line on its own would
let the total drift by a minor unit over several partial payments.
Introduced with FINERACT-1289. Still present on develop.
The first version of the FINERACT-1289 change divided at scale 6 with
HALF_EVEN; review asked for the configured rounding instead, and the switch to
MoneyHelper.getMathContext() also dropped the scale, so nothing now rounds the
prorated tax at all. The 6-decimal tax stored on the loan charge is unchanged
by this proposal; only the journal lines are rounded, with the configured
rounding mode.
was:
When a transaction partly pays a loan charge that has a tax group,
LoanJournalEntryPosterImpl (convertToAccountingBridgeTransaction) prorates each
tax component as tax × paidAmount / chargeAmount using
MoneyHelper.getMathContext(). That MathContext limits precision (significant
digits), not scale, and the result is never rounded to the currency's decimal
places. The value goes unchanged into acc_gl_journal_entry.amount, so the
tax-liability line and the net fee/penalty income line carry sub-unit amounts.
Example, 2-decimal currency: a fee of 1000.00 with a 23% tax-inclusive group
(tax 186.991870). A repayment of 400.00 towards it posts 74.796748 to tax
liability and 325.203252 to fee income. A repayment of 0.01 posts a tax line of
0.001870, although the rounded tax is 0.00.
The same split feeds cash-based repayments, accrual-based repayments with
income from fees, and accrual / accrual-adjustment transactions. All other
portions of a loan journal entry come from Money and are already at the
currency's scale, so this is the only place sub-unit amounts reach the GL.
Proposed fix: compute the tax cumulatively over the charge's earlier
transactions of the same kind (payments, or accruals), round that cumulative
figure to the currency's scale with the configured rounding mode, and post the
difference from what those earlier transactions already posted. Every line is
then a valid currency amount, and the lines of a fully paid charge sum exactly
to its tax rounded to the currency's scale. Rounding each line on its own would
let the total drift by a minor unit over several partial payments.
Introduced with FINERACT-1289. Still present on develop.
> Prorated tax on a partially paid loan charge is posted to the GL without
> rounding to the currency's scale
> ---------------------------------------------------------------------------------------------------------
>
> Key: FINERACT-2955
> URL: https://issues.apache.org/jira/browse/FINERACT-2955
> Project: Apache Fineract
> Issue Type: Bug
> Reporter: Piotr Wargulak
> Priority: Major
>
> When a transaction partly pays a loan charge that has a tax group,
> LoanJournalEntryPosterImpl (convertToAccountingBridgeTransaction) prorates
> each tax component as tax × paidAmount / chargeAmount using
> MoneyHelper.getMathContext(). That MathContext limits precision (significant
> digits), not scale, and the result is never rounded to the currency's decimal
> places. The value goes unchanged into acc_gl_journal_entry.amount, so the
> tax-liability line and the net fee/penalty income line carry sub-unit amounts.
> Example, 2-decimal currency: a fee of 1000.00 with a 23% tax-inclusive group
> (tax 186.991870). A repayment of 400.00 towards it posts 74.796748 to tax
> liability and 325.203252 to fee income. A repayment of 0.01 posts a tax line
> of 0.001870, although the rounded tax is 0.00.
> The same split feeds cash-based repayments, accrual-based repayments with
> income from fees, and accrual / accrual-adjustment transactions. All other
> portions of a loan journal entry come from Money and are already at the
> currency's scale, so this is the only place sub-unit amounts reach the GL.
> Proposed fix: compute the tax cumulatively over the charge's earlier
> transactions of the same kind (payments, or accruals), round that cumulative
> figure to the currency's scale with the configured rounding mode, and post
> the difference from what those earlier transactions already posted. Every
> line is then a valid currency amount, and the lines of a fully paid charge
> sum exactly to its tax rounded to the currency's scale. Rounding each line on
> its own would let the total drift by a minor unit over several partial
> payments.
> Introduced with FINERACT-1289. Still present on develop.
> The first version of the FINERACT-1289 change divided at scale 6 with
> HALF_EVEN; review asked for the configured rounding instead, and the switch
> to MoneyHelper.getMathContext() also dropped the scale, so nothing now rounds
> the prorated tax at all. The 6-decimal tax stored on the loan charge is
> unchanged by this proposal; only the journal lines are rounded, with the
> configured rounding mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
