When using Landed cost + Goods in transit (GIT) with Moving Average items, posting remaining actual voyage costs can fail with a negative-cost validation (e.g., “negative cost amount for receipts is not allowed”) if the required adjustment would push the referenced receipt’s remaining value below zero.

This occurs in real operational flows where:

• Estimated landed costs were posted correctly
• Some actual costs were posted successfully
• A manual Revaluation for moving average was performed before all actual voyage costs were finalized (to correct valuation elsewhere)
• Revaluation changed the item’s valuation “pool” and reduced a particular receipt layer’s remaining value (including to zero)
• Later, when remaining actual costs are posted and the actual is lower than estimate, the system must apply a negative adjustment against that receipt, which is blocked.

Customer scenario (sanitized but real)

• A purchase order (PO-A) for item (Item-X) is linked to a voyage using GIT.
• Estimated landed costs are applied successfully.
• Actual voyage cost posting correctly reverses estimates and applies actuals (standard behavior).
• A separate PO (PO-B) is posted later with an incorrect estimate for one cost type.
• Before all actual voyage costs are available, users run Revaluation for moving average to correct valuation.
• The revaluation impacts the same item valuation pool and reduces PO-A’s receipt value to zero, including related GIT records.
• When trying to post the remaining actual landed costs for PO-A, if actual < estimate, the system requires a negative adjustment and blocks posting due to negative receipt cost prevention.

Why this is a problem (business impact)

This creates a recurring operational failure mode:

• Remaining actual landed cost lines cannot be posted, leaving voyages partially costed and operationally “open.”
• Finance and supply chain teams cannot complete normal cost finalization flows without manual workarounds.
• Manual workarounds are not scalable (high-touch and error-prone), and create reconciliation complexity (vendor vs inventory vs variance accounts).
• This impacts month-end close and downstream reporting where landed cost accuracy is required.

Current system behavior

• Landed cost uses a standard process: estimates are posted, then reversed and replaced by actuals at cost invoicing.
• Under Moving Average, the system blocks postings that would push a receipt’s remaining cost below zero (negative receipt cost safeguard).
• The system does not automatically cascade/rebalance adjustments across receipts after revaluation; users must handle it manually.

Requested enhancement

Introduce a supported capability to auto‑rebalance landed cost estimate→actual adjustments in Moving Average scenarios where prior revaluation or valuation changes cause an insufficient remaining value on the referenced receipt.