EDI & Trading Partners

Trading Partners and Transports

EDI is trading documents exchanged as structured messages rather than as PDFs somebody rekeys. A partner record holds who you are trading with; a transport holds how the messages travel.

Where to find it

Architect Panel → ERP - Trading & Analytics:

• EDI — the console — messages, status, retry
• EDI Trading Partners — one row per counterparty
• EDI Transports — the five connection kinds
• EDI Messages — everything sent and received
• AS2 Certificates — certificates for AS2 partners

What a partner record holds

• Partner code and the counterparty it binds to in your own data.
• Standard and version — EDIFACT, X12 or another, at an agreed version.
• Their qualifier and ID, and ours — the four values that address a message.
• Acknowledgement required and a timeout in minutes.
• Test indicator — marks traffic as test rather than production.
• Transport, and for inbound, a token and an enable flag.

The four identifiers

Qualifier and ID pairs — yours and theirs — are what route a message. They are agreed with the partner, usually in a document they send you, and they must match exactly. A wrong qualifier produces a message that is rejected without ever reaching a human at the other end, and the failure is silent from your side until an acknowledgement fails to arrive.

Copy them; do not retype them.

Transports

Five kinds are provided: SFTP, HTTPS, EDI VAN mailbox, AS2 and OFTP2. All ship disabled and without credentials, so nothing connects to a partner because an update was applied.

The transport is separate from the partner, so several partners can share one — a VAN mailbox typically carries traffic for many counterparties.

Use the test indicator

Set it while you are commissioning. Partners generally have a test environment and treat flagged traffic accordingly; sending a live-flagged test order is how a genuine delivery arrives at somebody's warehouse.

Turn it off only when both sides have agreed you are live.

Acknowledgements and timeouts

Where a partner acknowledges, record that and set a realistic timeout. The timeout is what turns "no acknowledgement" from something nobody notices into something visible.

An order sent but never acknowledged is the worst failure mode in EDI, because both sides believe the other is dealing with it. Set the timeout to the partner's stated turnaround plus a margin, and check the console when one expires.

Inbound

Inbound is enabled per partner and carries its own token, so accepting messages is a deliberate act per counterparty rather than a general opening.

Commissioning

Expect to exchange test messages for a while. Agree the message types, the version and the identifiers in writing first, then test each message type in both directions before going live. Partners rarely accept a message they were not expecting.

Worked example

A supplier onboards a retail customer using EDIFACT over AS2. The retailer sends its identifiers and its AS2 certificate. A transport is configured, the partner record created with the test indicator on, and orders and despatch advices are exchanged in test for three weeks. Once both sides confirm, the test indicator comes off and inbound is enabled.

Recommendations

• Copy identifiers, never retype them.
• Commission with the test indicator on.
• Set acknowledgement timeouts and act on expiries.
• Agree message types and versions in writing before configuring anything.

Message Maps and Control Numbers

Two partners sending the same message type will not send the same message. Maps are how one document type serves both.

Where to find it

Architect Panel → ERP - Trading & Analytics:

• EDI Maps — segment-to-field mapping per partner, message type and direction
• EDI Control Numbers — the sequence counters per partner
• EDI Messages — what was actually sent and received

Maps are per partner and per direction

A map row ties a segment path in the message to a slot in your document, for one partner, one message type and one direction. It can mark a field required, apply a transform, or supply a constant where the partner expects a fixed value you do not otherwise hold.

Inbound and outbound are mapped separately even for the same message type, because what a partner sends you and what they expect back are rarely mirror images.

Levels and ordering

Rows carry a level and a sort order, which is what handles the nesting real EDI messages have — a header with lines, and lines with sub-lines. Getting the level wrong is the usual cause of a map that produces a header value repeated on every line, or line values collapsed into one.

Mark required fields honestly

A field the partner will reject the message for is required; mark it. It is far better to fail on your side with a clear reason than to send an incomplete message and receive a rejection whose text is a segment reference.

Build maps from their specification

Work from the partner's specification document, not from a sample message. A sample shows what one message happened to contain, not what is mandatory, what is conditional, or what codes are permitted. Maps built from samples fail on the first message that differs — typically the first one with a special case in it.

Control numbers

Every partner has counters holding the next value for each type of control number. Interchanges and messages are numbered sequentially, and the partner uses those numbers to detect gaps and duplicates.

Never reset a counter

This is the one hard rule.

Resetting means resending numbers the partner has already seen, so they will treat genuine new documents as duplicates and discard them — silently, because from their side that is exactly what duplicate suppression is for. The result is orders that were sent, accepted by the transport, and never processed.

If numbering must change, agree it with the partner first. Left alone, the counters look after themselves.

Test both directions per message type

Send and receive each message type before going live. An outbound map that works tells you nothing about the inbound one for the same document.

Worked example

A supplier maps a customer's purchase order inbound: header segments to the document header, line segments at level 2 to document lines, with the customer's own product code transformed to the internal item reference. A constant supplies the delivery method the customer omits but the warehouse requires. Twenty test orders are processed before the map is trusted.

Recommendations

• Never reset a control number.
• Map from the specification, not from samples.
• Check levels when values repeat or collapse.
• Test each message type in both directions.

AS2, OFTP2 and the Other Transports

Five transport kinds are provided. Which you use is usually decided by the partner, not by you.

Where to find it

Architect Panel → ERP - Trading & Analytics:

• EDI Transports — the five kinds, all shipped disabled
• AS2 Certificates — certificates and their expiry
• EDI Trading Partners — which transport each partner uses

The five

• SFTP — files to or from a server. Simple, widely understood, no built-in receipt.
• HTTPS — direct posting. Simple, and immediate.
• EDI VAN mailbox — a value-added network in the middle. One connection serves many partners and the VAN handles their differences, at a cost per message.
• AS2 — signed, encrypted, direct, with a signed receipt. The common retail requirement.
• OFTP2 — the automotive equivalent, likewise secure and receipted.

Why AS2 and OFTP2 exist

Both give you non-repudiation: a signed receipt proving the partner received the message, and proving what they received. Encryption in transit is the easy part; the receipt is the point.

In a dispute about whether an order was sent, a signed receipt settles it. An SFTP transfer log does not, which is why large trading partners mandate these.

Certificates

AS2 uses certificate pairs — yours for signing, theirs for encryption — and certificates expire.

An expired certificate stops the exchange dead, and it does so on a date known well in advance. Diary the renewal, and coordinate it: a certificate swap needs both sides ready, so it is a planned exchange rather than something to do when the connection breaks.

Keep the AS2 Certificates list current and check expiry dates quarterly. This is the most common avoidable EDI outage there is.

Choosing

Take the partner's requirement. Where you genuinely have a choice: SFTP or HTTPS for a small number of technically capable partners; a VAN when you have many partners and would rather pay per message than manage each connection; AS2 or OFTP2 when non-repudiation matters or the partner insists.

A VAN is often the right answer for a first EDI implementation — it removes most of the per-partner variation at a predictable cost, and you can move high-volume partners direct later.

All disabled by default

Every transport ships disabled with no credentials. Enable only what you use. A configured transport nobody is using is a credential to rotate and an attack surface to defend, for no benefit.

Worked example

A manufacturer trades with three retailers over AS2, one automotive customer over OFTP2, and a dozen smaller customers through a VAN. Certificate expiry is a diary item 60 days ahead of each date, and the AS2 renewals are agreed with each retailer in advance. The VAN removes twelve separate connections' worth of maintenance.

Recommendations

• Diary certificate expiry 60 days ahead.
• Enable only the transports you use.
• Consider a VAN for a first implementation.
• Keep credentials per transport, not shared across partners.