A barcode can select a work order quickly, but it cannot decide which operation has been completed or how much output the production system should accept. A reliable shop-floor workflow keeps the order, operation, product, workstation, operator, quantity type and backend result together. Otherwise a correct scan can still create progress on the wrong step or count the same output twice.
This guide is for production supervisors, manufacturing IT teams, MES/ERP integrators and handheld-terminal buyers. Its numbers and identifiers are editorial examples, not a customer deployment or an AIDC GO device test. The handheld-terminal category, Integration Support and Contact are starting points for a documented hardware and interface review; they do not imply that AIDC GO supplies an MES or production-management application.
Select the production context before entering quantity
Treat the scanned code as a selector, not as a completion event. The application should resolve it to an explicit work order and then show the product, current operation, workstation or resource, planned quantity, previously accepted quantity and remaining quantity. The signed-in operator is another field; it must not be inferred from whichever badge or order was scanned most recently.
An order can contain several operations, and the same product can appear on more than one order. Require the operator to confirm the current operation rather than assuming that the next open operation is correct. If the workstation is not authorised for that operation, or the operation is not available under the selected system's sequencing rules, stop with a specific exception.
Microsoft's current production feedback documentation for Dynamics 365 Supply Chain Management distinguishes reporting time and quantities per job or operation from reporting the finished product on the last job or operation. That is a bounded software example, not a universal MES data model.
Keep planned, good, rejected and rework quantities distinct
Before designing the handheld screen, define what each quantity means in the chosen application. Planned quantity is a target. Good quantity records accepted output under the application's rule. Error, scrap or rejected quantity needs its own reason and may have different inventory or quality effects. Rework can be a separate order, operation, status or quantity depending on the configured system.
The Dynamics 365 production floor execution interface currently lets workers report good quantity from an active job and report scrap through a separate action with a reason. Its report-as-finished documentation also allows partial quantities and error quantities. Those facts support the need to preserve quantity type and operation context; they do not establish the same fields or arithmetic for another MES.
| Record element | Editorial value | Decision it supports |
|---|---|---|
| Work order | WO-4802 |
Identifies the production order, not the completed operation by itself. |
| Operation | OP-20 / final inspection |
Names the step receiving feedback. |
| Planned quantity | 50 each |
Provides the target; it is not automatically the quantity completed. |
| Good quantity this submission | 28 each |
Candidate accepted output for this operation. |
| Rejected quantity this submission | 2 each |
Candidate nonconforming output, with a required reason. |
| Client submission ID | WO-4802-OP20-S07 |
Lets the application query an uncertain attempt instead of blindly posting it again. |
Follow a partial-completion example
Assume work order WO-4802 plans 50 pieces. On the first shift, the operator selects operation OP-20, confirms workstation INS-04, and reports 30 pieces processed: 28 good and two rejected for the project's named inspection reason. These values are constructed for explanation.
In this example, the configured application accepts one feedback record containing the order, operation, workstation, operator, unit, 28 good, two rejected and submission ID WO-4802-OP20-S07. The screen then reads the accepted backend record and shows 20 planned pieces still unreported for this example. Another system might calculate remaining work differently, separate scrap into another transaction or require supervisor approval. Acceptance must use that system's documented rules rather than assuming good + rejected always drives remaining quantity.
The next shift reopens the same order. It must see the already accepted 30-piece event and the remaining work before entering anything. Scanning WO-4802 again does not authorise another 30-piece report. The warehouse quantity-entry guide explains unit-aware entry; production feedback adds operation, status and output-type meaning.
Recover an uncertain submission without adding output twice
Suppose the operator selects Submit, the network times out, and the handheld receives no final response. The honest state is submission outcome unknown. It is not safe to show success, but it is equally unsafe to create a new transaction immediately.
Keep the same submission identity and query the backend or message status. If the original event was accepted, display its server record and do not post again. If it was rejected, show the rejection and allow a corrected event under the application's rules. If no accepted event exists and the system permits retry, resubmit with the same idempotent identity or another documented duplicate-control mechanism. A new button click with a new identity can turn one physical result into two production records.
The offline and unconfirmed-transaction guide develops this distinction for mobile capture. The duplicate-read guide addresses repeated decode events; neither a scanner debounce setting nor an on-screen beep proves that the MES accepted exactly one production transaction.
Route partial, wrong-operation and cross-shift exceptions
A production screen should expose a safe branch for each material difference.
– Partial completion: record the accepted quantity without silently marking the job complete. Show the remaining quantity under the selected system's rule. – Wrong operation: stop before posting, retain the scanned order for review and require an authorised operation selection. – Wrong workstation or operator: do not borrow the previous task's context. Reconfirm the resource and signed-in worker. – Rejected output: capture the project's reason and approval path instead of subtracting it invisibly from good quantity. – Rework: link the correction to the original result and the authorised rework route. Do not overwrite the first record as though it never occurred. – Cross-shift continuation: read back accepted progress and task status for the incoming operator; a handover note alone is not the production ledger. – Duplicate scan: reveal the existing active or completed feedback event before creating another.
The component-traceability guide links actual parts to a finished unit. This guide asks a different question: which operation received which quantity feedback, and what did the production system accept?
Verify the backend record, not only the handheld state
An acceptance test should compare four layers: the scanned selector, the handheld's resolved task, the submitted payload and the backend record. Capture a redacted example containing order, operation, workstation, operator, good quantity, rejected quantity, unit, reason, client submission ID, server record ID, acceptance state and timestamps with defined meanings.
Test a correct partial report, a wrong operation, a repeated scan, a timeout after server acceptance, a rejected submission, a cross-shift continuation and a rework correction. The Kanban replenishment guide separates a scanned signal from the replenishment task it creates. Production reporting needs the same discipline but owns a different record and different quantity meanings.
Purchase the complete reporting path
Evaluate the label at the real workstation, the handheld controls used with gloves, screen feedback, charging arrangement and the exact integration method. Then test the configured application against the selected MES/ERP version. Barcode performance, application validation and server-side transaction control are separate evidence sets.
Bring sample order labels, the operation model, quantity definitions, units, reason codes, worker and workstation rules, shift handover, offline behavior, retry contract, backend readback and expected audit record to the project review. The stock-transfer guide shows why dispatch and receipt must not be collapsed; likewise, selecting a production job and completing its feedback are different events.
Ask AIDC GO only for documented model and interface material relevant to the proposed handheld configuration. The manufacturing application owner remains responsible for job eligibility, quantity arithmetic, quality decisions, duplicate control and final acceptance. A defensible result is not “the order scanned.” It is one accepted production record tied to the intended order, operation and physical output.