Acumatica Stock Item Screen — A Deep Dive

Stock Items (IN202500) is the master data screen every inventory transaction ultimately depends on. The graph is InventoryItemMaint, and the DAC is InventoryItem — the same DAC used for non-stock items, distinguished by ItemType. Most of a stock item's default behavior is inherited from its assigned Item Class at creation time, following the same one-time-inheritance pattern seen on Customer and Vendor classes.

Item class sets the defaults, once

Posting class (which drives GL account defaults for inventory, COGS, and variance), valuation method, and UOM defaults all come from the Item Class when a new stock item is created. Changing the Item Class's settings afterward does not retroactively update existing items — a customization or a well-intentioned admin "fixing" the item class configuration will not fix items already created against the old settings.

Key tabs

• General — identity, item class, and the base UOM.
• Price/Cost — valuation method (FIFO, Average, Standard, Specific), default price, and last cost.
• Warehouse — per-warehouse replenishment settings (min/max, reorder point), which can differ from the item's global defaults.
• Vendor — preferred vendor and vendor-specific pricing/lead time, feeding PO defaults.
• GL Accounts — overrides to the posting-class-derived accounts, when an item needs different GL treatment than its class.
• Attributes — the free-form classification framework, frequently extended in customizations that need structured item metadata beyond what ships out of the box.

Extending InventoryItemMaint

Cost method is effectively locked in once transactions post against an item — changing it after the fact requires careful data migration, not a screen edit, so a common and legitimate customization is blocking the cost-method field from being changed at all once any transaction history exists, catching what the base screen might otherwise allow through a warning alone.

public class InventoryItemMaint_Extension : PXGraphExtension<InventoryItemMaint>
{
    protected virtual void InventoryItem_ValMethod_FieldVerifying(PXCache cache,
        PXFieldVerifyingEventArgs e)
    {
        var row = (InventoryItem)e.Row;
        if (row?.InventoryID == null) return;

        bool hasHistory = PXSelect<INTran,
            Where<INTran.inventoryID, Equal<Required<INTran.inventoryID>>>>
            .Select(Base, row.InventoryID).Any();

        if (hasHistory)
            throw new PXSetPropertyException("Valuation method cannot change once transactions exist for this item.");
    }
}

Custom fields and tabs via the Customization Project Editor

Adding a field to General or Attributes is routine. A new tab (a "Compliance" tab for regulated goods, for instance) is common on this screen because item master data frequently needs to carry structured information no built-in tab covers — implemented as a related DAC keyed on InventoryID with its own PXTab in the graph extension.

Common validation and event-handler use cases

Beyond cost-method locking: enforcing that a UOM conversion factor exists before an item can be used on a Sales Order in a non-base unit, defaulting warehouse-specific reorder points from a formula rather than manual entry, and validating that items in a regulated product category have required attributes populated before they can be marked Active.

Gotchas

UOM conversions defined incorrectly (or missing) don't fail loudly until someone tries to transact in the affected unit, at which point the error surfaces on a Sales Order or Receipt screen far from where the actual problem lives on the item master. Warehouse-level overrides on the Warehouse tab take precedence over item-level defaults, which a customization reading only the item-level fields will miss. And because InventoryItem is shared between stock and non-stock items, a customization that assumes every InventoryItem row has valuation/costing fields populated will misbehave when it encounters a non-stock or service item mixed into the same report or process.

Wrapping up

Stock Items is master data in the truest sense — its class-driven defaults and cost-method rigidity mean the safest customizations reinforce those constraints rather than work around them. Lock down what shouldn't change after the fact, and remember every InventoryItem-based customization has to coexist with the non-stock items sharing the same table.