The Production Order screen (AM201500) is the operational center of Acumatica's Manufacturing Edition — it's where a BOM and a routing become an actual work order with material lines, operation lines, and a status that drives shop-floor behavior. The graph is AMProdEntry, and the header DAC, AMProdItem, ties together the order type, the produced item, quantity, and the order's current status.
Order types and the status lifecycle
A production order carries an Order Type (Regular, Disassembly, Teardown, etc. depending on configuration) that determines which material and operation logic applies. Status moves through a defined lifecycle — Planned, In Process, Completed, Closed — and this status gates what's editable: once an order moves to In Process, material and operation lines are typically locked down from casual editing because the shop floor may already be transacting against them. A customization that lets a user freely edit BOM-derived material lines on an In Process order is usually working around a control that exists for a reason — inventory and cost variances get harder to explain once actuals and plan diverge silently.
Material and Operation tabs
The Details tab holds material lines (AMProdMatl), each pointing back to a BOM operation sequence; the Operations tab holds labor/machine steps (AMProdOper) pulled from the routing. These two tabs are linked by operation sequence number — a material line consumed "at" operation 20 expects operation 20 to exist on the routing side, and a common data problem after a BOM or routing edit is a material line left pointing at an operation sequence that no longer exists on the order, which orphans it from earnings and backflush logic.
Backflushing vs. manual issue
Whether material gets consumed automatically when an operation is reported complete (backflush) or requires an explicit Issue transaction is set at the BOM operation level, not globally, so a single production order can mix both behaviors across its material lines. When debugging "why didn't inventory move when I completed this operation," the first thing to check is the backflush flag on that specific BOM line — it's easy to assume a whole order is backflush or manual when it's actually mixed.
Increasing a production order's planned quantity after it's already been released doesn't automatically rescale material line quantities that were already manually adjusted from their BOM-derived defaults — only lines still tied to the BOM ratio recalculate. If a planner bumped the quantity to cover a shortage and material didn't move proportionally, check whether the affected material lines had been manually overridden earlier in the order's life.
Common customization points
Graph extensions on AMProdEntry are the usual approach — a RowPersisting handler enforcing a business rule like "no production order can be released without an assigned work center on every operation line," or a custom field on AMProdItem (added via DAC extension) capturing something like a customer job number for make-to-order manufacturing, surfaced on a custom tab. Another common pattern is an action button added to the toolbar that triggers a custom validation or external system notification (e.g., pushing the order to a scheduling system) at the point of Release.
Cost rollup and where variance actually posts
When a production order completes, actual costs (material, labor, machine, overhead per the routing) are compared against the BOM/routing-derived standard cost, and the difference posts as variance — the specific GL accounts depend on your posting class configuration, not something visible from this screen directly. Reporting on "what did this job actually cost" needs to join AMProdItem against the cost transaction tables, not just read the header quantity and unit cost, since those header fields reflect planned values more than realized ones in some configurations.
Wrapping up
Production Order is where planning data (BOM, routing) turns into shop-floor reality, and most of the gotchas here come from that transition — status gating what's editable, backflush behavior varying line by line, and quantity changes not always propagating the way a planner expects. Before adding validation or automation on this screen, trace whether the rule needs to apply at the order header, the material line, or the operation line, because those three levels behave differently through the status lifecycle.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.