Bugs/625412 Wrong posted G/L Entries and VAT Entries using Cash Basis Unrealized VAT from a partial Credit Memo if we mix VAT types and use only part of the amount in the Mexican version. - #10840
Conversation
GitHub Actions
Inactive
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Good Sense Reviewer - Round 1Recommendation: Request ChangesWhat this PR doesThis changes customer unrealized VAT posting for sales credit memos so the VAT part is calculated from the settled credit memo amount for each VAT posting group. It also skips the unrealized-to-realized G/L transfer when the credit memo application only reduces the invoice's remaining unrealized VAT. The main logic is targeted: the grouped path filters VAT entries by posting group, splits the settled credit memo amount from the posted credit memo lines, and still updates the source VAT entry through PostUnrealVATEntry. No new event subscriber or external publisher dependency is introduced. The remaining concern is that the exact high-risk posting path that produced wrong G/L entries is not asserted. Problem-solution fitFit: Strong The reported scenario is a partial sales credit memo applied to an invoice with multiple VAT posting groups. The code change targets that calculation and the related G/L transfer, and the scope stays within the customer cash-basis VAT posting path. SuggestionsS1 (🔴 High): Add exact G/L regression assertion Risk assessment and necessityRisk: This is a sensitive customer posting path in codeunit 12 that changes VAT Entry updates and G/L Entry creation for cash-basis VAT. A wrong result can post incorrect VAT realization or leave invalid transfers between realized and unrealized VAT accounts. The purchase/vendor paths are not changed, and no public event contract is changed. Necessity: The change is needed because the current behavior can create wrong VAT and G/L amounts when a partial credit memo is applied against a mixed-VAT invoice. There is no safe functional workaround other than correcting posted accounting data, so the scope is justified, but the exact regression path should be pinned before merge.
|
Good Sense Reviewer - Round 2Recommendation: Request ChangesWhat this PR doesSince round 1, the tests now store the posted credit memo number and assert that the credited VAT group does not post the invoice-side unrealized-to-realized G/L transfer. A new test also covers a partially settled credit memo with more than one VAT group. That addresses the previous high-risk test gap. The posting logic is still targeted to the customer cash-basis VAT path, but the current head does not pass the required AL analyzer build because one changed branch now uses Status of previous suggestions
New observations (commits since round 1)S2 (🔴 High): AL analyzer failure blocks build Risk assessment and necessityRisk: This remains a sensitive customer VAT posting path in codeunit 12. A wrong result can post incorrect VAT realization or leave invalid transfers between realized and unrealized VAT accounts. No public event contract is changed, but the current analyzer failure blocks a clean app build. Necessity: The change is needed because the reported partial credit memo scenario can create wrong VAT and G/L amounts. The added assertion now pins the exact G/L regression path, so the remaining work is to make the changed branch comply with the required AL ruleset.
|
Good Sense Reviewer - Round 3Recommendation: Request ChangesWhat this PR doesSince round 2, the single-statement The direct credit-memo posting path is better covered now, but the current head still has build-blocking AA0210 warnings in the new tests. The posting logic also still misses an already-posted credit memo application path and can over-realize a group when the calculated group amount is higher than that group's remaining unrealized VAT. Status of previous suggestions
New observations (current head)S3 (🔴 High): Cover posted credit memo applications S4 (🔴 High): Cap VAT realization per group S5 (🔴 High): Remove new VAT Entry key warnings Risk assessment and necessityRisk: This is a sensitive cash-basis VAT posting path in codeunit 12. A wrong result can persist incorrect VAT realization or invalid G/L/VAT balances, and the current CI build is still blocked by new analyzer warnings. Necessity: The change is needed because the reported partial credit memo scenario can post wrong VAT and G/L amounts. The scope is justified, but the remaining posting gaps and build failure must be fixed before merge.
|
|
Agent judgement — not directly backed by a BCQuality knowledge article. Line mapping was unavailable, so this was posted as an issue comment. 👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.41.6 |
Good Sense Reviewer - Round 7Recommendation: AcceptWhat this PR doesSince round 6, the only code change is in the cash-basis VAT test code. It adds the posting-date confirm handler to one existing purchase unrealized VAT test and removes extra assertions from an older application test. The production posting logic is unchanged in this update. The full PR still splits credit memo settlement by VAT posting group, avoids the invoice-side unrealized-to-realized G/L transfer for credit memo applications, caps realized amounts to the remaining unrealized VAT, and keeps regression coverage for the sensitive sales credit memo posting scenarios. Status of previous suggestionsNo active suggestions were carried from round 6. The live marker for round 6 had an empty suggestions list. New observations (commits since round 6)None - the latest commit only adjusts test coverage and does not introduce a new blocking issue. Risk assessment and necessityRisk: The touched production area remains high risk because it posts customer unrealized VAT, VAT entries, and G/L entries. The latest update is test-only, and the removed checks are covered by the dedicated multi-VAT credit memo tests that assert remaining unrealized VAT and absence of invalid G/L transfers. Necessity: The change remains needed because the bug can persist wrong VAT realization and wrong G/L amounts. The current scope is still targeted to the reported cash-basis credit memo scenario and its follow-up posting paths.
|
Good Sense Reviewer - Round 8Recommendation: Request ChangesWhat this PR doesThe full PR updates cash-basis unrealized VAT posting for partial credit memos with mixed VAT posting groups. It splits the settled credit memo amount by VAT group, avoids the invalid invoice-side G/L transfer for credit memo applications, and keeps VAT entry updates tied to the affected group. The latest round is test-only. It strengthens one VAT-entry assertion and changes two MX credit memo tests, but the MX test change now calls a helper that is not declared in that codeunit. Problem-solution fitFit: Strong The bug is clear: a partial credit memo must realize VAT only for the affected VAT group and must not create invalid G/L entries between realized and unrealized VAT accounts. The production fix and the main regression tests match that scenario, but the latest MX test edit must compile before the PR can be accepted. Status of previous suggestionsNo active suggestions were carried from round 7. New observations (commits since round 7)S1 (🔴 High): MX tests call an undefined helper Risk assessment and necessityRisk: The production area is high risk because it posts customer unrealized VAT, VAT entries, and G/L entries. The latest code change is test-only, but the undefined helper prevents the MX test app from compiling, so CI cannot prove the posting fix. Necessity: The change remains needed because the bug can persist wrong VAT realization and wrong G/L amounts. The scope remains targeted once the test compile issue is fixed.
|
Good Sense Reviewer - Round 9Recommendation: AcceptWhat this PR doesThe full PR updates cash-basis unrealized VAT posting for partial sales credit memos with mixed VAT posting groups. It now uses the settled credit memo amount for each VAT group, avoids invoice-side realized/unrealized G/L transfers for the credit memo application, and updates tests for the sales and MX paths. The latest round is test-only. It adds the missing MX helper and keeps the additional-currency tests on the expected G/L-entry path, so the prior compile blocker is addressed without changing production code. Problem-solution fitFit: Strong The bug is clear: a partial credit memo must realize VAT only for the affected VAT group and must not create invalid G/L entries between realized and unrealized VAT accounts. The production calculation and regression tests match that scenario, including partial and remaining-payment flows. Status of previous suggestions
New observations (commits since round 8)None - the latest changes only address the prior test compile issue and adjust the affected assertions. Risk assessment and necessityRisk: The production area is high risk because it posts customer unrealized VAT, VAT entries, and G/L entries. The latest changes are limited to tests, and the helper used by the changed MX tests is now present. Necessity: The change is needed because the bug can persist wrong VAT realization and wrong G/L amounts. The scope is targeted to sales credit memo application and the related regression coverage.
|
90e5dd1
Good Sense Reviewer - Round 10Recommendation: AcceptWhat this PR doesThe latest changes adjust the cash-basis unrealized VAT fix and tests for partial credit memos with multiple VAT groups. The code limits realization to the affected VAT posting group, and the tests now check both affected and unaffected VAT groups. Status of previous suggestions
New observations (commits since round 9)None - the latest commit is test and scenario stabilization for the already-reviewed fix. Risk assessment and necessityRisk: High area but controlled. This affects VAT realization G/L and VAT entries in localized cash-basis posting, but the changed conditions are focused on credit memo application and are backed by multi-VAT-group tests. Necessity: The fix is needed to avoid realizing or reversing VAT for the wrong VAT group when a partial credit memo is applied.
|
5 participants
Error Reported
When posting sales credit memos with cash-basis VAT, partially applying a credit memo to invoices containing multiple VAT posting groups could calculate VAT realization using the total settled amount instead of the amount associated with each VAT group. This resulted in incorrect amounts and invalid G/L entries between the realized and unrealized VAT accounts.
Solution
A dedicated calculation was added to determine the settled credit memo amount for each VAT posting group combination. This amount is adjusted by the currency factor before the VAT amount is calculated.
A condition was also introduced to control when G/L entries should be posted, preventing incorrect entries when the credit memo application does not represent an actual VAT realization.
Files Modified
Result
Cash-basis VAT credit memos now realize VAT correctly for each VAT posting group. Partial and full applications, subsequent payments, and unapplied credit memos produce the expected amounts without creating invalid entries between the realized and unrealized VAT accounts.
Fixes
AB#648956