[29.0] BE's PEPPOL "escompte" compensation - #11037
Conversation
GitHub Actions
Inactive
075096c to
e6ed954
Compare
Good Sense Reviewer - Round 1Recommendation: Request ChangesWhat this PR doesThe change adds a Belgian escompte compensation line so VAT stays on the discounted base while the payable amount remains whole. The main sales-invoice path and test follow that model, but the implementation does not safely distinguish the synthetic Exempt subtotal from normal Exempt VAT, and one analogous deprecated BaseApp export path is not updated. Problem-solution fitFit: Partial The reported sales-invoice case is mostly addressed by the synthetic tax subtotal, charge total, and test coverage. The fix still leaves mixed Exempt VAT documents and the matching BaseApp credit memo flow with incorrect export behavior. SuggestionsS1 (🔴 High): Exemption reason applies to normal exempt lines S2 (🔴 High): BaseApp exemption reason applies too broadly S3 (🔴 High): BaseApp credit memos miss compensation Risk assessment and necessityRisk: Belgian PEPPOL tax subtotals, exemption reasons, and payable totals are financial and compliance-sensitive export data. The default interface method limits compatibility risk, but wrong Exempt reasons or reduced credit memo totals can produce incorrect XML. Necessity: The compensation is needed for Belgian escompte exports. The scope should also preserve correct normal Exempt VAT output and keep the analogous BaseApp export paths consistent.
|
|
…hether a line is a escompte compensation
Good Sense Reviewer - Round 2Recommendation: Request ChangesWhat this PR doesThe new commits pass the current VAT amount line into the tax-exemption reason lookup, so normal Exempt VAT subtotals and the synthetic escompte subtotal can be told apart. They also add invoice tests for mixed Exempt VAT and no-discount cases, and align the exemption-reason lookup in the deprecated BaseApp export code. The main app invoice and credit memo paths use the shared finalization hook, but the deprecated BaseApp credit memo XMLport still builds its own VAT buffer and still does not add the payment-discount compensation line. Status of previous suggestions
New observations (commits since round 1)None - the new commits address earlier exemption-reason issues and add tests. The remaining blocker is carried forward from round 1. Risk assessment and necessityRisk: The changed area writes Belgian PEPPOL tax subtotals, exemption reasons, AllowanceCharge lines, and payable totals. That is financial and compliance-sensitive export data. The new exemption-reason overload is additive, but the deprecated BaseApp credit memo path can still export reduced payable totals because it never calls Necessity: The compensation remains needed so Belgian payment discounts keep VAT on the discounted base while the amount payable stays whole. The scope is closer now, but it still needs the same compensation step in the deprecated BaseApp credit memo export path to keep invoice and credit memo behavior aligned.
|
3 participants
Backport of #11023 to
releases/29.0.In BE, there's this weird tradition that when you have a payment terms discount, the VAT is calculated with that discount as taxable base, even when the full amount (pre-discount) is shown in the total.
In our standard PEPPOL, payment discounts are added as AllowanceCharge, which is what is desired, but the totals then become less, which is not what they do in BE.
A previous attempt to fix this was to remove the AllowanceCharge for the VAT, which was incorrect, since the totals would now be mismatching. More over, the confusion of the recent move to this app from BaseApp, and branching of 28.x when the fix landed, made the fix unavailable for 28.4 (to be dealt in other PRs).
What the PR does
I didn't add BaseApp's test, since that code is going away anyway, in favor of the new place in E-Documents.
Fixes AB#649017