Inventory Adjustments (IN301000) is the screen that reconciles what the system thinks is on the shelf with what's actually there, and it's one of the few transaction screens where the customization requests are less about workflow and more about cost accuracy. The graph is INAdjustmentEntry; the header/detail pair is INRegister/INTran, the same pair used by receipts, issues, and transfers — INRegister.DocType is what distinguishes an adjustment from every other inventory movement.
What an adjustment actually does
An adjustment can increase quantity (a positive adjustment, effectively a receipt without a PO), decrease quantity (a negative adjustment, consuming existing cost layers), or move cost without moving quantity (a cost adjustment). Which of these applies is determined by the sign and fields entered on the line, not by a separate document type selector — this is the detail that trips up new users expecting three distinct screens.
Key tabs
- Details — the INTran grid: item, warehouse/location, quantity, and (for negative adjustments against FIFO/Specific-cost items) the cost layer being consumed.
- Financial — the posting class-derived GL accounts for inventory and adjustment/variance, overridable per line if the posting class allows it.
Extending INAdjustmentEntry
The most common customization is requiring a reason code or approval before a negative adjustment above a value threshold posts — Acumatica ships reason codes as a feature, but enforcing that one is mandatory above a dollar amount, or routing it through an approval map, is custom logic on the graph extension.
public class INAdjustmentEntry_Extension : PXGraphExtension<INAdjustmentEntry>
{
protected virtual void INTran_RowPersisting(PXCache cache, PXRowPersistingEventArgs e)
{
var line = (INTran)e.Row;
if (line == null || line.InvtMult != -1) return; // only negative (outbound) lines
decimal extCost = (line.UnitCost ?? 0m) * (line.Qty ?? 0m);
if (extCost >= 5000m && string.IsNullOrEmpty(line.ReasonCode))
throw new PXSetPropertyException("Reason code is required for write-offs over $5,000.");
}
}Custom fields and tabs via the Customization Project Editor
Adding a field to the Details grid (an internal "adjustment category" separate from reason code, for example) is a straightforward DAC extension on INTran. Because INTran is shared across every inventory document type, scope any custom field's visibility to the Adjustment screen specifically, or it will unexpectedly show up on Receipts and Issues too.
Common validation and event-handler use cases
Beyond reason-code enforcement: defaulting a subaccount segment from the item's product category rather than the posting class default, blocking adjustments to items under active cycle count, and triggering a notification (via a business event or a direct call from the graph extension) when a single adjustment exceeds a value threshold, so finance sees large write-offs before month end rather than during it.
Gotchas
The cost method assigned to an item (FIFO, Average, Specific) determines what a negative adjustment actually consumes, and that method is effectively locked once transactions exist against the item — a customization that assumes Average-cost behavior will misbehave silently on a FIFO item with multiple open cost layers. Adjustments don't require a linked Sales or Purchase document, which means the audit trail for "why was this adjusted" lives entirely in the reason code and description fields — if a customization needs a stronger audit trail, that has to be added explicitly, it isn't implicit in the document type. And negative adjustments on lot/serial-tracked items require selecting which specific lot/serial is being removed; a customization that bulk-imports adjustments without lot/serial detail will fail validation on any tracked item.
A pure cost adjustment (revaluing existing stock without changing quantity) uses different fields on the same INTran row than a quantity adjustment. Customizations that generate adjustment lines programmatically need to set the right combination deliberately — mixing the two on one line produces a document that looks valid but posts incorrectly.
Wrapping up
Inventory Adjustments looks like the simplest inventory screen and is, in practice, the one most sensitive to the item's underlying cost method. Customizations that add friction (reason codes, thresholds, notifications) are welcome and safe; customizations that assume a uniform costing behavior across all items are the ones that come back as a support ticket during the next physical count.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.