Skip to content

[Bug]: [W1] [Subscription Billing] Sales-Explode BOM fails for foreign-currency customers when Sales Subscription Line reads uninserted Sales Line #10441

Description

Describe the issue

Exploding a BOM (Codeunit "Sales-Explode BOM") on a sales line for a customer that invoices in a foreign currency fails with a Sales Line "does not exist" runtime error.

Table 8068 "Sales Subscription Line" caches the originating sales line in the global variable SalesLine (set via SetSalesLine before the sales line itself is inserted, during BOM explosion in Codeunit 8069 "Sales Subscription Line Mgmt."). However, local procedure GetDate(): Date performed a hard SalesLine.Get(Rec."Document Type", Rec."Document No.", Rec."Document Line No.") instead of reusing the existing GetSalesLine(var SalesLine2: Record "Sales Line") caching helper (which falls back to Get() only when the cached line doesn't match).

GetDate() is invoked from the Unit Cost (LCY) field's OnValidate trigger, which fires while the sales line still only exists in memory (not yet inserted). For FCY customers this validation path is triggered, so the hard Get() fails. Non-FCY customers don't hit this code path, which is why the defect only reproduces with a foreign currency.

Expected behavior

BOM explosion on a sales line for a foreign-currency customer should succeed and create the corresponding "Sales Subscription Line" records without errors, the same as it does for LCY customers.

Steps to reproduce

  1. Create a customer with a foreign currency (Currency Code <> '').
  2. Create an item with Replenishment System = Assembly (BOM), where the BOM component has a Subscription Package/Service Commitment assigned.
  3. Create a sales order line for that customer/item.
  4. Run Codeunit::"Sales-Explode BOM" on the sales line (for example, via the Explode BOM action, or programmatically).
  5. Observe the error: Sales Line does not exist.

Additional context

Root cause: Table 8068 "Sales Subscription Line" → local procedure GetDate(): Date called SalesLine.Get(Rec."Document Type", Rec."Document No.", Rec."Document Line No.") directly instead of GetSalesLine(SalesLine).

Fix: replace the direct Get() call in GetDate() with GetSalesLine(SalesLine), which reuses the in-memory cached sales line set via SetSalesLine during BOM explosion when it matches, and only falls back to Get() otherwise. This is consistent with every other call site in this table (CalculateUnitCost, CalculateServiceAmount, CalculateCalculationBaseAmount, CreateVATAmountLineForSalesSubscriptionLine).

I will provide a fix for a bug

  • I will provide a fix for a bug

Metadata

Metadata

Assignees

No one assigned

    Labels

    FinanceGitHub request for Finance area

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions