Fix 644744: Undo subcontracting receipt keys Item Entry Relation with Capacity Ledger Entry No. - #10254
Open
alexei-dobriansky wants to merge 2 commits into
Open
Conversation
… Capacity Ledger Entry No. During undo of a tracked (or multi-output) subcontracting receipt, UndoPostingManagement.PostItemJnlLineAppliedToList copied ItemJnlLine."Item Shpt. Entry No." into Item Entry Relation."Item Entry No.". For subcontracting that field carries the Capacity Ledger Entry No. (set in Item Jnl.-Post Line), not the reversing Output Item Ledger Entry, so the relation was keyed with a capacity entry - causing silent corruption or a duplicate-key error on table 6507 when the number already existed. Key the relation from the actual posted Output Item Ledger Entry (ItemJnlPostLine.GetItemLedgerEntryNo()) for subcontracting. Normal items and the capacity-only (non-last-operation) single-line undo path are unaffected. - Add subcontracting undo repro/guard tests (tracked repro + non-last-operation guard). - Re-enable UndoPurchReceiptWithProductionSubcontracting_LotTracking. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 658f7a29-90df-404c-bd6d-952085412bad
…644744-Subcon_ItemEntryRelationErrorOnUndoReceipt
alexei-dobriansky
added
SCM
alexei-dobriansky
enabled auto-merge
August 14, 2026 11:56
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| end; | ||
|
|
||
| [ConfirmHandler] | ||
| procedure ConfirmHandler(Question: Text[1024]; var Reply: Boolean) |
Contributor
There was a problem hiding this comment.
The new undo-receipt tests use a Confirm handler that always returns true without enqueueing or asserting the expected prompt. That means the tests can stay green even if the wrong confirmation is shown or the dialog interaction count changes, instead of proving the intended UI contract.
Knowledge:
👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.32.4
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes AB#644744: undoing a subcontracting purchase receipt could fail with a duplicate
Item Entry Relation(table 6507) error, or silently store a wrong relation key.Root cause
During undo of a tracked (or multi-output) subcontracting receipt,
UndoPostingManagement.PostItemJnlLineAppliedToListcopiedItemJnlLine."Item Shpt. Entry No."intoItem Entry Relation."Item Entry No.". For subcontracting, that field carries the Capacity Ledger Entry No. (set inItem Jnl.-Post Line), not the reversing Output Item Ledger Entry. So the relation — whose primary key is aTableRelationtoItem Ledger Entry— was keyed with a capacity entry number, causing either silent corruption or a duplicate-key error when that number already existed as a relation key.The forward receipt path is unaffected because it keys the relation from the tracking specification (
InitFromTrackingSpec), which always carries the real Output ILE. The untracked single-output undo takes a shortcut path that never builds the relation, which is why the bug only reproduces with tracked/multi-output undo.Fix
In
PostItemJnlLineAppliedToList, for subcontracting key the relation from the actual posted Output Item Ledger Entry (ItemJnlPostLine.GetItemLedgerEntryNo()). Normal items and the capacity-only (non-last-operation) single-line undo path are unaffected.Tests
SubcWhseItemTrackingtests: tracked undo repro (asserts the relation is not keyed by a Capacity Ledger Entry and does reference the reversing Output ILE) and a non-last-operation guard (capacity-only undo creates no capacity-keyed relation).SCM Production Order III.UndoPurchReceiptWithProductionSubcontracting_LotTracking.