[Field Service Integration] Rounding error on Service Line quantity write-back for Item-type service lines with non-divisible durations

[tomasevicst]

Problem

When Field Service syncs Work Order Service durations back to BC Service Lines, the /60 conversion from minutes to hours produces repeating decimals for non-divisible durations (e.g. 20 min → 0.3333..., 40 min → 0.6666...). These raw values hit ServiceLine.Validate(Quantity, ...), which internally calls UOMMgt.RoundAndValidateQty and fails with:

• "The value 0.666666666666667 in field Quantity is of lower precision than expected..." — when Item UoM rounding precision is defined
• "This will cause the quantity and base quantity fields to be out of balance." — when Item UoM rounding precision is not defined

Fix

In FSIntTableSubscriber.Codeunit.al, wrap every /60 result with UOMMgt.RoundQty(value, ServiceLine."Qty. Rounding Precision") before passing to Validate. RoundQty falls back to 0.00001 when precision is 0, so both error cases are covered.

UpdateQuantities(FSWorkOrderService, ServiceLine, ToFieldService) — four sites:

• Estimated path: EstimateDuration / 60 → Quantity
• Actual path: GetMaxQuantity(Duration, DurationToBill) / 60 → Quantity and Qty. to Ship
• Actual path: DurationToBill / 60 → Qty. to Invoice

UpdateQuantities(FSBookableResourceBooking, ServiceLine) — one site:

• FSBookableResourceBooking.Duration / 60 → Quantity

Backward Compatibility

No schema or API changes. RoundQty with a rounding precision of 0 defaults to 0.00001, matching the existing behavior for items where precision is not configured. For items with a defined precision, quantities are now correctly rounded before validation instead of relying on the trigger to catch the mismatch.

What & why

Linked work

Fixes AB#640688

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]

Copilot PR Review

Iteration 1 · Outcome: completed

Knowledge source: https://github.com/microsoft/BCQuality@822cae1b2771ac25f665f73369f69093bd4fd630

Orchestrator pre-filter (13 file(s) excluded)

• layer-disabled (knowledge) : 13 file(s)

_{Findings produced by the Copilot CLI agent against BCQuality at 822cae1b2771ac25f665f73369f69093bd4fd630. Reply 👎 on any inline comment to flag false positives.}