RFID Integration with Odoo: A Practical Architecture

Odoo doesn't ship with an RFID app. That's fine. The right architecture keeps RFID-specific complexity outside Odoo anyway, with Odoo receiving clean business events it already knows how to process.

Here's the design we use. It's a reference, not a product, and every deployment needs tuning to its readers and floor layout.

The architecture

[Tags] -> [Readers / handhelds] -> [RFID middleware] -> [Odoo integration module] -> [Odoo inventory]

1. Readers

Fixed readers at dock doors or portals, and handheld readers for counting. Most can push events via LLRP, MQTT or HTTP. Handhelds usually run an Android app that talks to a reader sled.

2. Middleware

A small service, often Python or Node, running near the readers:

• Collects raw reads
• De-duplicates and filters (time windows, signal strength thresholds)
• Determines direction at dock doors when you have multiple antennas
• Decodes EPC values (typically SGTIN-96) into GTIN and serial
• Groups reads into a session tied to a document or a location
• Sends one event per session to Odoo, with retries if Odoo is unavailable

Keep this layer stateless where possible, with a local queue so nothing gets lost during network blips.

3. The Odoo module

A custom module that:

• Exposes an authenticated endpoint (or uses Odoo's JSON-RPC/XML-RPC API) to receive events
• Maps GTINs to product.product via barcode
• Maps serials to stock.lot records
• Matches the event to a transfer (stock.picking) or a count
• Records an RFID session with its expected vs actual result
• Leaves a human approval step for discrepancies

Flow 1: Receiving

1. A PO is confirmed. The supplier's ASN lists the expected EPCs or quantities.
2. A pallet passes the dock portal. Middleware sends the set of EPCs.
3. Odoo matches it to the incoming receipt, fills in done quantities and serials.
4. Differences (missing, extra or unknown tags) are shown to the receiving clerk.
5. The clerk validates. Stock and accounting update as normal.

Flow 2: Cycle counting

1. A counter scans a zone with a handheld.
2. Middleware sends the list of EPCs found, tagged with the location.
3. Odoo compares it to the serials it expects in that location.
4. The supervisor reviews: missing items, items in the wrong place, unknown tags.
5. Approved adjustments post as inventory adjustments.

Flow 3: Dispatch verification

At a dock door, reads are compared with the delivery order before the truck leaves. A mismatch triggers an alert to the dispatch team. This catches wrong-pallet errors, which are expensive to fix after the truck has gone.

Performance notes

• Batch writes. Create or update stock move lines in batches, not one RPC call per tag.
• Index your lookups. Barcode and serial lookups need to be fast at scale.
• Use background jobs (for example, OCA's queue_job) for large sessions, so the API responds quickly.
• Archive old sessions to keep tables lean.

Build or buy?

Commercial RFID middleware exists and can save time, especially for complex reader estates. The Odoo module is almost always custom, because it encodes your flows. We'd normally buy or reuse middleware and build the Odoo side.

Start small

Pilot one dock door or one zone. Measure read rates with your actual products, then scale. For background on the hardware side, see RFID integration with ERP. For the Odoo flows involved, see Odoo inventory routes explained. And if you want help designing it, our Odoo integration team builds these.