Work Order Reporting with RFID: Report Events, Not Optimistic Percentages

Production reporting looks like a simple automation: the pallet passes a reader, and Odoo updates the work order. It is not simple, because a work order records time as well as quantity, and a read says nothing about when the operation started or who performed it.

A work order is a claim about time, not just quantity

The accounting and the analysis both depend on the time dimension.

• Start and end times drive capacity, lead time and cost per hour.
• A quantity without a duration cannot be used for OEE or for rework analysis.
• A read at the end of the line tells you output; it says nothing about the twenty minutes of waiting in between.
• Reporting the completion of an operation is a separate event from reporting good quantity.
• Design the event model before choosing a read point.

What an RFID read can honestly report

Be strict about the claim each read supports.

• Presence of a specific tote or pallet at a specific point in time.
• Passage through a chokepoint, which is a strong claim if coverage is complete.
• Identity of a batch or serial, if the tag is bound correctly and verified.
• Nothing about operator identity unless the operator carries a tag and a workflow attributes the action.
• Nothing about quality, unless an inspection step writes its own event.

Read points on the production route

Each read point should exist for exactly one decision.

• Entry to the work centre: the operation is starting, and WIP has arrived.
• Exit from the work centre: the operation is complete, and quantity can be booked.
• Buffer and queue positions: know where the item is waiting, which explains the delay.
• Rework loop entry: the item is coming back, so the quantity is not good output.
• Scrap bin: a deliberate disposal event, not a missing read at the exit.

Start, pause, complete: modelling the states

A state machine prevents most reporting arguments.

• Queue, in progress, paused, blocked, done — five states cover most shop floors.
• A pause needs a reason code, or the downtime analysis is decorative.
• Blocked means waiting for material or quality, and is a different cost from idle.
• Transitions must be attributed and timestamped, and must be allowed to arrive late.
• Reject impossible transitions loudly rather than silently repairing them.

Quantity, scrap and the rework loop

Quantities need a source and a moment.

• Good quantity is booked at completion, with the unit of measure of the operation.
• Scrap is booked at the point of detection, with a reason and a work centre.
• Rework is an operation, not a correction; model it as such or the routing will lie.
• Partial completions are normal; allow them and keep the remaining quantity visible.
• Reconcile component consumption separately from output, because they fail differently.

Operator identity and the labour split

Who did the work is a real question in a plant with shifts.

• A badge read at the work centre can open a session, but it does not prove continuous presence.
• Attribute the transaction at the moment of confirmation, not at login.
• Shared work centres need a labour split; a single read cannot invent one.
• Indirect labour is usually missing from automated reporting, and it is usually the interesting part.
• Make manual confirmation easy, or operators will confirm everything at the end of the shift.

Backflushing and the timing trap

Backflushing is convenient and quietly wrong at the edges.

• Backflush consumes components when output is booked, which is fine in steady state.
• On a long operation, backflushing shifts consumption in time and distorts WIP.
• Scrap of components mid-operation is invisible unless the operator reports it.
• Backflush tolerances hide systematic over-consumption until an inventory count finds it.
• For high-value or regulated components, report consumption explicitly, even at a labour cost.

Exception handling when the line stops

The automation has to survive the shift where everything goes wrong.

• A missing read must produce a question, not a silent zero.
• Define who can confirm manually, and require a reason.
• Buffered events must be replayable in order, with the original timestamps preserved.
• A line that runs without the reader must be able to report on paper and reconcile later.
• Track how often manual confirmation is used; it is the health metric of the automation.

Sync model: events, not counters

Odoo's work orders have states; the integration should speak in transitions.

• Send operation events with identifiers, and let Odoo own the resulting quantities.
• Never increment a progress percentage directly; derive it from booked quantities.
• Make ingestion idempotent, because shop floor networks retry.
• Keep the raw event log, so a disputed quantity can be reconstructed.
• Reconcile daily: events received, quantities booked, differences explained.

Serialisation and genealogy

A serial at the end of the line is a promise about components.

• A serial read creates a genealogy claim that has to be defensible in a recall.
• Component lots must be bound to the serial at build time, never reconstructed afterwards.
• A serial reused across units destroys recall analysis and any warranty position.
• Genealogy is only as good as the component reporting upstream; if that is backflushed roughly, the recall list is worthless.
• Printing and applying the serial label is itself an operation, and label errors are a leading cause of genealogy failure.

Metrics and pilot

Prove the reporting is better, not merely more automatic.

• Measure reporting lag, manual confirmation rate, and the share of operations with a real start time.
• Compare OEE figures before and after, and check whether the change is measurement or reality.
• Run a pilot on one work centre with a stable routing and a cooperative shift lead.
• Watch the exception rate in the first month, because it predicts whether the team will keep using it.
• Decide in advance what level of manual fallback is acceptable.