RFID to ERP Integration Patterns

RFID to ERP Integration Patterns

Connecting RFID read events to SAP, Oracle, Microsoft Dynamics, or other ERP systems requires a well-defined middleware architecture. Raw tag reads are not directly consumable by ERP — they must be filtered, aggregated, and translated into business documents. This guide covers the three principal integration patterns and their trade-offs.

Integration Architecture Overview

The canonical stack from tag to ERP has four layers:

1. Edge — Readers capture raw EPC reads via LLRP
2. Middleware / ALE — Filters duplicates, applies business rules, aggregates events
3. EPCIS Repository — Stores canonical event records (ObjectEvent, AggregationEvent, TransactionEvent)
4. ERP Adapter — Translates RFID event data." data-category="Standards & Protocols">EPCIS events to ERP IDocs (SAP), XML Gateway documents (Oracle), or REST API calls

Never bypass EPCIS and write directly from ALE to ERP. The EPCIS layer provides auditable, GS1-standard event records that support supply chain partner sharing, regulatory reporting, and decommissioning workflows.

Pattern 1: ERP-Driven (Polling)

The ERP adapter polls the EPCIS repository on a schedule (every 1–15 minutes) for new events matching a business location or step filter.

Pros: Simple to implement; ERP controls the ingest rate; tolerant of RFID middleware outages Cons: Latency up to 15 minutes; polling overhead on EPCIS repository; not suitable for real-time dock-door receiving

Best for: batch inventory reconciliation, end-of-day warehouse position updates, compliance reporting.

Pattern 2: Event-Driven (Push via Message Bus)

EPCIS publishes events to a message broker (Kafka, RabbitMQ, Azure Service Bus) as they are recorded. The ERP adapter subscribes to relevant topics and processes events in near-real-time.

Pros: Sub-second latency; decoupled; ERP downtime does not block RFID operations Cons: More infrastructure; requires Kafka or equivalent operations expertise

Best for: dock-door receiving, outbound shipment closure, real-time cycle counting updates.

Pattern 3: iPaaS / Middleware Platform

Platforms like MuleSoft, Dell Boomi, or SAP Integration Suite provide pre-built RFID and EPCIS connectors with visual mapping to ERP document types.

Pros: Faster implementation for teams without middleware expertise; vendor support Cons: Licensing cost ($50K–$300K/year); lock-in; less flexibility for custom business logic

SAP-Specific Considerations

SAP's recommended approach uses SAP Auto-ID Infrastructure (AII) or its successor SAP Object Event Repository (OER) as the EPCIS layer, with IDocs carrying goods receipt and transfer order transactions to SAP EWM or WM.

Map EPC URIs to SAP material numbers via a cross-reference table. SGTIN-96 EPCs encode GTIN and serial number — extract GTIN via the EPC Decoder and look up the SAP material number from the GTIN master.

Commissioning and Decommissioning Events

The ERP integration must handle the full tag lifecycle: - Commission: New EPC associated with a specific material/serial — write to ERP item master and EPCIS ObjectEvent (ADD) - Ship: TransactionEvent links EPCs to outbound delivery document - Receive: TransactionEvent links EPCs to inbound delivery / goods receipt - Decommission: ObjectEvent (DELETE) when item is sold, scrapped, or returned

Failure to decommission causes phantom inventory — tagged items show as on-hand long after they have left the facility.

See also: EPCIS 2.0 Implementation Guide, Warehouse RFID Deployment, Edge Computing for RFID