Acumatica · Customization

Acumatica Shop Floor — Extension Patterns

Acumatica Shop Floor — Extension Patterns is one of those Acumatica customisations that every team eventually needs and almost no team does well the first time.

John Kihiu12 min read

Shop floor data collection is where manufacturing customization meets the physical plant — barcode scanners, time clocks, and operators who need a fast, constrained interface, not a full ERP screen. Extension work here is as much about the data collection surface as it is about the underlying production DACs.

Core DACs and screens

Labor and time transactions against a production operation typically write to an operation transaction DAC alongside AMProdOper, often through a dedicated shop floor time/clock screen distinct from the full production order entry screen — designed to be used at a shared terminal or handheld device rather than a desk. Material consumption at the shop floor level ties back to AMMTran and, if backflushing is configured, may not require a manual entry at all.

Extension points

Shop floor customizations are frequently about the data capture interface: adding a barcode-scannable field, simplifying the screen to fewer required inputs for a specific operation type, or adding a scrap/rework quantity capture that the stock clock screen doesn't separate out clearly. These are usually graph extensions on the shop floor time entry graph plus layout changes, rather than changes to the underlying production DACs themselves.

Barcode input needs validation the same as any manual entry

A barcode scan is just a fast way to populate a field — it doesn't validate itself. A customization that trusts scanned input without the same field-level validation a manual entry would get (valid operation ID, valid employee ID, item still open on the order) will happily record a scrap transaction against a closed order or a mis-scanned item, and it'll do it fast, which is worse than a slow, correct mistake.

A realistic scenario: scrap and rework capture

A frequent shop floor customization: the stock clock-in/clock-out screen tracks good quantity completed but doesn't cleanly separate scrap from rework, and the client needs both tracked distinctly for yield reporting.

C# · SHOP FLOOR ENTRY EXTENSION
public class ShopFloorEntry_ScrapRework_Extension : PXGraphExtension<ShopFloorTimeEntry>
{
    #region AMProdOperExt
    public class AMProdOperExt : PXCacheExtension<AMProdOper>
    {
        [PXDBQuantity]
        [PXUIField(DisplayName = "Scrap Qty")]
        public decimal? ScrapQty { get; set; }
        public abstract class scrapQty : PX.Data.BQL.BqlDecimal.Field<scrapQty> { }

        [PXDBQuantity]
        [PXUIField(DisplayName = "Rework Qty")]
        public decimal? ReworkQty { get; set; }
        public abstract class reworkQty : PX.Data.BQL.BqlDecimal.Field<reworkQty> { }
    }
    #endregion

    protected virtual void AMProdOper_RowPersisting(PXCache sender, PXRowPersistingEventArgs e)
    {
        var oper = (AMProdOper)e.Row;
        var ext = sender.GetExtension<AMProdOperExt>(oper);
        decimal scrap = ext?.ScrapQty ?? 0;
        decimal rework = ext?.ReworkQty ?? 0;

        if (scrap < 0 || rework < 0)
        {
            sender.RaiseExceptionHandling<AMProdOper.completeQty>(oper, oper.CompleteQty,
                new PXSetPropertyException("Scrap and rework quantities cannot be negative.", PXErrorLevel.Error));
        }
    }
}

As with the earlier manufacturing post, exact DAC and graph names for shop floor entry vary meaningfully across Acumatica versions and manufacturing edition history — this sketches the pattern (extend the operation record, validate before persisting, keep scrap and rework distinguishable) rather than a guaranteed drop-in against any specific version.

Terminal and kiosk-mode considerations

Shop floor screens are frequently run in a kiosk or shared-terminal mode where the logged-in user isn't necessarily the person performing the transaction — if a customization needs to attribute a transaction to a specific operator rather than the terminal's login, that has to be captured explicitly (badge scan, PIN entry) as part of the transaction, not inferred from session identity.

Testing considerations

Test on the actual device or terminal configuration used on the floor, not just a desktop browser — barcode scanner input often behaves like fast keyboard entry with a trailing character (like Enter) that can interact unexpectedly with grid navigation or field validation timing that doesn't show up when typing manually.

Wrapping up

Shop floor extensions live where operational speed and data integrity are in tension — validate scanned input as rigorously as manual input, capture operator identity explicitly in shared-terminal setups, and test on the real hardware before trusting a customization that only ran clean on a developer's desktop browser.

John Kihiu
Acumatica ERP Developer · Laravel Engineer

Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.