Manufacturing (AM) is the module where "extension" most often means "make the system model a production process it wasn't originally configured for" — a routing with an unusual sequence, a costing method specific to the industry, or a shop floor step Acumatica's stock flow doesn't capture cleanly.
Core DACs and screens
A production order is AMProdItem with operations on AMProdOper; the bill of material and routing that generate them live on BOM and routing maintenance screens, typically backed by DACs in the AMBom*/AMRoute* family. Material transactions post through something like AMMTran, and labor/time transactions through a corresponding operation transaction table. The core graphs are ProductionOrderEntry (or similarly named) for the production order and separate maintenance graphs for BOM and routing.
Extension points
Custom routing logic — an extra QA step that must be recorded before an operation can be marked complete, or a conditional step that only applies to certain item classes — is usually a graph extension on production order/operation entry, checking a custom field or a lookup against the routing definition before allowing an operation status change. Costing customizations (a blended standard/actual method, industry-specific overhead allocation) are higher-risk because they interact with both inventory valuation and GL, similar to the caution warranted in Fixed Assets and GL work.
If the plant uses backflushing (material consumption calculated automatically from the BOM as operations complete, rather than issued manually), a customization that adds a manual material entry step alongside it will double-count consumption unless it explicitly disables backflush for that material or operation. This is one of the more common and hardest-to-spot bugs in AM customizations because the error only shows up in an inventory variance report weeks later, not at the point of entry.
A realistic scenario: mandatory QA checkpoint
A frequent AM customization: certain item classes require a quality inspection record before the next routing operation can start, which isn't a stock hard-gate in the base routing engine.
public class ProductionOrderEntry_QAGate_Extension : PXGraphExtension<ProductionOrderEntry>
{
protected virtual void AMProdOper_RowPersisting(PXCache sender, PXRowPersistingEventArgs e)
{
var oper = (AMProdOper)e.Row;
if (oper == null || oper.Completed != true) return;
bool requiresQA = ItemRequiresQAInspection(oper.InventoryID);
if (requiresQA)
{
bool hasInspection = QAInspections.Select(oper.OrderID, oper.OperationID)
.RowCast<QAInspection>().Any(q => q.Passed == true);
if (!hasInspection)
{
sender.RaiseExceptionHandling<AMProdOper.completed>(oper, oper.Completed,
new PXSetPropertyException("A passed QA inspection is required before this operation can be marked complete.", PXErrorLevel.Error));
}
}
}
public PXSelect<QAInspection> QAInspections;
}Field and DAC names in the AM module vary more than most between Acumatica versions, since manufacturing edition history is more fragmented than core financials — confirm the operation completion field and transaction DAC names against the specific version before implementing this pattern.
WIP and cost rollup
Any change touching material or labor transactions feeds work-in-process valuation, which rolls up into the finished item's cost when the production order closes. A customization tested only against a single-level BOM can behave differently against a multi-level BOM where a sub-assembly's cost rollup happens before the parent's — test with at least one multi-level assembly before trusting the numbers.
Testing considerations
Test against a production order that uses backflushing and one that doesn't, and against at least one multi-level BOM. AM bugs concentrate at the boundary between manual and automatic material consumption, and at cost rollup through nested assemblies — a flat, single-level, manually-issued test order won't expose either.
Wrapping up
Manufacturing extensions carry the same costing risk as GL and Fixed Assets work, compounded by routing and BOM complexity. Respect backflush accounting, verify DAC and field names against the specific AM version in play, and test through a full multi-level production cycle before shipping.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.