Bug 634720: [Subcontracting] Production Routing factbox count must match drill-down operation filter

[ChethanT]

Summary

• In the Subcontracting Details factbox on a Purchase Order, the Production Routing field showed a count (e.g. 4) that didn't match the single routing line opened by its drill-down. Same issue on the Transfer Order factbox.
• Root cause: CalcNoOfProductionOrderRoutings in codeunit 99001559 Subc. ProdO. Factbox Mgmt. filtered the Prod. Order Routing Line table by Status + Prod. Order No. + Routing Reference No. only, while its drill-down counterpart ShowProductionOrderRouting additionally filters by Routing No. and Operation No.. The count therefore returned all operations of the production order line; the drill-down always returns the single linked routing operation.
• Fix: Add the two missing filters in CalcNoOfProductionOrderRoutings so both methods apply the same filter set. Single-point fix shared by both Subc. Purchase Line Factbox and Subc. Transfer Line Factbox.

Test

Added CalcNoOfProductionOrderRoutingsReturnsOneForSubcontractingPurchaseLine ([SCENARIO 634720]) in codeunit 139989 Subc. Subcontracting Test (src/Apps/W1/Subcontracting/Test/src/Codeunits/Tests/SubcSubcontractingTest.Codeunit.al). The test:

1. Creates a production order whose routing has multiple operations (asserts Count() > 1 as a precondition to detect the bug),
2. Creates a subcontracting purchase order for the subcontracting work center, and
3. Asserts CalcNoOfProductionOrderRoutings(PurchaseLine) = 1, matching the drill-down.

Without the fix, the assertion would observe the total number of routing operations of the prod-order line (e.g. 4).

Fixes AB#634720

🤖 Generated with Claude Code

[alexei-dobriansky]

Analysis

Scenario Validity:

• Valid and clear. The linked ADO bug is concrete about both the setup and the symptom: the [AI-REPRO] comment says the Production Routing field on the subcontracting factbox shows 4 while drilling down opens only the single linked routing line. It also spells out the exact mismatch in filters between CalcNoOfProductionOrderRoutings and ShowProductionOrderRouting.
• The scenario is important enough to justify a fix: the factbox is presenting inconsistent information for the same record, which is misleading in a manufacturing workflow. The work item is specific about prerequisites (released production order, multi-operation routing, subcontracted operation) and expected vs. actual behavior.

Correctness:

• The root cause is real in code. ShowProductionOrderRouting already narrows the routing line by Status, Prod. Order No., Routing Reference No., Routing No., and Operation No. (src/Apps/W1/Subcontracting/App/src/Process/Codeunits/SubcProdOFactboxMgmt.Codeunit.al:43-63). Before this PR, CalcNoOfProductionOrderRoutings used only the first three filters (...Codeunit.al:70-83 in the pre-change diff), so it counted all operations for the production-order line instead of the single linked routing operation.
• The fix is the right one: adding SetRange("Routing No.", RoutingNo); and SetRange("Operation No.", OperationNo); at ...SubcProdOFactboxMgmt.Codeunit.al:83-84 makes the count helper use the same filter set as the drill-down.
• The exact purchase-order repro now traces correctly: the purchase factbox field ShowProdOrderRouting gets its value from GetNoOfProductionOrderRoutings, which delegates straight to CalcNoOfProductionOrderRoutings (src/Apps/W1/Subcontracting/App/src/Process/Pages/SubcPurchaseLineFactbox.Page.al:57-64,99-101). SetProdOrderInformationByVariant supplies Prod. Order No., Prod. Order Line No., Routing No., and Operation No. from the Purchase Line record (...SubcProdOFactboxMgmt.Codeunit.al:162-169), so after the patch the count and drill-down are aligned for the exact same purchase line.
• The Transfer Order claim also looks technically sound. The transfer factbox uses the same helper (src/Apps/W1/Subcontracting/App/src/Process/Pages/SubcTransferLineFactbox.Page.al:39-45,69-81), and SetProdOrderInformationByVariant has a dedicated Transfer Line branch that supplies the same four fields (...SubcProdOFactboxMgmt.Codeunit.al:186-193). Because the transfer drill-down already depends on Routing No. and Operation No., reusing those same fields in the count is consistent rather than a new behavioral leap.
• Edge cases:
  • If a subcontracting line somehow had blank Routing No. or Operation No., the drill-down path was already depending on those values, so this PR is not introducing a new dependency; it is aligning the count with the existing drill-down contract.
  • No event ordering / subscriber interaction is involved here, and the diff does not add or move any subscribers, so the BaseApp-side verification step is not applicable for this PR.

Side Effects:

• The behavioral change is narrow: only the displayed routing count changes, and only inside CalcNoOfProductionOrderRoutings. No public signatures, events, or posting logic are changed.
• For previously working scenarios, the practical effect is that the factbox number now matches the record set opened by drill-down. That is a correction, not a semantic expansion.
• I do not see newly unreachable code in the touched area. The method still returns 0/blank-path behavior when SetProdOrderInformationByVariant fails; the only change is the narrower filter before Count().
• Partner-extension risk is low because this is an internal count helper used by the subcontracting factboxes, not a public event or API surface.

Risk Assessment:

• Low. This is a two-line filter alignment in a UI/helper codeunit, not a posting or amount-calculation change.
• Financial sensitivity is low: the field is informational. It does not drive pricing, posting, inventory, or ledger updates.
• The blast radius is small because both affected factboxes were already delegating to this single helper; the patch just makes the helper consistent with the already-shipping drill-down logic.
• What if we don’t make this change? Users continue seeing a misleading routing count on subcontracting Purchase Order / Transfer Order factboxes and must drill down to discover the actual linked routing operation. The workaround exists (use drill-down), so the business impact is limited, but the UI remains self-contradictory.

Test Coverage:

• The PR adds one focused regression test: CalcNoOfProductionOrderRoutingsReturnsOneForSubcontractingPurchaseLine (src/Apps/W1/Subcontracting/Test/src/Codeunits/Tests/SubcSubcontractingTest.Codeunit.al:2248-2294).
• The test does exercise the fixed code path directly. It first establishes a production order with multiple routing operations (...:2274-2276), creates the subcontracting purchase order, then calls SubcProdOFactboxMgmt.CalcNoOfProductionOrderRoutings(PurchaseLine) and asserts the exact expected value 1 (...:2291-2293). That assertion is at the point of the fix, not only at some downstream side effect.
• I do not see a risk that this test passes for the wrong reason in the purchase-line scenario: the precondition Count() > 1 prevents the test from accidentally passing on a single-operation routing where the bug would be invisible.
• Missing coverage: the work item and PR description say the same mismatch exists on the Transfer Order factbox, but the new test only covers the Purchase Line branch of SetProdOrderInformationByVariant (...SubcProdOFactboxMgmt.Codeunit.al:162-169). There is still no companion regression covering the Transfer Line branch (...:186-193). Since the fix itself is tiny and the transfer path already uses the same drill-down contract, I do not consider that gap a blocker, but it is the main remaining weakness in the safety net.

Recommendation: Accept with Suggestions

1. Add a transfer-line regression test — The bug report explicitly says the same mismatch exists on the Transfer Order factbox, but the new test only proves the Purchase Line path. Please add a companion test that creates the subcontracting transfer scenario and asserts CalcNoOfProductionOrderRoutings(TransferLine) = 1, so the Transfer Line branch in SetProdOrderInformationByVariant (src/Apps/W1/Subcontracting/App/src/Process/Codeunits/SubcProdOFactboxMgmt.Codeunit.al:186-193) is covered too.