When implementing a manufacturing daily report approval workflow, moving a paper form to a tablet is only the first step. The harder question is who confirms each production result, when it becomes final, and how a correction reaches ERP or MES after approval. This guide helps factory supervisors, production control, quality, and IT teams in Thailand define the approval states, revision trail, daily cutoff, exception handling, integration contract, RFP, and FAT/SAT tests. Quantities used below are illustrative, not industry benchmarks or legal requirements.
Digitizing a daily report is different from confirming production actuals
Electronic entry can reduce paper collection, transcription, and illegible handwriting. It can also spread an incorrect quantity quickly if entry immediately changes inventory. Good output, scrap, rework, downtime, and material consumption may have different owners and checks. A worker may submit output, a supervisor may compare it with the machine and lot record, and production control may verify the order before ERP posting. “Entered” and “confirmed” therefore need separate meanings.
Our guide to manufacturing daily report digitization covers entry and use of report data. Our guide to shop floor production actuals collection covers where the figures originate. This article focuses on what happens after collection: approval, return for correction, cutoff, revision, and downstream acceptance.
Microsoft’s manufacturing execution documentation describes worker registrations passing through approval and transfer to related modules. It is an example of one product, not proof that every ERP provides the same feature. Ask each vendor to demonstrate which data remains provisional before approval and exactly when transfer occurs. Source: Microsoft Learn, Registration for manufacturing execution.
Define the record being approved
A paper report may be one sheet, while the controlled system record should usually be finer grained. A candidate key includes plant, line or machine, production order, operation, shift, production date, item or lot, and report type. Adapt it to the process so that each approved record is uniquely identifiable. If a single signature approves an entire plant report, a later correction to one operation can unintentionally reopen unrelated records.
Use explicit states such as Draft, Submitted, Under review, Returned, Approved, Awaiting transfer, Accepted by ERP, Correction requested, Corrected, and Cancelled. The labels matter less than authorized transitions and their evidence. Approval and ERP acceptance must remain separate: an approved entry can wait in a failed interface queue. A green check on the screen should have one unambiguous business meaning.
Store production date separately from entry timestamp. A night shift crossing midnight needs a plant shift calendar that assigns events to a production date. A delayed entry may refer to yesterday’s production even though it was submitted today. The terminal and server must apply the same rule, and historical entries must retain both event time and recording time.
What the supervisor should check
Do not define approval as “look at all numbers.” Specify checks for the active order, operation sequence, good/scrap/rework relationships, working time, downtime reason, lot identity, previous-operation receipt, and machine counter variance. A system can surface deterministic exceptions, leaving the supervisor to judge the cause. The approval queue should show age, cutoff proximity, variance type, and delegated owner.
Where a supervisor is absent, delegated approval needs a scope, start and end time, and reason. A small site may allow one person to enter and approve some low-risk records while requiring a second check for records that affect inventory or shipment. Document that exception explicitly. A returned record should identify the exact line, requested change, reason, and deadline. Resubmission should display a before-and-after comparison rather than silently replacing the first value.
Use rule-based approval to isolate exceptions
Automatic approval may be appropriate where the order and operation match, required lot and inspection data exist, quantity relations are valid, and counter variance stays within an approved threshold. The rule and its version should be recorded with each decision. Record the automatic actor and decision time separately from human approvals. Microsoft documents a workflow example in which registrations meeting predefined rules can be approved automatically while unaccepted deviations require manual handling. Apply the idea to quantities only after defining local limits and stop conditions. Source: Microsoft Learn, Calculate, approve, and transfer registrations.
Build a revision trail for before and after approval
Before approval, a worker may correct and resubmit a record, but the first value, changed value, actor, time, and reason should survive. After approval, avoid quietly overwriting the final record. Create a correction request, obtain authorized approval, then issue either a new valid version or cancellation and reposting events. The chosen method must match what the downstream ERP accepts.
Suppose 120 good units were confirmed and sent to ERP, then a check shows 118. Changing the display to 118 leaves the ERP transaction at 120 unless a downstream correction is made. Link original 120, corrected 118, the illustrative difference of minus 2, reason, approver, and ERP adjustment result. Rework, returns, and quality holds may need cancellation and new transactions rather than a simple difference.
SAP Digital Manufacturing documents cancellation of a quantity confirmation already posted to an integrated ERP, along with prerequisites and limits involving automatic goods receipt or backflush. This is a product-specific capability, not a promise that every correction can be automated. Check the actual product version and configuration. Source: SAP Help, Cancelling Quantity Confirmations.
Present the full event sequence from original entry through return, resubmission, approval, transfer, and correction on the record screen. Keep event time and received time separate for offline devices. At multilingual sites, shared reason codes can support consistent reporting while free-text notes remain in their original language. A translated note should not silently replace the source. NIST SP 800-53 provides useful control concepts for audit event content and retention, but it is not itself a manufacturing daily report law. Set retention according to applicable contracts, sector rules, and company policy. Source: NIST SP 800-53 Rev. 5.1.
Set the cutoff and the ERP/MES data contract
Cutoff is more than a screen lock. It defines which production date, order, operation, and shift are included in the confirmed actuals transferred to ERP. Aggregate approved records and display submitted-but-unapproved, returned, missing, and failed transfers separately. Treating missing records as zero hides whether output was low or reporting was late. Dashboards should distinguish provisional quantity, approved quantity, and ERP-accepted quantity.
ISA-95 provides a framework for information exchange between manufacturing operations and enterprise systems. It helps teams define MES/ERP boundaries and responsibilities, but does not prescribe a factory’s approver or cutoff time. In the interface specification, identify the system of record for the production order, shop floor actuals, and inventory posting. Source: ISA, ISA-95 Standard.
Microsoft describes good quantity, error quantity, and error cause in production-order completion, and explains the inventory posting effect of the “report as finished” journal. A daily report figure and an ERP-posted inventory figure can therefore refer to different states even if staff call both “output.” Keep them in distinct columns. Sources: Microsoft Learn, Report a production order as finished and Production order posting.
Each interface event should have a stable detail ID, revision, transaction type, and event ID. Business data may include plant, order, operation, item, lot, production date, shift, unit, and quantity. Technical trace data should include approval time, send time, response, and ERP transaction ID. Determine required fields from the product and ERP contract. If machine output is shots while the finished unit is pieces, record the conversion factor and version used before posting.
Retries must not create duplicate inventory. Confirm whether ERP deduplicates by event ID or whether the sender must query before resending. An HTTP success response does not always mean the business transaction posted. Capture the ERP transaction ID or provide a way to query final status. Distinguish a retry of the same event from a new correction event. GS1 EPCIS is a useful reference for describing events by what, when, where, why, and condition; adopting EPCIS is not a prerequisite for this workflow. Source: GS1, EPCIS 2.0.
Design exceptions before the normal demonstration
An offline tablet may submit after cutoff, with different event and server times. Define who authorizes late entry, how the production date is chosen, and how duplicates are rejected. Show “not yet sent” locally; never display it as approved on the supervisor’s queue before the server receives it. If a machine counter differs from a worker entry, investigate empty cycles, setup, multi-cavity tools, inspection rejects, and rework before choosing a source. Do not automatically favor the sensor reading.
A cancelled or split order can leave submitted records linked to an obsolete order. Preserve the original order ID and relation to its replacement. A correction after accounting close also needs a policy for ERP adjustment and accounting period. Correcting the daily report screen alone is not completion if inventory, costing, or allocation remains wrong.
| Exception | First owner | Evidence | Closure condition |
|---|---|---|---|
| Late or missing submission | Supervisor | Shift, device state, order | Submission or recorded reason |
| Quantity discrepancy | Supervisor and quality | Counter, inspection, rework | Reason confirmed and resubmitted |
| Unknown lot | Quality and warehouse | Receipt, issue, physical label | Lot identified or hold recorded |
| ERP transfer failure | Production control and IT | Event ID, response, ERP transaction | Accepted without double posting |
| Post-approval correction | Authorized production owner | Original, reason, downstream impact | Cancellation or adjustment reconciled |
Owners may be combined at small plants, but approval and downstream acceptance should not collapse into one status. An exception queue should show elapsed time and the next owner, not just a count.
Write testable RFP requirements
“Tablet entry, manager approval, ERP integration” is too vague for comparable quotations. Attach current forms, example master data, shift calendar, normal and abnormal samples, and the ERP import specification to the RFP. Redact sensitive customer and employee data where appropriate. Specify approval levels, delegation, resubmission, cutoff, offline behavior, and correction method. Ask vendors whether each requirement is standard configuration, custom development, or integration, and request limitations and evidence.
Write requirements as observable behavior. For example: an unauthorized worker cannot edit an approved good quantity; the attempted action is traceable; a late entry after cutoff enters an exception queue and not confirmed actuals; retransmitting an approved correction does not increase stock twice. These same statements become FAT/SAT acceptance criteria. Demonstrate errors, resubmission, night-shift date assignment, and ERP timeout with your own sample data, not only a polished happy path. Compare the operating and rule-maintenance effort as well as the software quote.
FAT/SAT scenarios for approval, correction, and posting
Define FAT and SAT responsibilities in the contract. In the supplier environment, test state transitions and integration logic. At the plant, test actual devices, network, language, and user roles. Record expected screen, API event, ERP record, and audit history for each scenario.
- Normal path: worker submits good, scrap, and downtime; supervisor approves; ERP accepts once and returns a traceable transaction ID.
- Return: supervisor rejects a quantity discrepancy; worker resubmits with a reason; both values remain visible and no premature ERP event exists.
- Correction: after ERP acceptance, an authorized correction creates the agreed cancellation or adjustment and reconciles both systems.
- Network loss: lost response and retry do not duplicate ERP stock; the failure queue and recovery are visible.
- Night shift: entries on both sides of midnight and late submission use the same production date in tablet, report, and ERP.
- Permission: expired delegation and unauthorized changes are blocked and logged.
- Rework and hold: quality-held and reworked units move without double counting.
Let real operators perform SAT under normal glove, noise, shared-terminal, and weak-network conditions. Have local supervisors confirm that Thai, English, and Japanese status and return reasons mean the same operational action. Translation quality matters because ambiguous labels can create wrong approvals.
Roll out one process, then expand
Choose a pilot operation where orders and actuals can be traced, a supervisor can review daily, and ERP acceptance can be checked. Observe ordinary and exceptional original records, then agree on a single rule sheet for quantity definitions, cutoff, corrections, and integration. Configure roles and screens, run abnormal FAT cases, complete plant SAT, and define the condition for retiring the paper process.
Measure the proportion approved before cutoff, age of pending approvals, return reasons, post-approval corrections, ERP recovery time, and report-to-ERP quantity differences. These are local improvement measures; this article does not claim a standard improvement rate. Set targets from a measured baseline and avoid incentives that cause staff to hide exceptions.
Before the RFP, collect source records from night shifts, month-end, product changes, and rework. Trace one production order across the paper report, machine counter, inspection, supervisor signoff, ERP actuals, inventory receipt, and handwritten correction. Different values may count shots, accepted items, or finished inventory rather than signal an error. Watch where decisions stop and who gets called; workarounds often expose missing exception requirements.
Name a data owner for each field and update. An example architecture could keep production orders in ERP, operation events in MES, quality decisions in a quality system, and inventory in ERP or WMS. Your actual systems may differ. For each interface field, document owner, trigger, acceptable delay, correction authority, monitoring owner, and reconciliation target. Version approval rules as products, equipment, shifts, and quality methods change. Historic records must display the rule applied at the time, not be judged retroactively under today’s rule. Expand automatic approval gradually and provide a way to stop it when a bad condition is discovered.
Reconcile old and new records before cutover
Run a defined parallel period for the same production orders. Compare operation, shift, lot, good/scrap/hold categories, and correction counts, not only daily totals; offsetting errors can make totals look correct. Investigate discrepancies against physical, inspection, and inventory evidence rather than assuming either source is right. Name the reconciliation owner, acceptable differences, and owner of unresolved issues before setting the cutover date. After go-live, assign a daily owner for pending approvals and failed transfers. Monitor sent, accepted, failed, retried, corrected, and unreported orders. If stock is adjusted manually during an outage, link that ERP transaction to the later automated retry to avoid double posting.
FAQ: choosing a daily report approval system
What if the supervisor is absent?
Use time-limited delegation with a defined plant or line scope and a recorded reason, or automatically confirm only records that meet approved low-risk rules. Verify that the fallback still meets ERP cutoff. Test expired delegation in SAT.
How much correction history should be kept?
Retain original and new values, record and revision IDs, reason, actor, approver, times, and the downstream cancellation or adjustment result. Determine retention from relevant contracts, industry rules, and company policy; NIST is a design reference, not a universal retention period.
Does MES remove the need for an approval workflow?
MES may collect actuals, but you still need to verify who approves, when records close, how corrections work, and how ERP confirms receipt. Some products provide these features; others need configuration or integration. Test the actual state transitions in the RFP.
Should ERP receive every daily report immediately?
Provisional progress can be visible immediately while inventory-impacting transactions wait for approval. Some operations require immediate posting. The essential requirement is to distinguish provisional, approved, and ERP-accepted values and define correction handling for each.
What belongs in the RFP and FAT/SAT?
Include real forms, states, permissions, cutoff, production-date and quantity definitions, correction method, retry deduplication, audit trail, night shift, and network failures. Test return, post-approval correction, retry, and expired delegation across both report and ERP records.
Conclusion
The core of a manufacturing daily report approval workflow is the agreement about which detail is confirmed by whom, using what evidence, and how an error is corrected downstream. Keep approval distinct from ERP acceptance, preserve revisions, and design cutoff exceptions. Express those rules as observable RFP requirements and test them in FAT and SAT.
If you are mapping current factory forms to ERP or MES responsibilities, contact TOMAS TECH. We can help identify the approval, correction, and integration decisions before product selection.
References
- ISA, ISA-95 Standard
- Microsoft Learn, Registration for manufacturing execution
- Microsoft Learn, Calculate, approve, and transfer registrations
- Microsoft Learn, Report a production order as finished
- Microsoft Learn, Production order posting
- SAP Help, Cancelling Quantity Confirmations
- NIST, SP 800-53 Rev. 5.1
- GS1, EPCIS 2.0
