[sanjmaurya]

Bug 650503: [All-E] Subcontracting Order Date does not account for lead time before the routing operation starts

Fixes AB#650503

Issue :-

Bug 653858: subcontracting purchase lines and worksheet lines had the wrong Order Date. It was not the routing start date minus the purchase lead time.
When the user changed the lead time on an existing order, the date was not recalculated from the routing start.
Because the subcontractor price is date-effective, the wrong Order Date could also select the wrong price.

**Cause :- **

The subcontracting flows did not calculate the Order Date from the routing operation's Starting Date and the purchase lead time (Item Vendor lead time first, then Vendor).
The two flows are the Calculate Subcontracts report and the direct creation from the routing line.
On "Carry Out Action", the standard Make Order flow overwrote the purchase line dates with the purchase header's order date. It did not use the worksheet dates.
The existing "is the cost automatic?" check compared the line's Direct Unit Cost only to the price-aware cost. A worksheet cost computed before a price became valid for the order date was treated as manual, so the price was not refreshed.

Solution:-

SubcontractingManagement.Codeunit.al: new SetSubcontractingOrderDate. It sets Order Date backward from the routing start, using Lead-Time Management and the purchase lead time.
SubcCalculateSubcontracts.Report.al and SubcPurchaseOrderCreator.Codeunit.al: call SetSubcontractingOrderDate right after the vendor is validated, so both flows use the same date logic.
SubcReqWkshMakeOrd.Codeunit.al:
Suppresses the header order-date copy for subcontracting lines.
Sets Order Date, Expected Receipt Date (the due date) and Requested Receipt Date on new purchase lines, and when an existing order is changed or rescheduled.
SubcPriceManagement.Codeunit.al: new IsAutomaticSubcCostForReqLine. It also treats the pre-price fallback cost as automatic, so the price valid on the new order date is

[alexei-dobriansky]

Good Sense Reviewer - Round 1

Recommendation: Accept

What this PR does

This calculates the subcontracting Order Date backward from the routing operation start by using the standard purchase lead time and calendars. It then keeps the worksheet, direct-order, carry-out, reschedule, receipt dates, and date-effective pricing aligned.

The shared helper uses the standard purchase lead-time precedence and calendar calculation. The subscribers run at the right points to prevent the purchase header date from replacing the worksheet date, to apply the final dates before insert or modify, and to refresh only automatically calculated worksheet costs during new-line creation. The regression tests cover worksheet carry-out, direct creation, existing-order recalculation, lead-time precedence, receipt dates, and price selection.

Problem-solution fit

Fit: Strong

The change covers all reported creation and rescheduling paths and keeps the final purchase line dates and price consistent with the routing operation. The implementation is focused on the date-calculation and transfer points that caused the mismatch.

Suggestions

None.

Risk assessment and necessity

Risk: Order Date affects vendor preparation and date-effective subcontractor pricing, so a regression could select the wrong cost or provide too little lead time. The change is limited to subcontracting lines; the target branch contains the required publisher events at the expected points, and all live checks completed successfully.

Necessity: Without this change, worksheet and purchase-line dates can differ, direct and worksheet creation can calculate from the wrong date, and rescheduling can keep an outdated price. The centralized calculation and targeted subscribers remove those inconsistencies without changing public interfaces.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=12820 round=1 by=alexei-dobriansky at=2026-10-16T13:08:43.9958576Z lastSha=87be1a8ec8c534dec690424de0e4c32bd3c94d85 reviewKey=7191645bbf4a9a42cf3cc6c4b9cd396d34a06eaea7bf0699bfb5499c95c013d4 suggestions=

[github-actions]

⚠️ Stale Status Check Deleted

The Pull Request Build workflow run for this PR was older than 72 hours and has been deleted.

📋 Why was it deleted?

Status checks that are too old may no longer reflect the current state of the target branch. To ensure this PR is validated against the latest code and passes up-to-date checks, a fresh build is required.

---

🔄 How to trigger a new status check:

1. 📤 Push a new commit to the PR branch, or
2. 🔁 Close and reopen the PR

This will automatically trigger a new Pull Request Build workflow run.

[Predrag Maricic (PredragMaricic)]

The date calculation and propagation through worksheet, direct-order, and rescheduling flows look correct. The added tests cover the principal workflows, and no blocking correctness issue was found.

• S1 (Low): The PR description links AB#650503 but its synopsis says “Bug 653858”; the tests also refer to scenario 653858. Please align the issue references.
• S2 (Low): Add a Vendor-only fallback test; the current setup verifies Item Vendor precedence but not the no-Item-Vendor fallback. (Inline thread.)

CI reports 167 successful checks and four skipped checks.