Bug 640321: Blanket Purch. Order to Order drops extended text for later items

[alexei-dobriansky]

Fixes AB#640321

Codeunit 97 copied each blanket line to the order with "Attached to Line No." still pointing at the blanket line no.; IsPurchOrderLineToBeInserted then Gets that stale line no. on the new order and, when the parent item lands on a different line no., skips the extended-text line. Add RemapAttachedToLineNo (mirroring the shipped Sales-side fix) to rewrite "Attached to Line No." to the parent's new order line no. before the insert check. Adds a test. Propagated to the IT and NA layers.

[alexei-dobriansky]

Agentic PR Review - Round 1

Recommendation: Accept

What this PR does

This PR fixes Bug 640321 by remapping purchase extended-text lines from the blanket line number to the new purchase order parent line number before IsPurchOrderLineToBeInserted checks whether the attached line exists. The change is targeted and matches the existing Sales-side RemapAttachedToLineNo pattern. The parent line is inserted before its extended-text lines, the lookup uses the blanket order back-reference and the existing Purchase Line key, and the added W1, IT, and NA tests cover the multi-item regression that drops later extended text.

Suggestions

None.

Risk assessment and necessity

Risk: The regression surface is limited to Blanket Purchase Order to Order line creation in W1, IT, and NA. The change happens before OnBeforeInsertPurchOrderLine, so extensions see the corrected order-side Attached to Line No.; that aligns with the Sales-side behavior and should reduce, not increase, extension ambiguity. The lookup is index-backed by Purchase Line key ("Document Type", "Blanket Order No.", "Blanket Order Line No."), so performance risk is low.

Necessity: The bug is clear and important: the [AI-REPRO] comment scores the repro 10/10 and shows that later items silently lose extended text when Make Order is used. Without this change, users must manually re-add missing extended text or risk incomplete purchase order details. The scope is appropriate because the PR fixes only the affected purchase conversion code and adds regression tests for all changed test layers.

---

[AI-PR-REVIEW] version=1 system=github pr=9084 round=1 by=alexei-dobriansky at=2026-07-06T09:02:06Z lastSha=17396f3b85b2ecee6ced06113a156c88af17b361 suggestions=none

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Agent} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

RemapAttachedToLineNo (new in this PR, identically added to the W1, IT, and NA copies of BlanketPurchOrdertoOrder.Codeunit.al) only overwrites PurchOrderLine."Attached to Line No." when ParentPurchaseLine.FindFirst() succeeds.

If the parent blanket line was not transferred into this specific new order (for example a prior partial 'Make Order' already created the parent on an earlier order, while an unposted extended-text/attached line for the same parent is processed again on a later partial run), the field keeps the stale blanket-order line number instead of being cleared. IsPurchOrderLineToBeInserted() then calls AttachedToPurchaseLine.Get() against the new document using that stale number: if it happens to collide with an unrelated line number in the new order (plausible since both documents often use the same default line-number increment), the extended text silently attaches to the wrong line instead of being dropped or erroring. Recommend adding an else branch that resets PurchOrderLine."Attached to Line No." to 0 when the parent lookup misses, so the existing Get()-based check in IsPurchOrderLineToBeInserted cleanly excludes the orphaned attachment instead of risking a coincidental false match. This is flagged as advisory pending confirmation of whether the partial-order scenario is reachable in practice; if confirmed reachable, the impact would be a silent data-integrity defect and this guidance is a candidate for a dedicated BCQuality knowledge article.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

    local procedure RemapAttachedToLineNo(PurchBlanketOrderLine: Record "Purchase Line"; var PurchOrderLine: Record "Purchase Line")
    var
        ParentPurchaseLine: Record "Purchase Line";
    begin
        if PurchOrderLine."Attached to Line No." = 0 then
            exit;

        ParentPurchaseLine.SetCurrentKey("Document Type", "Blanket Order No.", "Blanket Order Line No.");
        ParentPurchaseLine.SetLoadFields("Line No.");
        ParentPurchaseLine.SetRange("Document Type", PurchOrderLine."Document Type");
        ParentPurchaseLine.SetRange("Document No.", PurchOrderLine."Document No.");
        ParentPurchaseLine.SetRange("Blanket Order No.", PurchBlanketOrderLine."Document No.");
        ParentPurchaseLine.SetRange("Blanket Order Line No.", PurchBlanketOrderLine."Attached to Line No.");
        if ParentPurchaseLine.FindFirst() then
            PurchOrderLine."Attached to Line No." := ParentPurchaseLine."Line No."
        else
            PurchOrderLine."Attached to Line No." := 0;
    end;

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

[github-actions]

Copilot PR Review

Iteration 1 · Outcome: completed

Knowledge source: https://github.com/microsoft/BCQuality@822cae1b2771ac25f665f73369f69093bd4fd630

Findings by domain

Findings split into Knowledge-backed (cite a BCQuality article) and Agent (the agent's own judgement, no matching BCQuality rule).

Domain	Findings	Knowledge-backed	Agent	Inline	Fallback
Agent	1	0	1	1	0

Totals: 0 knowledge-backed · 1 agent findings.

Orchestrator pre-filter (13 file(s) excluded)

• layer-disabled (knowledge) : 13 file(s)

_{Findings produced by the Copilot CLI agent against BCQuality at 822cae1b2771ac25f665f73369f69093bd4fd630. Reply 👎 on any inline comment to flag false positives.}