Acumatica Non-Stock Item Screen — A Deep Dive

Non-Stock Items (IN202000) shares its underlying DAC, InventoryItem, with Stock Items — the distinction lives entirely in ItemType. What looks like a separate screen is really a filtered, differently-laid-out view over the same table, configured for items that don't carry quantity-on-hand or cost-layer tracking: services, charges, labor, and freight items.

Four flavors of non-stock, and why the type matters

Non-Stock, Service, Charge, and Labor item types aren't cosmetic labels — each drives different default behavior on the screens that consume them. A Charge-type item behaves differently on an AP Bill or Sales Order line than a Service item does, particularly around whether it expects quantity at all versus a flat amount. Picking the wrong type for a given use case is a common setup mistake that surfaces later as odd behavior on unrelated transaction screens, not as an error on this one.

Key tabs

• General — identity, item class, and item type, which is fixed at creation the same way it is for stock items.
• Price/Cost — default price and cost, but no valuation method — non-stock items don't carry cost layers.
• GL Accounts — the accounts a non-stock item posts to, often more heavily relied upon here than for stock items since there's no inventory asset account in the picture, just direct expense/income posting.

Extending the same graph, differently

Because this screen uses the same InventoryItemMaint graph as Stock Items, a graph extension written for one needs to explicitly check ItemType before applying logic that only makes sense for one side — a valuation-method lock like the one useful on Stock Items is meaningless here and shouldn't fire.

public class NonStockItemMaint_Extension : PXGraphExtension<InventoryItemMaint>
{
    protected virtual void InventoryItem_RowPersisting(PXCache cache, PXRowPersistingEventArgs e)
    {
        var row = (InventoryItem)e.Row;
        if (row == null || row.ItemType == INItemTypes.StockItem) return; // stock items handled elsewhere

        if (row.ItemType == INItemTypes.ServiceItem && row.SalesAcctID == null)
            throw new PXSetPropertyException("Service items require a default sales account.");
    }
}

Custom fields and tabs via the Customization Project Editor

Adding a field to General or GL Accounts is a standard DAC extension on the shared InventoryItem DAC. Any field visible on both Stock and Non-Stock screens should be scoped with an explicit condition (an ItemType check in the layout or a PXUIField visibility rule) rather than assumed to make sense identically on both — a field like "reorder point" is meaningless for a Service item and confusing if left visible.

Common validation and event-handler use cases

Beyond default-account enforcement: validating that Freight/Charge items used on Sales Orders map to a consistent revenue account regardless of who created the sales order, blocking Labor-type items from being added to Purchase Orders if labor is only meant to flow through time entry, and defaulting a Kit item's component BOM-like structure (Acumatica's kit assembly, distinct from Manufacturing's BOM) when a non-stock kit item is created.

Gotchas

A non-stock item never has quantity-on-hand, which means inventory availability checks and reorder logic written generically against InventoryItem need explicit exclusion of non-stock types, or they'll produce nonsensical "zero on hand" warnings for items that were never meant to be tracked that way. Kit items (a non-stock item type with a defined set of components) look similar to a Manufacturing BOM at a glance but are a distinct, simpler mechanism — conflating the two in a customization leads to code that tries to use BOM APIs against a kit structure that doesn't support them. And GL account defaults matter more here than on stock items, since there's no inventory asset account buffering the posting — a missing default account on a Charge item fails loudly the first time it's used on a document, not at creation time.

Wrapping up

Non-Stock Items is a view, not a separate entity, and its customizations need to respect that shared DAC by scoping logic to the relevant item types explicitly. Get the item type right at setup, and most of the screen's quirks resolve themselves before they reach a developer.