[Subcontracting] WIP Transfer Line Description Cleared When Direct Transfer Is Enabled

[stevengrossGOB]

Bug: WIP Transfer Line Description Cleared When Direct Transfer Is Enabled

Affected Objects

Object Type	Object Name	Object ID
TableExtension	Subc. Transfer Line	99001517
Codeunit	Subc. Transfer WIP Posting	99001541

Reproduction Steps

1. Setup: Create a production item with a subcontracting routing line where Transfer WIP Item = true and Transfer Description is empty. Create a transfer route with an in-transit location from the production order's location to the subcontractor location.
2. Given: Create a released production order. Create a subcontracting purchase order via the Prod. Order Routing page. Run "Create Transfer Order to Subcontractor" on the purchase order. This creates a WIP Transfer Line with Description filled from the item (because Transfer Description is blank on the routing line).
3. When: On the created Transfer Header, manually set Direct Transfer = true (or toggle it from false to true).
4. Then (wrong behavior): The WIP Transfer Line's Description field is emptied.

False Behavior

After enabling Direct Transfer on the Transfer Header, the WIP Transfer Line's Description becomes blank (''). The base application fires the OnUpdateTransLinesOnAfterUpdateFromDirectTransfer event during line rebuild, which triggers the Subcontracting app's subscriber in Subc. Transfer WIP Posting (codeunit 99001541). This subscriber calls TransferLine.Validate("Transfer WIP Item", true) and then TransferLine.UpdateDescriptions(). Inside UpdateDescriptions() (SubcTransferLine.TableExt.al), the routing line IS found (because Subc. Prod. Order No. and related fields are restored before this event fires), and the unconditional assignment Rec.Description := ProdOrderRoutingLine."Transfer Description" sets the description to the empty string.

Expected Behavior

When Transfer Description is empty on the Prod. Order Routing Line, the WIP Transfer Line's Description should remain unchanged (preserving the value set from the item description during initial creation). This matches the behavior in InsertWIPTransferLine and InsertWIPReturnTransferLine (in SubcCreateTransfOrder.Report.al and SubcCreateSubCReturnOrder.Report.al), which both guard the description assignment with if ProdOrderRoutingLine."Transfer Description" <> '' then.

Root Cause

Procedure: UpdateDescriptions() (line ~208)

The procedure unconditionally assigns Rec.Description := ProdOrderRoutingLine."Transfer Description" and Rec."Description 2" := ProdOrderRoutingLine."Transfer Description 2" without checking whether those values are non-empty:

internal procedure UpdateDescriptions()
var
    ProdOrderRoutingLine: Record "Prod. Order Routing Line";
begin
    if Rec."Transfer WIP Item" then
        if ProdOrderRoutingLine.Get(...) then begin
            Rec.Description := ProdOrderRoutingLine."Transfer Description";      // ← bug: clears if empty
            Rec."Description 2" := ProdOrderRoutingLine."Transfer Description 2"; // ← bug: clears if empty
        end;
end;

This is inconsistent with InsertWIPTransferLine and InsertWIPReturnTransferLine, which both use:

if ProdOrderRoutingLine."Transfer Description" <> '' then
    TransferLine.Description := ProdOrderRoutingLine."Transfer Description";

Fix Description

Add <> '' guards to UpdateDescriptions() to match the logic in both InsertWIPTransferLine and InsertWIPReturnTransferLine:

internal procedure UpdateDescriptions()
var
    ProdOrderRoutingLine: Record "Prod. Order Routing Line";
begin
    if Rec."Transfer WIP Item" then
        if ProdOrderRoutingLine.Get("Production Order Status"::Released, "Subc. Prod. Order No.", "Subc. Routing Reference No.", "Subc. Routing No.", "Subc. Operation No.") then begin
            if ProdOrderRoutingLine."Transfer Description" <> '' then
                Rec.Description := ProdOrderRoutingLine."Transfer Description";
            if ProdOrderRoutingLine."Transfer Description 2" <> '' then
                Rec."Description 2" := ProdOrderRoutingLine."Transfer Description 2";
        end;
end;

Related Work Item

• (add links if known)

How I validated this

• I read the full diff and it contains only changes I intended.
• I built the affected app(s) locally with no new analyzer warnings.
• I ran the change in Business Central and confirmed it behaves as expected.
• I added or updated tests for the new behavior, or explained below why none are needed.

[github-actions]

Could not find linked issues in the pull request description. Please make sure the pull request description contains a line that contains 'Fixes #' followed by the issue number being fixed. Use that pattern for every issue you want to link.