Repository navigation
[Master]-Dispute Status – Inconsistent On Hold and Document Synchronization on Vendor Ledger Entries. - #13228
Conversation
GitHub Actions
Inactive
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
🔵 Needs a closer look
The interaction between vendor dispute validation and manually maintained holds during ledger edits needs functional confirmation before approval.
No open issues 🎉
What changed in this PR
This PR aligns dispute-status handling for vendor and customer ledger entries in Business Central, with regression coverage for hold changes and posted-invoice synchronization.
Changes:
- Adds vendor validation to set or clear dispute-controlled holds.
- Clears customer holds marked
Xwhen replacing or removing a status configured to overwrite holds. - Propagates changes across country layers and adds tests for vendor status assignment and vendor/customer status removal.
| File | Description |
|---|---|
| src/Layers/W1/Tests/ERM/EditPostedDocuments.Codeunit.al | Adds hold and invoice-synchronization regression tests. |
| src/Layers/W1/BaseApp/Sales/Receivables/CustLedgerEntry.Table.al | Clears holds when changing qualifying dispute statuses. |
| src/Layers/W1/BaseApp/Purchases/Payables/VendorLedgerEntry.Table.al | Adds dispute-driven hold validation. |
| src/Layers/RU/Tests/ERM/EditPostedDocuments.Codeunit.al | Adds localized regression tests. |
| src/Layers/RU/BaseApp/Sales/Receivables/CustLedgerEntry.Table.al | Propagates customer hold clearing. |
| src/Layers/RU/BaseApp/Purchases/Payables/VendorLedgerEntry.Table.al | Propagates vendor hold validation. |
| src/Layers/NO/BaseApp/Purchases/Payables/VendorLedgerEntry.Table.al | Propagates vendor hold validation. |
| src/Layers/NL/Tests/ERM/EditPostedDocuments.Codeunit.al | Adds localized regression tests. |
| src/Layers/NL/BaseApp/Sales/Receivables/CustLedgerEntry.Table.al | Propagates customer hold clearing. |
| src/Layers/NL/BaseApp/Purchases/Payables/VendorLedgerEntry.Table.al | Propagates vendor hold validation. |
| src/Layers/NA/BaseApp/Sales/Receivables/CustLedgerEntry.Table.al | Propagates customer hold clearing. |
| src/Layers/NA/BaseApp/Purchases/Payables/VendorLedgerEntry.Table.al | Propagates vendor hold validation. |
| src/Layers/IT/Tests/ERM/EditPostedDocuments.Codeunit.al | Adds regression tests and a sales-invoice helper. |
| src/Layers/IT/BaseApp/Sales/Receivables/CustLedgerEntry.Table.al | Propagates customer hold clearing. |
| src/Layers/IT/BaseApp/Purchases/Payables/VendorLedgerEntry.Table.al | Propagates vendor hold validation. |
| src/Layers/IS/BaseApp/Sales/Receivables/CustLedgerEntry.Table.al | Propagates customer hold clearing. |
| src/Layers/GB/Tests/ERM/EditPostedDocuments.Codeunit.al | Adds localized regression tests. |
| src/Layers/GB/BaseApp/Purchases/Payables/VendorLedgerEntry.Table.al | Propagates vendor hold validation. |
| src/Layers/FR/BaseApp/Sales/Receivables/CustLedgerEntry.Table.al | Propagates customer hold clearing. |
| src/Layers/FR/BaseApp/Purchases/Payables/VendorLedgerEntry.Table.al | Propagates vendor hold validation. |
| src/Layers/FI/BaseApp/Sales/Receivables/CustLedgerEntry.Table.al | Propagates customer hold clearing. |
| src/Layers/FI/BaseApp/Purchases/Payables/VendorLedgerEntry.Table.al | Propagates vendor hold validation. |
| src/Layers/ES/Tests/ERM/EditPostedDocuments.Codeunit.al | Adds regression tests and a sales-invoice helper. |
| src/Layers/ES/BaseApp/Sales/Receivables/CustLedgerEntry.Table.al | Propagates customer hold clearing. |
| src/Layers/ES/BaseApp/Purchases/Payables/VendorLedgerEntry.Table.al | Propagates vendor hold validation. |
| src/Layers/CH/BaseApp/Sales/Receivables/CustLedgerEntry.Table.al | Propagates customer hold clearing. |
| src/Layers/CH/BaseApp/Purchases/Payables/VendorLedgerEntry.Table.al | Propagates vendor hold validation. |
| src/Layers/BE/Tests/ERM/EditPostedDocuments.Codeunit.al | Adds localized regression tests. |
| src/Layers/APAC/Tests/ERM/EditPostedDocuments.Codeunit.al | Adds localized regression tests. |
| src/Layers/APAC/BaseApp/Sales/Receivables/CustLedgerEntry.Table.al | Propagates customer hold clearing. |
| src/Layers/APAC/BaseApp/Purchases/Payables/VendorLedgerEntry.Table.al | Propagates vendor hold validation. |
Review effort: Balanced
Good Sense Reviewer - Round 1Recommendation: Accept with SuggestionsWhat this PR doesAdds dispute-status validation to vendor ledger entries and clears dispute-controlled holds when an overwrite status is removed or replaced on vendor and customer entries. The equivalent changes are applied across the affected regional files. The conditions preserve manual hold codes other than Problem-solution fitFit: Strong The changed validation directly addresses inconsistent hold assignment and removal. It also uses the existing posted-invoice synchronization paths rather than adding another document-update mechanism. SuggestionsS1 (🟠 Moderate): Keep the warning for existing payment journals S2 (🟠 Moderate): Cover status switches and manual hold preservation Risk assessment and necessityRisk: Automatic hold changes affect payment selection and collection workflows. The main integration concern is the existing payment-journal confirmation noted above; public signatures and event contracts remain unchanged. Test bodies were reviewed, but no build or runtime tests were run. Necessity: Without this change, an overwrite dispute status does not automatically hold a vendor entry, while removing one from a customer entry can leave the automatic hold behind. Users must maintain these holds manually, so the targeted correction is justified.
|
|
GitHub Actions
Inactive
…Bug-656633-Dispute-Status-Inconsistent-On-Hold-on-Vendor-Ledger-Entries
Good Sense Reviewer - Round 2Recommendation: Accept with SuggestionsWhat this PR doesUpdates dispute-controlled holds on vendor and customer ledger entries and uses the existing entry-edit codeunits to keep posted invoices synchronized. Since round 1, vendor hold changes use Status of previous suggestions
New observations (commits since round 1)S3 (🟠 Moderate): Preserve dispute edits on closed Spanish customer entries Risk assessment and necessityRisk: Automatic holds affect payment selection and customer collection. The final-value check preserves the existing journal warning and avoids unnecessary validation, but closed Spanish customer entries need the handling described above. Public signatures and event contracts are unchanged. Test bodies and callers were reviewed; no build or runtime tests were run. Necessity: Without the fix, an overwrite dispute status can leave a vendor entry available for payment, and removing a customer dispute can leave an automatic hold behind. Users must adjust these holds manually, so the focused correction is justified.
|
…Bug-656633-Dispute-Status-Inconsistent-On-Hold-on-Vendor-Ledger-Entries
Good Sense Reviewer - Round 3Recommendation: AcceptWhat this PR doesManages dispute-controlled holds on vendor and customer ledger entries while retaining the existing posted-invoice synchronization paths. The hold calculation clears X only when leaving an overwrite status and preserves other manual hold codes. The new Spanish customer change assigns the final hold value on closed entries without calling the validation that requires Open, while open entries still reach the existing journal confirmation. Its regression test sets and removes an overwrite dispute through Cust. Entry-Edit on a closed entry. All three previous suggestions have positive fix evidence; no new finding is supported by the author-only new commit and net diff. Status of previous suggestions
New observations (commits since round 2)None - changes only addressed prior suggestions. Risk assessment and necessityRisk: Automatic holds affect payment selection and customer collection. Final vendor hold changes retain the payment-journal warning, and the Spanish customer path now preserves closed-entry dispute edits while retaining validation for open entries. All 31 frozen changed-file hunks were verified against the pinned head, and regional validation and test bodies were compared. Public signatures, event contracts, amounts, and posting calculations are unchanged. Necessity: Without this correction, assigning an overwrite dispute can leave a vendor entry available for payment, and removing a dispute can leave an automatic hold behind. Users must adjust holds manually. The focused validation changes and regression coverage are justified.
|
Fixes AB#656633