Repository navigation
Bug 653927: [29.x] [SAF-T NO] TotalDebit and TotalCredit differ from exported amounts after reversals - #12899
Conversation
Backport-Source: github:#12696 Backport-Target: BCApps:releases/29.x Backport-Path-Set: 4da2ac75904103ff1aa49537aac384ce27d1fb12915693703cff6125c1dab0a2
Good Sense Reviewer - Round 1Recommendation: AcceptWhat this PR doesThis change recalculates SAF-T 1.30 debit and credit control totals from the sign of each selected G/L entry amount. It keeps SAF-T 1.20 behavior unchanged and repeats the full selection totals in every split file. The new aggregate uses the same posting-date and source-code filters as the line exporter. Positive amounts are summed as debits, while negative amounts are converted to positive credit totals, which matches the XML line classification. The regression tests cover reversals, negative entries, multiple and blank source codes, period limits, empty selections, foreign currency, and monthly and daily splits. Problem-solution fitFit: Strong The change directly fixes the reported mismatch between the control totals and the exported line amounts. Its scope is limited to SAF-T 1.30, where the XML uses sign-based debit and credit classification. SuggestionsNone. Risk assessment and necessityRisk: This affects financial audit-file control totals, so a wrong sign or filter could produce a non-compliant export. The implementation reuses the exporter's source-code selection, uses a read-only SQL aggregate, changes no public API or event contract, and has focused regression coverage. Necessity: Without this change, reversals and other negative entries can make SAF-T 1.30 control totals disagree with the amounts in the exported files. The fix is targeted and preserves the existing SAF-T 1.20 calculation.
|
a94b5e8
into
releases/29.x
Backport of #12696 for AB#653927