[Main]- Standard-cost purchase receipts use Direct Unit Cost instead of Standard Cost when cumulative expected-cost rounding is enabled

[DhavalMore88]

Bug 646424: [master] [Repair Item] [ALL-E] Standard-cost purchase receipts use Direct Unit Cost instead of Standard Cost when cumulative expected-cost rounding is enabled

AB#646424

Issue: When posting a purchase receipt (receive only, no invoice) for an item with Costing Method = Standard, the Cost Amount (Expected) on the Value Entry is calculated from the Direct Unit Cost on the purchase line instead of the item's Standard Cost (e.g. Standard Cost 0.134 × 1000 posts 136.00 instead of 134.00). This overstates the interim inventory value and the Inventory Accrual (Interim) G/L amount, breaking the standard costing principle that inventory is always valued at Standard Cost.

Cause: In CalcPosShares in ItemJnlPostLine.Codeunit.al, the fix for Bug 631139 (PR 245490) introduced ShouldUseCumulativeRoundingForExpectedCost to switch the expected-cost basis from ItemJnlLine."Unit Cost" * ItemJnlLine.Quantity to ItemJnlLine.Amount in order to eliminate a 0.01 rounding residual across partial receipts. For FIFO/Average items these two expressions are equivalent, but the guard did not exclude Standard costing, where ItemJnlLine.Amount carries the vendor's Direct Unit Cost and legitimately differs from Standard Cost — so the price difference was silently capitalised into inventory instead of being recognised as Purchase Variance on invoicing.

Solution: Added an early if Item."Costing Method" = Item."Costing Method"::Standard then exit(false); check to ShouldUseCumulativeRoundingForExpectedCost in ItemJnlPostLine.Codeunit.al (W1 plus the APAC, CH, ES, IT and RU layers), so Standard-cost items fall back to the Unit Cost * Quantity basis and post expected cost at Standard Cost. The two scenarios are mutually exclusive on Costing Method, so Bug 631139's cumulative-rounding behaviour is fully preserved for FIFO/Average/LIFO/Specific items, and the price difference is correctly posted to Purchase Variance when the receipt is invoiced. Added regression test StandardCostItemExpectedCostUsesStandardCostOnReceipt to codeunit 137018.

[alexei-dobriansky]

Agentic PR Review - Round 1

Recommendation: Accept

What this PR does

This PR fixes a bug where posting a purchase receipt for a Standard-cost item incorrectly calculates Cost Amount (Expected) using the vendor's Direct Unit Cost instead of the item's Standard Cost. The root cause is in ShouldUseCumulativeRoundingForExpectedCost in ItemJnlPostLine.Codeunit.al: a prior fix (Bug 631139) switched the expected-cost basis to ItemJnlLine.Amount to eliminate rounding residuals across partial receipts, but the guard did not exclude Standard costing, where Amount carries the vendor price rather than Standard Cost.

The fix adds an early exit(false) for Costing Method = Standard before the function can return true. This correctly routes Standard-cost items back to the Unit Cost * Quantity path, which uses Standard Cost, while leaving the cumulative-rounding behaviour fully intact for FIFO, Average, LIFO, and Specific items. The condition is placed before the other guards, which is the right order — Standard costing is a property of the item, not of setup flags, so it should be evaluated first. The fix is applied identically to all six layers (W1, APAC, CH, ES, IT, RU) that carry a copy of this codeunit.

Suggestions

No suggestions.

Risk assessment and necessity

Risk: The change is a targeted two-line guard in a single local function. The only behavioral change is that ShouldUseCumulativeRoundingForExpectedCost now returns false for Standard-cost items; this was already the correct behavior before Bug 631139's patch. FIFO, Average, LIFO, and Specific items are unaffected — the new guard exits before they reach the later checks, but those items never match Costing Method = Standard, so there is no change in their code path. The regression test StandardCostItemExpectedCostUsesStandardCostOnReceipt in codeunit 137018 directly covers the fixed scenario with a quantity large enough (1000) to trigger cumulative rounding, using random decimal values to cover the rounding edge case described in the bug. All six layer copies are patched consistently, so there is no risk of the bug remaining in a specific country deployment.

Necessity: The bug causes the interim inventory value and the Inventory Accrual (Interim) G/L balance to be overstated for every Standard-cost purchase receipt when cumulative expected-cost rounding is enabled. The fix correctly restores standard costing semantics (inventory always valued at Standard Cost) without touching any shared code path. The scope is appropriate for a targeted bug fix.

---

[AI-PR-REVIEW] version=1 promptVersion=1 system=github pr=10094 round=1 by=alexei-dobriansky at=2026-08-11T09:39:19Z lastSha=9f38c521c47ad8e10854b2346ce57c8293110cdd reviewKey=b1f25d4f9a36687342e24026293a0c3263d74cfb63a0ff893b914d897c4482aa suggestions=