Fix subcontracting receipt undo Item Entry Relation identifier corruption

Problem Statement

Undoing a posted subcontracting purchase receipt can fail with Item Entry Relation already exists. When no key collision occurs, the undo can complete while associating lot or serial tracking with the wrong entry.

The failure is a cross-layer reproduction. The Subcontracting app supplies the production-linked subcontracting receipt context and marks the undo journal line as subcontracting. The generic Base App posting contract then returns a Capacity Ledger Entry number through Item Journal Line."Item Shpt. Entry No.". During tracked or multi-output receipt undo, the generic applied-entry-list flow interprets that overloaded value as an Item Ledger Entry number and persists it in Item Entry Relation.

The first manual recording is only the successful prerequisite adjustment item posting. The canonical reproduction commits two lot-tracking lines, posts the subcontracting purchase order successfully, and fails while undoing the posted receipt.

Solution

Make subcontracting receipt undo preserve the distinction between Capacity Ledger Entry identifiers and Item Ledger Entry identifiers. The undo flow must use the actual reversing Item Ledger Entry identifier when creating each Item Entry Relation, while retaining any Capacity Ledger Entry identifier for capacity-specific posting behavior.

After the change, undoing a tracked or multi-output subcontracting receipt must complete without a duplicate-key error, and its lot or serial relations must identify the reversing item postings. Normal purchase receipt undo and the existing untracked single-output subcontracting shortcut must retain their current behavior.

User Stories

1. As a production accountant, I want to undo a posted subcontracting purchase receipt with lot tracking, so that I can reverse an incorrect receipt without a runtime error.
2. As a production accountant, I want the undo operation to preserve the lot-to-item-posting association, so that item tracking remains attached to the reversed inventory movement.
3. As a production accountant, I want the undo operation to preserve serial-to-item-posting associations, so that serialized output can be traced after reversal.
4. As a warehouse user, I want tracked subcontracting receipt undo to complete through the normal posted-receipt action, so that I do not need a data repair or workaround.
5. As an inventory controller, I want every relation created by receipt undo to resolve to an existing Item Ledger Entry, so that tracking data cannot point at a capacity posting.
6. As an inventory controller, I want a successful undo to mean both that posting completed and that tracking relations are correct, so that silent corruption is not mistaken for success.
7. As a production accountant, I want a receipt with multiple eligible output Item Ledger Entries to undo successfully, so that partial or split output receipts are supported.
8. As a production accountant, I want a single lot-tracked output receipt to use the correct tracked undo path, so that the shortcut for untracked output does not mask the defect.
9. As a production accountant, I want a single serial-tracked output receipt to use the correct tracked undo path, so that serial tracking is handled consistently with lot tracking.
10. As an inventory controller, I want the system to distinguish Capacity Ledger Entry numbers from Item Ledger Entry numbers, so that independent number sequences cannot create false item relations.
11. As a developer, I want the posting result contract to retain its existing capacity-posting meaning for subcontracting, so that capacity costing and production behavior are not regressed while fixing tracking.
12. As a developer, I want the generic undo flow to consume an explicitly correct item-posting identifier for relation creation, so that it does not infer identifier type from an overloaded journal field.
13. As a developer, I want normal non-subcontracting purchase receipt undo to remain unchanged, so that the fix is limited to the affected cross-layer behavior.
14. As a developer, I want the untracked single-output subcontracting undo shortcut to remain unchanged, so that the existing efficient path is not unnecessarily broadened.
15. As a test maintainer, I want the regression to run with the Subcontracting app installed, so that the test reproduces the production-linked context that activates the defect.
16. As a test maintainer, I want the regression to create and commit tracking assignments deterministically, so that the test proves the tracked path rather than an unsaved UI state.
17. As a test maintainer, I want the regression to exercise the public receipt-undo operation, so that it verifies user-visible behavior rather than an internal implementation detail.
18. As a test maintainer, I want the regression to cover both duplicate-key prevention and relation correctness, so that future changes cannot reintroduce either failure mode.
19. As a support engineer, I want the documented reproduction to identify the positive adjustment as setup only, so that investigation focuses on the subcontracting receipt undo failure.
20. As a support engineer, I want the documented reproduction to state that the Subcontracting app is required, so that the issue is not incorrectly classified as reproducible in an isolated Base App scenario.

Implementation Decisions

