Acumatica Bill of Material Screen — A Deep Dive

Bill of Material (AM208000) belongs to Acumatica's Manufacturing edition and defines how a finished item is built from components and operations — it isn't available at all in instances without Manufacting Management licensed, which is worth confirming before assuming this screen applies to a given implementation. The graph is BOMMaint, backed primarily by AMBomItem for the header, AMBomOper for operation steps, and material lines nested under each operation.

BOMs are versioned, not edited in place

A BOM isn't a single static record — it's a revision, with an effective date range, and Acumatica expects you to create a new revision rather than freely editing an active one that's already been used in production orders. Customizations that treat a BOM ID as a stable pointer to "the current recipe" will get inconsistent results unless they explicitly resolve the active revision for a given date, the same way the base engine does.

Key tabs

• BOM Details / Operations — the sequenced list of operations (work centers, run/setup time) each with their own material lines, since materials in a manufacturing BOM are typically consumed at a specific operation rather than all at once.
• Attributes — engineering/classification metadata, frequently extended in practice since standard attributes rarely cover everything an engineering team wants to track.
• Where Used — reverse lookup showing which parent BOMs consume this item as a component, essential for impact analysis before changing a shared sub-assembly.

Extending BOMMaint

A frequent request is validating that a new BOM revision doesn't reference a component that's been discontinued, or that estimated costs stay within a tolerance of the previous revision unless explicitly overridden — a safeguard against fat-fingered quantity or UOM entry silently blowing up a standard cost calculation.

public class BOMMaint_Extension : PXGraphExtension<BOMMaint>
{
    protected virtual void AMBomItemDet_RowPersisting(PXCache cache, PXRowPersistingEventArgs e)
    {
        var line = (AMBomItemDet)e.Row;
        if (line == null) return;

        InventoryItem comp = PXSelect<InventoryItem,
            Where<InventoryItem.inventoryID, Equal<Required<InventoryItem.inventoryID>>>>
            .Select(Base, line.InventoryID);

        if (comp?.ItemStatus == "Discontinued")
            throw new PXSetPropertyException("This component is discontinued and cannot be added to a new BOM revision.");
    }
}

Custom fields and tabs via the Customization Project Editor

Adding a field to the header or a material line is a standard DAC extension, scoped to the relevant AM DAC (AMBomItem for header-level, AMBomItemDet for material-line-level). A dedicated engineering-change tab is common in regulated manufacturing environments, usually modeled as a related DAC tied to the BOM revision key.

Common validation and event-handler use cases

Beyond discontinued-component checks: enforcing that a new revision has an engineering sign-off custom field populated before it can move to Active status, validating operation sequence numbers don't create circular or invalid routing when combined with the Work Center screen's data, and recalculating rolled-up standard cost automatically when a component's cost changes rather than waiting for a manual cost update run.

Gotchas

Because production orders reference a specific BOM revision at the time they're created, changing or deactivating a revision after production orders already exist against it doesn't retroactively change those orders — which is usually the correct behavior but surprises people expecting a BOM edit to apply everywhere immediately. Nested BOMs (a sub-assembly that is itself a manufactured item with its own BOM) mean a naive "list all components" report needs to recurse rather than read one level, or it will undercount true material requirements. And this entire screen is a no-op in editions without Manufacturing licensed — a customization built and tested only against a Manufacturing-enabled tenant can fail confusingly if deployed somewhere that module isn't active.

Wrapping up

Bill of Material is a versioned, hierarchical structure disguised as a simple parts list, and its customizations need to respect both properties — resolve the active revision explicitly, and recurse through nested BOMs rather than assuming a flat component list.