Repository navigation
[Master][all-e]Purchase Invoice Statistics Non-Deductible VAT Amount does not match VAT Entries and G/L Entries when Non-Deductible VAT is enabled. - #13482
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Good Sense Reviewer - Round 1Recommendation: AcceptWhat this PR doesPreserves allocated non-deductible VAT for manual entries generated by purchase posting, while retaining automatic journal recalculation. This prevents split invoice entries from being rounded independently a second time. Purch.-Post already distributes non-deductible VAT using rounding remainders, and Invoice Posting Buffer copies those amounts into manual VAT entries. The new guard preserves them through VAT/G/L posting. The split-line regression tests would produce 0.04 instead of 0.03 under the old condition; they assert statistics, VAT totals, G/L amounts, and balance. Coverage includes VAT-inclusive prices and credit memos, plus the retained automatic journal calculation. Problem-solution fitFit: Strong The reported mismatch comes from overwriting document-level rounding allocations during invoice posting. The guard removes that second LCY calculation for document-generated manual VAT entries without changing the calculation used by automatic journals. SuggestionsNone. Risk assessment and necessityRisk: VAT and G/L posting are financially sensitive, but the production change is limited to the existing normal-VAT invoice recalculation branch. Credit memos, reverse-charge VAT, full VAT, and additional-currency calculations retain their previous control flow; public signatures and events are unchanged. Sales and Service use the same manual-entry buffer copy, but their standard posting flows do not populate purchase non-deductible VAT allocations. The added tests cover the changed purchase path and the retained automatic-entry branch. Necessity: Without this change, splitting purchase invoice posting entries can overstate non-deductible VAT and understate deductible VAT, leaving statistics inconsistent with VAT and G/L entries. Avoiding split entries is only a possible workaround where line-description and dimension requirements permit it. Preserving the existing document allocations is a narrow correction with no schema or upgrade changes.
|
…Bug-657371-Main-PurchaseInvoiceStatisticsNonDeductibleVATAmountdoesnot
Good Sense Reviewer - Round 2Recommendation: AcceptWhat this PR doesPreserves allocated non-deductible VAT for manual purchase-posting entries instead of rounding each invoice posting line again. Round 2 changes only the regression tests: the handler captures the non-deductible amount displayed by Statistics, and the tests compare both VAT and G/L totals against that amount. This is a suitable oracle for the reported mismatch, not a comparison of the posted result with itself. The tests retain a fixed total VAT assertion of 0.06, an independent 0.03 non-deductible assertion for prices excluding VAT, two-entry counts, deductible VAT assertions, and the G/L balance check. The unchanged automatic-journal test still checks exact recalculated amounts. Problem-solution fitFit: Strong The reported problem is a mismatch between purchase Statistics and posted VAT/G/L totals after line splitting. The production guard preserves the LCY allocations already copied from the invoice posting buffer for manual entries, while automatic normal-VAT invoices retain their previous recalculation. The revised tests directly compare Statistics with both posted totals while allowing the prices-including-VAT expectation to follow the displayed allocation. Status of previous suggestionsNo previous suggestions. New observations (commits since round 1)None. No new issue was found in the PR-owned changes since the previous round. Risk assessment and necessityRisk: VAT and G/L posting are financially sensitive, but the only new PR-owned commit changes test expectations and variable-storage handling. The full production fix adds one VAT-posting-mode guard without changing signatures, schema, credit-memo branching, or additional-currency control flow. The captured Statistics value is dequeued before posting and the queue is checked empty; the automatic-journal test retains exact amount assertions. Necessity: Without the production change, separately rounded invoice posting lines can overstate non-deductible VAT and leave Statistics inconsistent with VAT and G/L entries. Avoiding split entries is only a possible workaround when dimension and description requirements permit it. The Round 2 adjustment keeps regression coverage focused on agreement with Statistics without imposing the same fixed VAT-inclusive allocation on every localization.
|
Bug 657371: [Master][all-e]Purchase Invoice Statistics Non-Deductible VAT Amount does not match VAT Entries and G/L Entries when Non-Deductible VAT is enabled.
Fixes AB#657371
Issue :- Purchase Invoice Statistics shows a Non-Deductible VAT Amount of 286.35, while Preview Posting shows 286.76 in VAT Entries and G/L Entries—a difference of 0.41, depending on how lines are split.
Cause :- Purchase posting allocates non-deductible VAT across document lines using rounding remainders. An invoice-specific calculation then overwrites these allocations by recalculating and rounding non-deductible VAT independently for each posting line. Splitting entries by dimensions or line descriptions therefore changes the total. Credit memos bypass this recalculation.
Solution :- Preserve the document’s allocated non-deductible VAT amounts for manual VAT entries generated by purchase posting. Restrict the recalculation to automatic journal VAT entries, retaining existing journal behavior. Regression tests were added for purchase invoices, prices including VAT, credit memos, and automatic journal calculations.