RFID + ERP/WMS Integration: Where the Value Is Won or Lost

The readers work. The tags read at 98 %. And three months into the project the finance team is staring at inventory adjustments nobody can explain. Almost every RFID failure that is not a physics problem is an integration problem: events arrive out of order, the same pallet is counted twice, or the middleware writes a quantity into the ERP that the ERP can never audit.

This article is about the layer between the reader and the business system — how to design it so that the numbers in Odoo, SAP or Yonyou are defensible at month-end.

What should the integration own, and what stays in the ERP?

Split responsibilities explicitly, and write the split into the statement of work. Ambiguity here is what produces two systems that each believe the other one is authoritative.

• Edge layer owns reader connectivity, antenna configuration, read filtering, duplicate suppression, tag-to-SKU resolution, event timestamps and the event identifier.
• Middleware owns ordering, retry, dead-letter handling, enrichment with context (dock door, operator, work order) and the mapping to a business document.
• The ERP owns valuation, allocation, availability calculation, financial posting and the audit trail.

The rule that saves most projects: middleware never writes stock.quant directly. It submits a document — a receipt, a transfer, a count adjustment — and lets the ERP's own business logic decide what the stock becomes. Direct writes skip the audit trail, skip the valuation layer and break the day you upgrade.

Which pattern fits your volume: file, API or event stream?

Choose from measured numbers, not from vendor preference. The three patterns coexist happily.

• Under 5,000 events per shift: hourly or nightly file exchange is enough, and it is by far the easiest to reconcile. One file per site, deterministic naming, checksum in the manifest.
• 5,000 to 50,000 events per hour: synchronous REST calls, batched in groups of 100–500, each carrying an idempotency key.
• Above that, or whenever latency decides the business outcome (a dock door must confirm in seconds): an event stream — MQTT for the reader-to-edge hop, Kafka or RabbitMQ for the edge-to-ERP hop.

Latency matters more than throughput. A receiving confirmation that arrives twenty minutes late is a business problem, not an IT problem. Measure p95 at the dock door, not the average in the test lab.

Odoo: how to land RFID events without corrupting stock.quant

Odoo will let you write almost anything. That is exactly why the integration needs discipline.

• Give each flow a dedicated operation type: RFID Receipt, RFID Internal Transfer, RFID Count. Reporting and access rights follow the operation type.
• For counting, use the inventory adjustment wizard: write inventory_quantity on the quant row, then call action_apply_inventory. Never write the quantity field directly; the adjustment creates the auditable move.
• Assign every event a stable external ID in a custom field with a unique index, so a retry cannot create a second move line.
• Batch 200–500 move lines per transaction. Larger batches hold row locks on products and block other users for no benefit.
• Keep RFID-specific fields (rfid_epc, rfid_event_id, rfid_reader) in a separate model or as non-stored computed fields. stock.quant is read constantly; bloating it costs performance everywhere.

SAP: IDoc, OData and the middleware question

SAP wants material documents, not tag reads. There are three realistic paths and each has a good use case.

• IDoc (WMMBID02, MBGMCR, DESADV): mature, batch oriented, and the least disruptive choice when you already run PI/PO.
• OData and REST APIs on S/4HANA: better for near-real-time posting and far simpler to version than custom IDoc extensions.
• A dedicated MII or EWM layer: justified only above a few million tag events per day, or when EWM is already the system of record for the warehouse.

The recurring mistake is choosing the movement type by convenience rather than by accounting meaning. 261 and 262 for consumption, 101 and 102 for receipt, 311 and 312 for transfer — each carries consequences in costing and period-end. Have the controller sign the mapping table before the first line of integration code is written.

Yonyou, Kingdee and domestic ERPs: OpenAPI first

Chinese ERPs — Yonyou U8+, Yonyou BIP and NC Cloud, Kingdee K/3 and Cloud — expose REST OpenAPI and a message bus. Use them, and use them asynchronously.

• Pull an inventory snapshot daily and reconcile it against your own count; push transactions as completed business documents.
• Direct database writes into U8 are common practice in the local market and are the single most expensive shortcut available. They bypass the audit trail, break on patch upgrades and turn month-end reconciliation into a political negotiation.
• Confirm the API rate limit and the field mapping for warehouse, batch and serial number before promising real-time behaviour. Many domestic deployments are effectively near-real-time, and promising otherwise is how projects lose credibility in week two.

What breaks in production, and how to design for it

Six failure modes account for most production incidents, and each has a design answer.

• Clock skew between readers: log both occurred_at (reader) and received_at (server), and never sort by occurred_at alone.
• Duplicate EPCs: two tags programmed with the same identifier produce contradictory movements. Detect at the edge, reject before the ERP sees it.
• Reader offline backlog: a reader that reconnects after two hours must not replay 40,000 stale reads as current events. Cap the backlog window and mark late events explicitly.
• Out-of-order delivery: an item cannot leave a location before it arrived. Reject or quarantine; never silently accept.
• Timezone: store UTC, display local time, and test one daylight-saving boundary before go-live.
• Silent partial failure: a batch of 500 where 3 rows fail must report 497 succeeded and 3 pending, not one generic error.

A checklist before you sign the integration SOW

• Who generates the event ID, and is it globally unique across sites and years?
• Which system has the authority to turn a read into a movement?
• Is every write idempotent, and has it been tested with a deliberately duplicated message?
• What is the p95 latency, measured at the dock door?
• How do exceptions surface, and who closes them within what SLA?
• Can you replay a full day of events without doubling stock?
• Is the movement-type and operation-type mapping signed off by finance or controlling?

If any answer is a person's name rather than a document, the integration is not specified yet — and the cost of that ambiguity will be paid in inventory adjustments.