Packaging manufacturers occupy an odd middle ground in Acumatica implementations: part make-to-stock corrugated/converting operation, part make-to-order custom print run, often with the same plant running both models depending on the customer. The BOM and order-type configuration has to support both without forcing every job through the heavier make-to-order path.
Configuring both production models on one item class structure
Standard SKUs — stock corrugated boxes, generic mailers — run cleanest as make-to-stock: a Production Order type driven by MRP replenishment against forecast, standard BOM, standard costing. Custom print jobs — a specific customer's branded packaging, a one-off die-cut — are make-to-order, typically triggered directly from a Sales Order line via the "Create Production Order from Sales Order" flow, with the BOM built or cloned per job (often from a template BOM with print-plate and die-cut tooling as separate BOM lines so tooling cost is visible per job, not buried in overhead).
protected virtual void SOLine_RowPersisting(PXCache cache, PXRowPersistingEventArgs e)
{
var line = (SOLine)e.Row;
if (line.InventoryID != null && IsCustomPrintItem(line.InventoryID)
&& line.Operation == SOOperation.Issue)
{
// Force MTO production order creation instead of allocating from stock,
// even if the finished item class defaults to make-to-stock.
line.POCreate = true;
line.ProdOrdType = "MO"; // custom make-to-order type
}
}Tooling and setup cost: a BOM line, not a hidden overhead absorption
The single most common gap I fix on packaging implementations: die-cutting tools, print plates, and setup labor for a custom job get buried in general overhead instead of appearing as their own BOM/routing lines against the specific production order. That makes job profitability invisible — a $40,000 custom order with $8,000 of one-time tooling looks identical in the P&L to a $40,000 repeat order with none. Adding tooling as an explicit non-stock BOM component (or a fixed routing setup-time operation) fixes that at zero customization cost — it is a configuration decision on the BOM, not code.
Trim and co-product waste in sheet/roll converting
Corrugated and flexible-packaging converting produces trim waste as a near-constant percentage of input material — this is the same BOM by-product mechanism covered for plastics manufacturing (nominal-value by-product, credited back against material cost), and I configure it the same way: a by-product output line for trim/waste with a recovery value set low or zero, so it does not distort the primary product's allocated cost.
If a custom SKU is incorrectly flagged for MRP-driven replenishment (a make-to-stock item class default left unchanged), MRP will recommend production runs for a one-off customer job that should never repeat. Audit item class assignment for every custom/MTO finished item before go-live — this is a five-minute check that prevents a genuinely confusing planning report later.
Wrapping up
Packaging manufacturing on Acumatica works cleanly once you deliberately split make-to-stock and make-to-order item classes and order types, and once tooling/setup cost is modeled as its own BOM line rather than absorbed into overhead. Neither requires custom code — both require someone to make the configuration decision explicitly instead of accepting BOM defaults built for a simpler single-model shop.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.