Acumatica Inventory Issues and Receipts — Extensions

Issues and receipts are the two transaction types that actually move inventory quantity and cost, which makes them a more delicate extension target than they first appear — every issue and receipt eventually reconciles against a GL posting, and a customization that gets the timing or the cost layer interaction wrong shows up as a variance report headache weeks later, not an immediate error.

Core DACs and screens

Both flow through INTran, distinguished by transaction type, with receipts entered on the Receipts screen (IN301000-ish range) via INReceiptEntry and issues on the Issues screen via INIssueEntry. Both post to a batch (INRegister) on release, which is what ultimately generates the GL entries for the inventory and offset accounts.

Extension points

Custom validation — requiring a reason code on issues above a quantity threshold, enforcing a specific location for receipts of a certain item class — is standard RowPersisting/field-verifying work on INTran. Where it gets more delicate is anything touching cost: a customization that needs to override unit cost on a receipt (say, applying a landed-cost estimate before the actual landed cost allocation runs) has to interact correctly with whichever valuation method the item uses, since FIFO and average cost items carry cost forward completely differently.

A realistic scenario: mandatory reason on large adjustments

A frequent customization: any inventory issue exceeding a threshold percentage of on-hand quantity requires a reason code and a supervisor's electronic sign-off before it can be released, to catch data-entry errors and shrinkage before they hit the books.

public class INIssueEntry_LargeAdjustmentGate_Extension : PXGraphExtension<INIssueEntry>
{
    protected virtual void INTran_RowPersisting(PXCache sender, PXRowPersistingEventArgs e)
    {
        var line = (INTran)e.Row;
        if (line == null || line.TranType != INTranType.Issue) return;

        decimal? onHand = GetQtyOnHand(line.InventoryID, line.SiteID);
        if (onHand.GetValueOrDefault() == 0) return;

        decimal pctOfOnHand = (line.Qty ?? 0) / onHand.Value;
        if (pctOfOnHand > 0.25m && string.IsNullOrEmpty(line.ReasonCode))
        {
            sender.RaiseExceptionHandling<INTran.reasonCode>(line, line.ReasonCode,
                new PXSetPropertyException("Issues over 25% of on-hand quantity require a reason code.", PXErrorLevel.Error));
        }
    }
}

The supervisor sign-off half of this requirement is better implemented through the Approval Maps engine attached to the issue document, once the reason-code gate above establishes when an approval should even be required — keep the "is this unusual" detection and the "who has to approve it" routing as separate concerns.

Interaction with landed cost and PO receipts

Receipts linked to a purchase order interact with landed cost allocation (freight, duty, and other charges apportioned across receipt lines) which runs as a separate step after the physical receipt. A customization that overrides unit cost directly on the receipt line risks being silently overwritten once landed cost allocation runs — confirm the sequencing before assuming a custom cost override survives to the final posted cost.

Testing considerations

Test against both FIFO and average-cost items, and against a receipt that has pending landed cost allocation, since these are the two conditions most likely to expose a gap between what a custom validation assumes about "current cost" and what the system actually has at that point in the transaction lifecycle.

Wrapping up

Issue/receipt customizations are mostly disciplined validation work, with the one real hazard being cost interaction — check whether reason codes already solve the requirement before adding custom fields, and be explicit about how a customization sequences against landed cost allocation if it touches unit cost at all.