[Bug][SubscriptionBilling] Process Usage Data Billing uses lines marked Processing Status = Error (currency mismatch)

[miljance]

Describe the issue

When the currency of a usage data import does not match the currency of the Customer/Vendor Subscription Contract, and the contract's Subscription Contract Type disallows a different currency (Allow Diff. Curr. in Cust. UD / Allow Diff. Curr. in Vend. UD = false), the Create Usage Data Billing step correctly marks the Usage Data Billing line with Processing Status = Error.

This happens in table 8022 "Usage Data Billing", procedure AlignContractCurrency, in src/Apps/W1/Subscription Billing/App/Usage Based Billing/Tables/UsageDataBilling.Table.al:

if AllowDiffCurrency then
    Rec."Currency Code" := TempSubscriptionLine."Currency Code"
else begin
    Rec."Currency Code" := ImportCurrencyCode;
    Rec."Processing Status" := Enum::"Processing Status"::Error;
    Rec.SetReason(CurrencyMismatchErr);
end;

However, the subsequent Process Usage Data Billing step (codeunit 8026 "Process Usage Data Billing", src/Apps/W1/Subscription Billing/App/Usage Based Billing/Codeunits/ProcessUsageDataBilling.Codeunit.al) never checks Processing Status. Its Code() procedure filters Usage Data Billing on only three fields:

UsageDataBilling.SetRange("Usage Data Import Entry No.", UsageDataImport."Entry No.");
UsageDataBilling.SetRange("Document No.", '');
UsageDataBilling.SetFilter("Subscription Contract No.", '<>%1', '');

As a result, the errored lines are still processed:

1. CalculateCustomerUsageDataBillingPrice recalculates and overwrites the line's "Unit Price" and Amount using the contract currency, despite the currency-mismatch rejection.
2. ProcessServiceCommitment then uses those lines to update the Subscription Header Quantity and the Subscription Line Price / "Unit Cost" / "Unit Cost (LCY)". Because Commit() is called after UpdateServiceObjectQuantity, these writes are not rolled back by any later error.
3. The aggregation helpers — FindUsageDataBilling, CalculateTotalUsageBillingQuantity, CalculateSumCostAmountFromUsageDataBilling, CalculateSumAmountFromUsageDataBilling — sum over the errored lines too, so a subscription line with a mix of valid and errored usage rows gets incorrect totals.

The error marking is therefore cosmetic: data the system explicitly refused to trust is still used to recalculate amounts and to update the Subscription and Subscription Line.

Expected behavior

Usage Data Billing lines with Processing Status = Error must be skipped by the Process Usage Data Billing step. Their amounts must not be recalculated, and they must not contribute to the values written back to the Subscription Header or Subscription Line.

Steps to reproduce

1. Create a Customer and a Vendor with a non-blank Currency Code, then create a Customer Subscription Contract and a Vendor Subscription Contract for them with usage-based Subscription Lines.
2. Assign Subscription Contract Types to both contracts with Allow Diff. Curr. in Cust. UD = false and Allow Diff. Curr. in Vend. UD = false.
3. Create a Usage Data Import (Generic supplier) whose imported usage data has no currency code, so the import currency differs from the contract currency. Use Usage Based Pricing = Usage Quantity and a supplier with Unit Price from Import = false.
4. Run the Create Usage Data Billing processing step. The Usage Data Billing lines get Processing Status = Error with the currency-mismatch reason; Unit Price and Amount are 0.
5. Run the Process Usage Data Billing processing step.

Actual: the errored lines get a Unit Price and Amount calculated, and the Subscription Header Quantity plus the Subscription Line Price / Unit Cost are updated from the rejected data.

Expected: the lines keep Processing Status = Error, Unit Price and Amount stay 0, and the Subscription Header and Subscription Line are left untouched.

Additional context

No response

I will provide a fix for a bug

• I will provide a fix for a bug