• Treat this as a cross-layer defect: the Subcontracting app supplies the context and activates the affected path; the generic Base App undo flow owns the incorrect interpretation used for relation creation.
• Preserve the existing semantic distinction that subcontracting posting may return a Capacity Ledger Entry identifier through the overloaded journal field. Do not make Item Entry Relation depend on that field’s meaning.
• Change the highest practical undo seam: after each reversal posting in the applied-entry-list flow, obtain the actual reversing Item Ledger Entry identifier through the posting contract or an existing posting event, and use that identifier for the temporary item relation.
• Keep capacity-ledger identifiers available to the capacity-specific undo logic; the fix must not replace a capacity identifier in code that genuinely requires it.
• Keep the existing branching behavior: tracked output and multiple output entries use the applied-entry-list path; one untracked output may continue using the single-entry shortcut.
• Do not change the schema or primary key of Item Entry Relation. Its Item Entry No. remains an Item Ledger Entry identifier.
• Do not add a conversion based on numeric equality or a lookup that guesses whether a number belongs to a capacity or item ledger. The identifier type must be explicit at the handoff.
• Keep the Subcontracting app’s existing receipt-context and output-entry collection behavior unless a narrowly required contract adjustment is needed to expose the correct reversing item entry.
• Use the existing integration-test codeunit and test libraries. Avoid a new test-only production seam unless the current posting contract cannot expose the reversing item entry at the selected boundary.

Testing Decisions

• Tests must verify observable behavior at the posted purchase receipt undo boundary. They must not assert that a particular internal procedure or temporary record was called.
• Add a focused integration regression in the existing Subcontracting test suite, with the Subcontracting app installed and enabled.
• Build the scenario through existing manufacturing and purchase test libraries: create a production item with a subcontracting operation, create and refresh a released production order, create the linked subcontracting purchase order, commit deterministic lot or serial tracking, and post the receipt.
• Invoke the normal receipt undo operation using the established confirmation-handler pattern used by existing purchase-receipt undo tests.
• The primary scenario must use two committed lot assignments, matching the canonical manual reproduction and forcing the applied-entry-list path.
• Assert that receipt undo completes without the duplicate-key error.
• Assert that each created relation for the reversing receipt has an Item Entry No. that resolves to a reversing Item Ledger Entry and has the expected lot or serial tracking values.
• Assert that no relation created by the undo uses a Capacity Ledger Entry identifier as its Item Entry No.; this must be checked by resolving the relation to item-ledger data, not only by comparing numbers.
• Add focused coverage for a single serial-tracked output and for multiple eligible output Item Ledger Entries if the existing test setup can create them without duplicating the entire scenario.
• Preserve coverage for the untracked single-output shortcut and ordinary non-subcontracting receipt undo through existing tests or a small neighboring regression where needed.
• Use prior art from the existing Subcontracting integration tests for production and subcontracting order setup, the purchase test library for receipt posting, the item-tracking library for deterministic tracking codes and assignments, and the Base App SCM tests for receipt undo invocation and confirmation handling.

Out of Scope

• Repairing Item Entry Relation records that were already corrupted in customer databases.
• Changing the Item Entry Relation table schema, primary key, or TableRelation definition.
• Redesigning the general posting contract for every use of Item Shpt. Entry No. outside this affected undo flow.
• Changing subcontracting costing, capacity posting, production-order status updates, warehouse transfer behavior, or item-charge behavior except where required to preserve the corrected undo contract.
• Adding a UI warning or workaround instead of correcting the identifier handoff.
• Making an isolated Base App scenario without the Subcontracting app reproduce this issue; the Subcontracting receipt context is a required part of the reproduction.
• Reworking the manual recordings into an automated test script beyond correcting the committed tracking action and identifying the canonical reproduction.

Further Notes

• The issue is intermittent because Capacity Ledger Entry and Item Ledger Entry number sequences are independent. A capacity number can collide with an existing Item Entry Relation key or can be stored without collision while still identifying the wrong record.
• The adjustment item posting is setup data only. It is not the operation that creates the faulty relation.
• The regression’s two independent success criteria are intentional: no runtime failure and correct relation ownership.
• The current manual evidence indicates that the two lot assignments were accepted and committed in the client before posting; the recorded OK action should remain consistent with that evidence.

Start with the existing Subcontracting integration tests and the Base App SCM receipt-undo tests, then trace the applied-entry-list flow around Item Journal Line."Item Shpt. Entry No." and Item Entry Relation creation. Use the purchase, production, and item-tracking test libraries to reproduce the two committed lot assignments with the Subcontracting app installed. Done means public receipt undo completes and every created relation resolves to the reversing Item Ledger Entry, while capacity identifiers and existing shortcut behavior remain intact.