PO-2026-115 Partially received v2 · amended 24-06 160 short

Line 4 has no cost layer line. LBA01 was shipped but never arrived, so there is nothing to cost. Its 160 units were written off GIT_INBOUND to LOST_IN_TRANSIT so the transit balance closes, and the money sits on supplier claim SC-2026-0041 instead of on a stock valuation (rule R-05.11). Its AED 32,200 of FOB is excluded from the allocation denominators, which is why the landed unit cost of every other line is higher than a naive PO-wide average would give.

Read the Δ unit column against a quantity-only basis. INV1's cost_engine.allocate_receipt_costs spread every overhead by unit count, which would have given all eight lines the same +AED 4.78. i3's per-component basis gives MIN-2159 +13.33 because a canvas tote is 0.34 kg and takes 36% of the air freight on 12% of the units, and gives ALM02 +1.90. That difference flows straight into gross margin per SKU and into the reorder engine's cost input, so it is not a rounding preference.

Rounding residue is placed, not lost. Each line gets floor(amount x numerator / denominator); the remainder goes entirely to the single line with the largest basis numerator and that cell is outlined. Clearance carried AED 3 of residue to CDW01, insurance AED 4 and duty AED 1 to MST-CRM-42-BLK.

Why cost rows live in a second journal. The v2 PRD constrains inventory_ledger.quantity_delta to be non-zero, and a cost revision moves value with zero quantity. Rather than weaken that constraint for every module, i3 keeps quantity in ledger_entries and value in cost_ledger, hash-chained the same way and reconciled against it nightly. This is open question Q-05.1 in the module spec and needs a lead ruling.

Note that the eleven quantity rows sum to zero across the two supplier-side stock types: IN_PRODUCTION opened 1,800 and closed 0, GIT_INBOUND opened 1,800 and closed 0. That is acceptance criterion AC-05.2 and AC-05.3 satisfied for this PO. Nothing was stranded in transit.