Mapping projects that survive the second partner
The first EDI mapping is easy. The tenth is only easy if the first was built as a canonical model instead of a point-to-point translation.
Point-to-point does not scale
Connecting an ERP directly to a partner format works once. With ten partners you own ninety translations, and every ERP change has to be replayed in each one. A canonical internal model turns that into ten inbound and ten outbound mappings.
Design the canonical model from the business, not the format
Model an order as your company understands it: header, parties, terms, lines, references. Then map each partner dialect onto it. Fields that only one partner uses belong in a clearly marked extension area, never in the core.
- Keep identifiers typed: GLN, DUNS and internal numbers are not interchangeable strings.
- Store the original interchange next to the canonical instance for audit purposes.
- Version the canonical model, and treat a breaking change like an API change.
Partner profiles belong in data
Every partner has quirks: a mandatory reference, a shorter description field, a proprietary qualifier. Encode those as profile data validated at runtime, not as branches in mapping code. A profile can be reviewed by the integration team; a nested conditional cannot.
{
"partner": "4000004000002",
"standard": "EDIFACT",
"version": "D.96A",
"required": ["RFF+ON", "DTM+2"],
"maxLength": { "IMD.C273.7008": 35 }
}Test data is a deliverable
Keep a regression set of real, masked interchanges per partner. Every mapping change runs against the whole set. This is the single practice that separates integrations that age well from those that need a rewrite after two years.
Try it on your own document
Upload an EDIFACT, X12 or XML file and see structure, validation findings and a plain-language explanation in one view.
Analyze a document