Acumatica Shop Floor Control — 2025 R2 Changes

Every R2 release moves more of Acumatica toward the Modern UI, and the manufacturing data-collection screens are squarely in the blast radius. If you've customized clock entry, labor transactions, or the shop floor data-collection flow, the 2025 R2 cycle is one you want to test against early — not because anything is broken, but because the surface your customizations attach to keeps shifting from classic ASPX pages to Modern UI (TypeScript/HTML) screens.

This post covers what changed in the shop floor area, what it means for existing customizations, and how I approach validating a manufacturing instance against an R2 upgrade.

The direction of travel

Acumatica has been rewriting screens onto the Modern UI stack release by release: server-side graphs stay the same, but the presentation layer becomes a TypeScript screen definition instead of an ASPX page with a customization-project layout diff. Shop floor and warehouse data-collection screens are priority targets because they're used on scan guns and tablets, where the Modern UI's responsive rendering genuinely matters. In the 2025 cycle, more of the production clock-in/clock-out and material reporting flow renders through the new stack, and the scan-driven workflows continue converging on the pattern established by the WMS pick-pack-ship screens: a scan input box driving a state machine, rather than a grid you type into.

What survives an upgrade and what doesn't

The good news: business-logic customizations survive. Graph extensions on ClockEntry, LaborEntry, or the production maintenance graphs, DAC extensions adding fields to AMProdItem or the transaction DACs, event handlers, custom validations — all of that is presentation-independent and carries forward exactly as it does on any other screen.

What doesn't survive cleanly:

• ASPX layout changes. If your customization project contains page-level diffs (moved fields, added tabs) against a screen that got rewritten to Modern UI, those diffs are ignored when the new screen renders. The field still exists on the DAC; it just stops appearing until you add it to the Modern UI screen definition.
• Control-level JavaScript. Anything injected into the classic page — custom PXJavaScript, client-side hacks against the old grid — is gone. This is where I've seen barcode-scanning wedges break, where someone had wired a scanner to a specific classic input control.
• Automation steps on screens that moved to the workflow engine in earlier releases should already be converted, but manufacturing screens that only recently gained workflow support need their old automation-step customizations re-expressed as workflow customizations.

Re-adding fields on a Modern UI screen

When a screen you extended goes Modern, custom fields get re-declared in the screen's extension files instead of a layout diff. The pattern is an HTML include plus a TypeScript extension of the generated screen class:

import { AM315000 } from '../AM315000';
import { PXFieldState, featureInstalled } from 'client-controls';

export interface AM315000_Ext extends AM315000 {}
export class AM315000_Ext {
    // custom field added via DAC extension on the server
    UsrOperatorBadgeID: PXFieldState;
}

<field name="UsrOperatorBadgeID"
       wg-container="TransactionsForm"></field>

It's less alien than it looks: the server still drives everything through the same graph and DAC metadata, and the TypeScript layer is mostly declarative placement. But it is a different skill than dragging fields in the classic screen editor, and it belongs in source control next to your C#.

How I test a manufacturing R2 upgrade

1. Restore production onto a sandbox, upgrade, publish customizations, and read the publish log for every warning mentioning an AM screen.
2. Walk the physical flow with a scanner in hand: release a production order, clock in, issue materials, report quantity at an operation, move, clock out, close. Screens lie; the scan gun doesn't.
3. Check the mobile app screens for production if you use them — the mobile site map definitions occasionally need updates when the underlying screen's containers change names.
4. Re-run one full standard cost cycle and one MRP regeneration on the sandbox. Shop floor changes rarely touch these, but manufacturing upgrades have a way of surprising you at the edges.

Should you adopt the new screens immediately

If Acumatica still offers the classic rendering toggle for a given screen, you can defer — but I've stopped recommending deferral beyond one release. The Modern UI versions of the data-collection screens are genuinely better on handheld hardware (bigger touch targets, faster round-trips, saner focus handling for scan input), and the longer you wait, the more customization debt accumulates against a rendering path that is clearly end-of-life. Budget the conversion once, do it deliberately, and stop paying the toggle tax.

Wrapping up

2025 R2's shop floor changes are evolution, not revolution: same graphs, same DACs, new presentation. Your C# survives; your layout diffs and client-side hacks are what need attention. Inventory your AM-screen customizations before you upgrade, test with real hardware, and treat the Modern UI conversion as a one-time cost worth paying — because the classic shop floor screens are not coming back.