Repository navigation
[Master]-Non-Deductible Reverse-Charge VAT Correction Is Posted to Purchase VAT Account Instead of Payment Discount Account. - #12474
Conversation
|
The new parameter is named Suggested fix (apply manually — could not be anchored as a one-click suggestion): local procedure GetPaymentDiscountVATExclNonDedVATAccountNo(VATEntry2: Record "VAT Entry"; NonDedVATAmount: Decimal): Code[20]Line mapping was unavailable, so this was posted as an issue comment. 👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.48.6 |
<!-- Thanks for contributing to BCApps! A few things before you hit "Create pull request": - Your PR must link to an approved issue. New here? See CONTRIBUTING.md. - You must have built and run your change yourself. CI is a safety net, not a substitute. - If you used AI or an agent to write this PR, you are still the author. Read the diff, build it, and try it before requesting review. Contributing guide: https://github.com/microsoft/BCApps/blob/main/CONTRIBUTING.md Local dev environment: https://github.com/microsoft/BCApps/blob/main/LOCAL_DEV_ENV.md --> ## What & why <!-- A few sentences: what does this change do, and what problem does it solve? --> ## Linked work <!-- Required: link an approved GitHub issue using "Fixes #<number>". Microsoft contributors: also link the ADO work item with "AB#<number>" if you have one. --> Fixes # ## How I validated this - [ ] I read the full diff and it contains only changes I intended. - [ ] I built the affected app(s) locally with no new analyzer warnings. - [ ] I ran the change in Business Central and confirmed it behaves as expected. - [ ] I added or updated tests for the new behavior, or explained below why none are needed. **What I tested and the outcome** *(required — be specific: scenarios, commands, screenshots for UI changes)* <!-- Example: - Ran the new "Post and Send" action on a sales invoice in a fresh container; document posted and email queued (see screenshot). - New unit tests in MyFeatureTest.Codeunit.al pass locally; full module test suite green. - No tests added because change is comment-only / refactor with existing coverage. --> ## Risk & compatibility <!-- Anything reviewers should watch for: breaking changes, upgrade/data impact, permissions, telemetry, feature flags, follow-up work. Write "None" if there's nothing to call out. -->
Good Sense Reviewer - Round 1Recommendation: Request ChangesWhat this PR doesThis change routes the non-deductible part of a reverse-charge VAT payment-discount correction to the purchase payment-discount account instead of the purchase VAT account. The account selection matches the existing vendor posting logic, and the updated test covers the reported application scenario. However, the RU layer contains a malformed adaptation and cannot build. Problem-solution fitFit: Strong The change targets the incorrect G/L account allocation directly and preserves the existing behavior for other adjustment entry types. The RU implementation must be corrected before the solution works across all changed layers. SuggestionsS1 (🔴 High): Restore the RU-specific argument Risk assessment and necessityRisk: This changes financial posting across multiple layers. The main implementation is narrow and has regression coverage, but the malformed RU copy is a build blocker and also drops an existing transaction VAT flag from the changed call. Necessity: The fix is required because the current behavior assigns the non-deductible correction to the wrong G/L account. Without it, payment-discount posting produces an incorrect account allocation.
|
Co-authored-by: neeleshsinghal <241776335+neeleshsinghal@users.noreply.github.com>
Good Sense Reviewer - Round 2Recommendation: AcceptWhat this PR doesThis change sends the non-deductible part of a reverse-charge VAT payment-discount correction to the purchase payment-discount account instead of the purchase VAT account. The deductible correction and the reverse-charge counterpart retain their existing accounts and amounts. The changes since round 1 repair the RU posting call. The transaction VAT flag is again its final argument, with the required comma, rather than a standalone expression. The call now matches the localized procedure signature and neighboring VAT calls. Review of all 12 changed files found no further correctness issue; the updated regression test checks the corrected account allocation and exact totals. Problem-solution fitFit: Strong The account selection directly fixes the reported payment-discount correction. The RU repair preserves its localized transaction VAT behavior without changing the intended allocation. Status of previous suggestions
New observations (commits since round 1)None — the changes address the previous suggestion. Risk assessment and necessityRisk: Financial posting remains a sensitive area, but the change is limited to account selection for non-deductible reverse-charge VAT payment discounts. The regional copies preserve their existing local behavior, and the shared customer and service posting paths are unchanged. Two independent review samples agreed that S1 is addressed and found no new issues. The frozen three-dot Necessity: Without the fix, the non-deductible VAT correction continues to use the purchase VAT account rather than the payment-discount account, leaving an incorrect G/L allocation. The RU repair is necessary to make the changed localized call valid.
|
|
|
Fixes AB#653327
Fix : GL Account is now called from the General Posting Setup instead when Pmt Discount is Involved.