Understand and introduce EDI/EDIFACT
This entry page is for project owners, administrators, and integration developers who want to exchange business documents with a trading partner automatically. It explains the essential terms, separates the standard, partner profile, mapping, and transport contracts, and shows what Workspace supports natively.
Start with one decision: does the agreed partner contract use ORDERS and ORDRSP in D.96A or D.25A over the Partner API or SFTP? Treat a different message, directory, or transport as a separate integration scope.
Check the supported contract first
| Direction | Workspace contract | Meaning |
|---|---|---|
| Inbound | ORDERS in D.96A or D.25A | The buyer submits a purchase order. Workspace validates, maps, and processes it under the active application policy. |
| Outbound | ORDRSP in D.96A or D.25A | Workspace accepts or rejects the complete order. |
| Syntax acknowledgement | CONTRL 2.2 for syntax version 3 or CONTRL 4.1 for syntax version 4 | The recipient accepts or rejects the EDIFACT syntax. CONTRL is not a D.96A/D.25A directory message. |
| Application acknowledgement | APERAK in D.96A or D.25A | The recipient reports an application-level or mapping-related acceptance or rejection. |
| Transport | Partner API or SFTP | The transport moves bytes. It does not replace syntax validation or a business acknowledgement. |
The current native contract includes neither DESADV, INVOIC, nor AS2. An UN/EDIFACT directory can define a message that Workspace does not yet process as a product capability.
Keep the contract layers separate
EDI/EDIFACT projects often fail when participants call several different layers “the format”. Keep these contracts distinct:
| Layer | Guiding question | Example |
|---|---|---|
| EDI | Which business process crosses system boundaries? | Purchase order and order response without manual re-entry. |
| UN/EDIFACT syntax | How are interchanges, messages, segments, and data elements written? | Separators, UNB/UNZ, UNH/UNT, release character, and syntax version. |
| Directory | Which structure does a message type have in one release? | ORDERS:D:96A:UN or ORDERS:D:25A:UN. |
| Partner profile | Which subset, qualifiers, and rules do both partners agree? | Mandatory GTIN, permitted quantity units, date format, buyer and seller identifiers. |
| Mapping | How do partner fields translate into the canonical Workspace model? | BGM.2.1 becomes the external order reference. |
| Transport | How do unchanged bytes reach the recipient? | Partner API or SFTP. |
| Processing | Which business effect may the message trigger? | Apply automatically, review differences, or approve manually. |
An EDIFACT parser alone is not a complete EDI integration. The approved partner contract connects all layers.
Read an EDIFACT message
This shortened example shows an ORDERS message in D.96A. It is an orientation aid, not a partner profile:
UNA:+.? '
UNB+UNOC:3+4000001000001:14+4000002000008:14+260716:1030+1'
UNH+1+ORDERS:D:96A:UN'
BGM+220+PO-1001+9'
DTM+137:20260716:102'
LIN+1++04012345000016:EN'
QTY+21:2:PCE'
UNS+S'
UNT+7+1'
UNZ+1+1'| Segment | Purpose in this example |
|---|---|
UNA | Announces the service characters. When UNA is absent, the agreed defaults apply. |
UNB | Opens the interchange and identifies syntax, sender, recipient, time, and control reference. |
UNH | Opens a message and identifies type, version, release, and controlling agency. |
BGM | Identifies the business document and its reference. |
DTM | Carries a qualified date or time. |
LIN | Starts an order line and carries an item reference. |
QTY | Carries a qualified quantity and unit. |
UNS | Separates message sections. |
UNT | Closes the message with segment count and message reference. |
UNZ | Closes the interchange with message count and control reference. |
The example separates elements with +, components with :, and segments with '. The release character ? escapes the next service character. Never split a message naively on apostrophes or plus signs.
Choose the directory, syntax version, and partner profile
Workspace binds the directory to an immutable profile revision:
| Directory | Syntax version in the native contract | Typical UNH identification |
|---|---|---|
| D.96A | 3 | ORDERS:D:96A:UN |
| D.25A | 4 | ORDERS:D:25A:UN |
Do not select the newer directory automatically. Use the exact version both partners approved with samples, required fields, qualifiers, and code values. EANCOM is a GS1-defined subset of UN/EDIFACT, not a synonym for every UN/EDIFACT partner profile. Workspace does not promise a generic EANCOM profile; evaluate that requirement separately.
Interpret acknowledgements correctly
| Signal | Question it answers | It does not prove |
|---|---|---|
HTTP 202 or successful SFTP upload | Did Workspace accept the bytes for processing? | Syntax, mapping, or Commerce application. |
CONTRL | Was the interchange syntactically acceptable? | Business acceptance of the order. |
APERAK | Was the message acceptable to the application or mapping contract? | Commerce acceptance of the order. |
ORDRSP | Was the complete order accepted or rejected? | Transport acknowledgement for another message. |
Monitor transport, syntax, mapping, application, and acknowledgement status separately. One generic “successful” status is insufficient for reliable EDI operations.
Official standards and directories
Use primary sources to look up syntax and standard messages. These sources describe the standard, not the partner profile activated in Workspace.
| Source | Use it for |
|---|---|
| UNECE: UN/EDIFACT introduction and rules | Terms, syntax rules, design guidance, and implementation guidance. |
| UNECE: UN Trade Data Interchange Directory | Directories, message types, segments, data elements, and code lists. |
| UNECE: directory downloads | Official release packages and historic directories. |
| UNECE: UN/EDIFACT Executive Guide | Management and project introduction to the standard. |
| ISO 9735-2:2002 | Batch EDI syntax rules for syntax version 4. The complete standard may require a licence. |
| ISO 9735-11:2022 | Compatibility profile for migration from syntax version 3 to 4. |
| GS1 EANCOM | Official GS1 subset of UN/EDIFACT; use it only when the partner profile explicitly requires it. |
IANA: application/EDIFACT | Registration of the EDIFACT media type. HTTP values are case-insensitive; Workspace documents application/edifact. |
| UNECE Recommendation 20 | Codes for units of measure used in international trade. |
| UNECE UN/LOCODE | Official codes for trade and transport locations. |
| GS1 standards repository | GS1 rules for EANCOM, GLN, GTIN, and related identifiers. |
Do not copy a complete standard definition into a partner mapping. Version the agreed partner profile instead and record the source and release in your project evidence.
Choose the next step
| Your task | Next page |
|---|---|
| Plan a new trading partner project. | Set up an EDIFACT trading partner |
| Administer profiles, connections, SFTP, and status. | Operate B2B Exchange |
| Develop mappings, tests, or a partner client. | Work with EDIFACT as a developer |
| Implement the Partner API worker. | Integrate the B2B Exchange Partner API |
You have completed this introduction when both partners have recorded the message, direction, directory, syntax version, partner profile, transport, business responsibility, and acknowledgement path.