ERP-WMS Integration and EDI

EDI Transaction Reference (X12 Standard)

EDI (Electronic Data Interchange) is the language of structured business documents between trading partners and between enterprise systems. ANSI X12 is the dominant standard in North American warehousing.

Core Warehouse EDI Transactions

Transaction	Name	Direction	Trigger
850	Purchase Order	Buyer → Vendor	Buyer places PO
855	PO Acknowledgment	Vendor → Buyer	Vendor confirms PO
856	Advance Ship Notice (ASN)	Vendor → Buyer	Vendor ships; WMS triggers receiving workflow
810	Invoice	Vendor → Buyer	Post-shipment billing
940	Warehouse Shipping Order	ERP/OMS → WMS	ERP releases order to WMS for fulfillment
945	Warehouse Shipping Advice	WMS → ERP	WMS confirms shipment; ERP updates inventory/AR
943	Warehouse Stock Transfer Advice	ERP → WMS	Sends inventory transfer instruction
944	Warehouse Stock Transfer Receipt	WMS → ERP	Confirms transfer received

WMS-ERP Transaction Flow (Typical Outbound)

ERP (940 Shipping Order) ──► WMS
WMS picks/packs/ships
WMS (945 Shipping Advice) ──► ERP
ERP updates:
  - Open order status → fulfilled
  - Inventory on-hand → decremented
  - AR → invoicing triggered

ASN (856) Importance

The 856 ASN from a supplier enables the receiving WMS to pre-build a receipt — items, quantities, LPN labels — before the truck arrives. Without ASN: blind receiving. With ASN: directed putaway begins before the trailer is fully unloaded. ASN accuracy is therefore a major supplier compliance metric.

---

Integration Architecture Patterns

Pattern 1: Direct Database Integration (Legacy)

• WMS reads/writes directly to ERP tables
• Tightly coupled — ERP upgrade breaks WMS integration
• Avoid for new implementations

Pattern 2: Point-to-Point API (REST/SOAP)

• WMS and ERP communicate via exposed APIs
• Simple for 2-system integration; becomes unmaintainable as systems proliferate
• Acceptable for small integration footprints

Pattern 3: Middleware / iPaaS (Preferred for Complex Environments)

• Hub-and-spoke model: all systems connect to middleware, not each other
• Platforms: MuleSoft, Dell Boomi, Azure Logic Apps, Microsoft SSIS, Informatica
• Advantages: centralized monitoring, reusable mappings, easier to add new systems
• Cost: middleware platform license + development effort to build mappings

Pattern 4: ERP-Native Adapters

• SAP PI/PO or SAP Integration Suite for SAP EWM environments
• Oracle Integration Cloud for Oracle WMS
• Tightly managed by ERP ecosystem; limits flexibility with non-ERP WMS

---

ERP WMS Modules vs Best-of-Breed

Factor	ERP WMS (SAP EWM, Oracle WMS Cloud, D365 WMS)	Best-of-Breed WMS
Integration to ERP	Native, no integration layer required	Requires integration development
Warehouse complexity	Good for simple to moderate operations	Designed for high-complexity, high-volume DCs
Implementation cost	Lower for greenfield	Higher integration layer cost
Configuration depth	Adequate but constrained	Typically more warehouse-specific flexibility
Upgrade cycle	Tied to ERP upgrade	Independent releases
Industry adoption	Greenfield SAP/Oracle shops, manufacturing	3PLs, omnichannel retail, high-velocity DCs

Rule of thumb: ERP WMS wins when the operation is moderate complexity and the ERP is already the dominant platform. Best-of-breed wins when order complexity, volume, or automation depth outgrows what the ERP WMS can configure.

---

Data Model Mismatch: The Hidden Integration Problem

ERP and WMS think about inventory in fundamentally different ways:

• ERP: Inventory in financial units (each, case, pallet as accounting denominations). A “pallet” = quantity × unit cost.
• WMS: Inventory in physical license plates (LPNs), locations, and container types. A “pallet” = LPN with weight, dims, contents, and a physical location.

This mismatch creates common failure modes:

• Multiple WMS LPNs mapping to one ERP record → reconciliation complexity
• ERP unit-of-measure not matching WMS receiving UOM → receiving quantity errors
• ERP valuation timing (cost of goods sold) not aligning with WMS ship confirmation timing → financial period issues

Resolution: Define the master data model jointly during implementation. Agree on the unit-of-measure conversion layer before go-live.