[Subcontracting] Fix subcontracting order opening wrong purchase order after creation#9396
[Subcontracting] Fix subcontracting order opening wrong purchase order after creation#93966CRIPT wants to merge 15 commits into
Conversation
…he last one created
…cting-order-opens-old-purchase-order
…tstanding Amount - SalesDocTotalsSalesEntryUI: disable Foundation app area to prevent auto invoice discount calculation - PurchDocTotalsSalesEntryUI: same fix for purchase doc totals tests - ERMSalesPurchaseDocument (CA): use Amount Including VAT for customer GL entry ACY calculation - SalesPurchaseReports (CA): use Outstanding Amount (includes tax) for report verification"
…urchaseOrderCreator
…, and Outstanding Amount" This reverts commit cd26c51.
…cting-order-opens-old-purchase-order
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Copilot PR ReviewIteration 2 · Outcome: completed Knowledge source: https://github.com/microsoft/BCQuality@186d8a131465475c79244d994acb872cd5c0d4bf Orchestrator pre-filter (2 file(s) excluded)
Findings produced by the AL review agent v1.7.3. Reply 👎 on any inline comment to flag false positives. |
|
Im getting infra failures not releated to my PR:
Note @Dynamics365 Thanks! |
|
1 similar comment
|
Pull request was closed
Fixes AB#639381
Problem
When a subcontracting operation already had a received purchase order and the production order quantity was increased, clicking Create Subcontracting Order again created a new PO for the delta quantity but opened the old, already-received PO instead of the newly created one. The user had to manually navigate to find the correct order.
Root cause
ShowCreatedPurchaseOrder re-derived which PO to open by filtering purchase lines (Prod. Order No. + Operation No. + Routing Reference No.). That filter matched both the old and the new lines, so FindFirst returned the lowest Document No. (the old one). The code never tracked which document was actually created during the current run.
Fix
We now capture the purchase order(s) actually created/affected in the current invocation: we snapshot the existing subcontracting POs before Carry Out and Mark the newly created (or updated) header afterwards, then open only the marked set. Filtering was aligned with PurchLineExists (open, unreceived lines), the confirmation count/branching is derived from the marked headers, and a fallback keeps working when Carry Out updates an existing open PO instead of creating a new one. Added two integration tests covering the delta-PO and updated-open-PO scenarios.