EDI Mapping Specs
EDI Mapping Specs
A mapping spec turns a partner's EDI document into a business object your scripts and apps can use. It says which segment and element carries the PO number, where the line items repeat, and what to call each field.
Find them at Extensions > EDI Mapping Specs. Creating and editing requires DataMagik - Builder.
Why a spec instead of code
Without one, a script reading an 850 has to write segments.find(s => s.tag === "BEG").elements[2]
and hope the partner populates BEG03 the way you expect. The knowledge ends up trapped in that script,
and onboarding the next partner means copying and editing it. A spec is data: it is versioned, it is
testable against a real file, and the same one drives both reading and writing.
Start from a template
DataMagik ships 26 starter mappings, grouped by vertical. Pick one, and the designer opens pre-filled with a sensible layout you then tune to your partner.
| Set | Starter | Purpose |
|---|---|---|
| 810 | 810-standard | Invoice — header invoice number/date/PO, IT1 line loop, TDS total. |
| 812 | 812-credit-debit-adjustment | Credit/debit adjustment — the price or weight settlement after a heat is weighed and graded, or a claim against an invoice. |
| 816 | 816-organizational-relationships | Ship-to, bill-to and plant hierarchy sent as data instead of by email. |
| 820 | 820-remittance-advice | What a customer paid and which invoices it settles, so cash application is not keyed. |
| 824 | 824-application-advice | Syntactically fine but rejected by the business application — something a 997 cannot say. |
| 830 | 830-planning-schedule | Forecast with cumulative accounting. The core automotive release document. |
| 846 | 846-inventory-advice | On-hand and available stock by item, as a service centre reports coil and plate inventory. |
| 850 | 850-standard | Purchase order — header, N1 party loop, PO1 line loop with PID descriptions. |
| 852 | 852-product-activity | POS/inventory movement from a grocer or retailer. |
| 855 | 855-po-acknowledgment | Purchase order acknowledgment — BAK header, per-line ACK status. |
| 856 | 856-standard | Advance ship notice — HL shipment/order/item hierarchy. Steel: heat number via REF at item level. |
| 860 | 860-po-change | The buyer revises an order already sent — POC lines with change code and revised quantity or price. |
| 861 | 861-receiving-advice | What actually arrived, weighed and counted, against what the ASN promised. |
| 862 | 862-shipping-schedule | Firm release against a PO, with FST ship-schedule requirements. |
| 864 | 864-text-message | Free-form mill notes: heat certificates pending, line down, gauge substitution. |
| 865 | 865-po-change-ack | The seller's answer to an 860 — accepted, rejected, or accepted with changes. |
| 866 | 866-production-sequence | Build-order sequencing against a release: which unit, in what order, to what line-side location. |
| 869 | 869-order-status-inquiry | Ask a mill or service centre where an order stands. Outbound. |
| 870 | 870-order-status-report | The reply: released, rolled, shipped, with quantities by status. |
| 875 | 875-grocery-purchase-order | Grocery purchase order (UCS) — G50 header, N9 references, G69/G55 line items. |
| 940 | 940-warehouse-shipping-order | Instruct a 3PL to ship. Outbound. |
| 944 | 944-stock-transfer-receipt | The 3PL confirms what it received into stock against a transfer. |
| 945 | 945-warehouse-shipping-advice | A 3PL confirms a shipment — HL shipment/order/item with W12 line items. |
| ORDERS | edifact-orders | EDIFACT purchase order — BGM document number, LIN line loop with composite product id and QTY. |
| DELJIT | edifact-deljit | EDIFACT delivery just-in-time call-off. Inbound from European OEMs. |
| DESADV | edifact-desadv | EDIFACT despatch advice / ASN. Outbound to European OEMs. |
The designer
| Part | What it does |
|---|---|
| Name | How the spec is referenced from a partner's routing row and from
edi.map(raw, "name") in a script. |
| Direction | Inbound (segments → object) or outbound (object → segments). |
| Standard / Transaction set | X12 or EDIFACT, and which document. |
| Output key | The name of the array in the resulting object — purchaseOrders. |
| Header fields | One row per value from the document header. The path is a segment and an element position. |
| Repeating groups | Line items and parties. A group starts at a segment
and repeats — PO1 for order lines, N1 for parties — and can nest. |
| Settings | Define your own configuration fields and their defaults, for a document-logic script to read. Acknowledgements, conformance and turnaround are set per partner on the routing row, not here. |
| Edit as JSON | The whole spec as a document. Nested groups beyond the first level, and code sets, are edited here. |
Field paths
A path is SEGMENT[n] for an element and SEGMENT[n][c] for a component.
Positions are 0-based, counting the elements after the segment tag. So in
BEG*00*SA*PO-48815**20260725:
BEG[0] = "00" purpose code
BEG[1] = "SA" PO type
BEG[2] = "PO-48815" the PO number
BEG[4] = "20260725" the PO date
BEG[2] is BEG03 in your partner's specification. Their
documents number elements from 1; the designer counts from 0. Off-by-one here is the single most
common mapping mistake.Each field also has a type — string, number or date — and a
required flag. Default to string: EDI is string data, and a partner sending
00100 for a quantity should not silently become 100 in an audit trail unless
you asked for it. Marking a field required means a document that does not carry it is treated as
non-conformant and sent to review rather than passed downstream half-empty.
AI discover
Paste a real document into Sample EDI document and press AI discover. DataMagik parses the file structurally — that part is deterministic and always correct — and asks the AI to propose field names and loop boundaries from the segment inventory. You then correct and save.
The names it proposes are its own — a discovered 850 might call the line array
lineItems where the starter template calls it lines. Rename anything you
would rather match your existing scripts before saving.
Test mapping — a worked 850
This is the part to do before anything else goes live. Paste a document, press Test mapping, and read the object next to the file that produced it.
Given this purchase order:
ISA*00* *00* *ZZ*ACMESTEEL *ZZ*CHUPPCONS *260725*1200*U*00401*000000101*0*P*>~
GS*PO*ACMESTEEL*CHUPPCONS*20260725*1200*101*X*004010~
ST*850*0001~
BEG*00*SA*PO-48815**20260725~
N1*ST*Chupp Consulting Plant 4~
N4*Columbus*OH*43004~
PO1*1*100*EA*12.50**BP*WIDGET-A~
PID*F****Widget A, zinc plated~
PO1*2*40*EA*31.75**BP*BRACKET-C~
CTT*2~
SE*9*0001~
GE*1*101~
IEA*1*000000101~
the 850-standard starter reports Mapped OK · X12 · envelope valid and
produces:
{
"purchaseOrders": [{
"poNumber": "PO-48815",
"poDate": "2026-07-25",
"parties": [
{ "entityCode": "ST", "name": "Chupp Consulting Plant 4",
"city": "Columbus", "state": "OH", "postalCode": "43004" }
],
"lines": [
{ "line": "1", "product": "WIDGET-A", "productQualifier": "BP",
"quantity": 100, "uom": "EA", "unitPrice": 12.5,
"descriptions": [{ "description": "Widget A, zinc plated" }] },
{ "line": "2", "product": "BRACKET-C", "productQualifier": "BP",
"quantity": 40, "uom": "EA", "unitPrice": 31.75, "descriptions": [] }
]
}]
}
Note what the spec did beyond copying strings: poDate became a real date,
quantity and unitPrice became numbers because those fields are typed, the
N1/N4 pair collapsed into one party object, and the PID under
each PO1 nested inside its own line rather than floating at the top.
To finish the setup, register the sender as a trading
partner with qualifier ZZ and ID ACMESTEEL, and add a routing row for
They send us / 850 mapped by this spec.
Using a spec from a script
const result = edi.map(raw, "850-acme"); // apply a saved spec
const tx = edi.process(raw); // full pipeline: partner + spec + routing
const specs = edi.starterSpecs(); // the built-in catalog
const out = edi.buildMapped(obj, "855-acme"); // the other direction