[Subcontracting] Purchase Line FactBox Shows Wrong Transfer Order Count When Return Exists

[stevengrossGOB]

Bug: Purchase Line FactBox Shows Wrong Transfer Order Count When Return Exists

Affected Objects

Type	Name	ID
Page	Subc. Purchase Line Factbox	99001518
Codeunit	Subc. Purch. Factbox Mgmt.	99001560

Reproduction Steps

Setup

• Standard subcontracting setup with an item, routing, and a released production order.
• Component supply method set to Transfer to Vendor.
• Vendor has a subcontracting location code; a transfer route exists between the source and subcontractor locations.
• A subcontracting Purchase Order is created from the Prod. Order Routing Line.
• An outbound Transfer Order is created from the Purchase Order.

Given

1. Items are partially or fully shipped to the subcontractor location (or placed in transit).
2. The Create Return from Subcontractor action is used on the Purchase Order to create a Return Transfer Order.

When

The Subc. Purchase Line Factbox is displayed for the Purchase Line.

Then (pre-fix — wrong behavior)

• No. of Transfer Orders shows 2 (counts both the outbound and return transfer orders).
• Return Transfer Order field is blank (does not display the return order number).
• Drilldown on the Return Transfer Order field still navigates correctly because ShowTransferOrdersAndReturnOrder uses the Subc. Return Order boolean.

False Behavior

• GetNoOfTransferOrders over-counts by including the return transfer order.
• GetReturnTransferOrderNo returns blank, unable to locate the return transfer order.

Expected Behavior

• No. of Transfer Orders = 1 (only the outbound transfer order).
• Return Transfer Order field = the return transfer order number.

Root Cause

FilterTransferLineToSubcontractorPurchaseOrder (used by GetNoOfTransferOrders and GetTransferOrderNo) identifies non-return lines by filtering "Subc. Operation No." <> '' and "Subc. Routing No." <> ''. However, the SubcCreateSubCReturnOrder report populates Subc. Operation No. and Subc. Routing No. on return transfer lines from the Prod. Order Routing Line. This means return lines pass the filter and are incorrectly included in the count.

GetReturnTransferOrderNo uses the inverse filter — "Subc. Operation No." = '' and "Subc. Routing No." = '' — to find return lines. Because return lines have these fields set, the query finds nothing and returns blank.

The Subc. Return Order boolean field (set to true on all return lines by the report) is the authoritative discriminator, as already used by ShowTransferOrdersAndReturnOrder and SubcRoutingFactboxMgmt.GetNoOfTransferLinesFromRouting.

Fix Description

File: src/Process/Codeunits/SubcPurchFactboxMgmt.Codeunit.al

1. FilterTransferLineToSubcontractorPurchaseOrder — replace the Subc. Operation No. <> '' and Subc. Routing No. <> '' filters with SetRange("Subc. Return Order", false).

2. GetReturnTransferOrderNo — replace the Subc. Operation No. = '' and Subc. Routing No. = '' filters with SetRange("Subc. Return Order", true).

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.

What I tested and the outcome (required — be specific: scenarios, commands, screenshots for UI changes)

Risk & compatibility

[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.