Loading

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.