Trading Partner EDI Integration
Purchase orders, invoices and ship notices flowing straight from trading partners into ERP records — parsed, validated and traceable.
Client
Distribution & Trading Enterprise
Industry
B2B Commerce · Document Integration
Duration
4 months
Year
2024
Background
Trading partners were sending purchase orders, invoices and shipping notices in EDI formats that nobody downstream could read directly. Documents arrived, someone opened them, and the contents were re-keyed into the ERP. The volume was manageable until it was not — and every re-keyed document was a chance to introduce an error into an order or a supplier invoice.
The Challenge
EDI is unglamorous and unforgiving: the formats are rigid, partners deviate from them anyway, and a malformed document must fail loudly rather than land half-written in the ERP. The service needed to parse and validate incoming documents, transform them into internal ERP structures, and give operations a way to see exactly what happened to any given document — including the ones that failed.
Our Solution
SageWare built a focused Spring Boot microservice for EDI document exchange, handling purchase orders (850), invoices (810) and advance ship notices (856). Incoming documents are parsed, validated against format and business rules, and transformed into internal ERP data structures. REST APIs cover document submission, status tracking and error inspection, so operations can trace any document through the pipeline. Retry with backoff handles transient failures, and structured logging plus audit tracking record every processing attempt. The service is containerised with Docker and deployed into the existing microservices architecture.
Key Deliverables
- EDI 850, 810 and 856 documents parsed, validated and transformed into ERP structures
- REST APIs for document submission, status tracking and error inspection
- Retry with backoff, structured logging and per-document audit tracking
- Containerised and deployed into an existing microservices architecture
Results & Impact
How We Did It
01
Format & Rule Mapping
Mapped each supported EDI document type to its target ERP structure, capturing both format rules and the business validations each document had to satisfy.
02
Parse & Validate Pipeline
Built the parsing and validation stages so malformed or non-compliant documents fail cleanly and visibly rather than partially writing to the ERP.
03
REST Surface & Error Handling
Exposed submission, status tracking and error inspection APIs, with retry and backoff for transient failures during processing.
04
Containerisation & Rollout
Containerised the service with Docker, integrated it into the existing microservices architecture, and instrumented it with structured logging and audit tracking.
Decisions & Trade-offs
Reject the whole document rather than write part of it
A partially imported purchase order is worse than no purchase order, because it looks like a real one. When validation fails on any line we reject the document entirely, record why, and write nothing to the ERP. Operations sees a clear failure with a reason attached instead of discovering three weeks later that an order exists with four of its six lines.
Retry transient failures, never validation failures
Retrying is only useful when the next attempt might reasonably succeed. A downstream timeout will clear; a missing unit price on line four will fail identically on every attempt, and retrying it only delays the moment a person is told. We separated the two at the point of failure so transient errors back off and recover on their own, and malformed documents go straight to a human with the segment and the reason named.
Keep the partner’s format at the edge
Every trading partner deviates from the standard somewhere. Translating at the boundary, into internal ERP structures, means those quirks stay in one place rather than spreading into downstream modules that should never have to know which partner a document came from. It costs a mapping layer per partner. It is considerably cheaper than a purchasing module carrying special cases for a partner that changed its format two years ago.
Scope & Boundaries
We built the inbound and outbound document pipeline for three document types. The VAN connection and partner onboarding agreements were the client’s, and acknowledgement documents beyond the basic functional acknowledgement were out of scope for this phase.
Next Case Study
The Neith
E-commerce · Fashion & Design