EDI & Trading Partners

Trading Partners and Transports

EDI is how larger customers and suppliers expect to trade — orders, despatch notes and invoices exchanged as structured messages rather than as email attachments.

A trading partner

Each partner is configured with:

• Standard and version — which EDI dialect they use. Partners differ, and a partner may change version on a date they choose.
• Interchange qualifiers and IDs, both ways — how you identify yourself to them and how they identify themselves to you. These are supplied by the partner and must match exactly.
• Acknowledgement expectation — whether they expect a functional acknowledgement, and whether you should expect one back.
• Transport — how messages physically move.

Transports

SFTP, FTPS, HTTPS, VAN and direct API are supported, along with AS2 and OFTP2, which are covered separately. The partner tells you which they use; it is rarely negotiable.

Every transport ships disabled with no credentials, in keeping with the platform convention. Enable and configure only what you need.

Acknowledgements

Take the acknowledgement expectation seriously. A partner expecting an acknowledgement treats its absence as a failed delivery, and will often chase or resend. Equally, if you expect one and it does not arrive, that is your signal a message did not land — the absence of an error is not evidence of delivery.

Onboarding a partner

Expect it to take longer than the configuration suggests. Partners usually require test exchanges before going live, and their specification will have details their documentation does not mention. Budget for a testing cycle, and keep the partner's specification alongside the configuration.

Every interchange is recorded

Both directions are logged. When a partner claims they sent an order you never received, or that they never received your invoice, that record is what settles the question.

Message Maps and Control Numbers

An EDI message is a structured set of segments and elements. A map connects those to the slots on your documents.

Mapping

Each mapping line ties an element position to a document slot — an element within a particular segment becomes the order number, another becomes the delivery date. Because it maps to document slots rather than directly to your columns, the same map works regardless of what you called your columns; the binding resolves the rest.

Maps are per partner

Two partners on the same standard will still differ, because the standards permit choices and everyone makes them differently. Expect a map per partner, and do not assume a working map can be copied without checking.

Control numbers

EDI uses control numbers at interchange, group and transaction level to sequence messages. Partners check them: a gap suggests something was lost, and a repeat suggests a duplicate.

Allocation is atomic, so two messages sent simultaneously cannot take the same number. This is the sort of thing that appears to work in testing and fails under load, which is why it is handled centrally rather than by each transport.

Nothing is applied twice

Every message carries a unique key across the partner, direction and control numbers. A redelivered interchange — which partners do routinely after a timeout — is recorded once and applied once. Without this, a resent order becomes two orders, and the customer receives double.

When a map is wrong

A mismapped element usually shows up as a sensible-looking document with one field wrong: a date in the wrong place, a quantity against the wrong line. Compare against the partner's specification rather than against what looks reasonable — EDI element positions are not intuitive, and a plausible guess is how the error arrived.

Test with real messages

Ask the partner for genuine sample messages rather than constructing your own. Real traffic contains the optional segments, unusual characters and edge cases that a clean test message will not.

AS2 and OFTP2

AS2 and OFTP2 exchange EDI directly over the internet with cryptographic signing and encryption, rather than through an intermediary. Retail and automotive partners commonly require one of them.

What they need

Both are certificate-based. For each partner you hold their public certificate, used to encrypt what you send and verify what they sign, and your own key pair, used to sign what you send and decrypt what you receive.

Receipts

AS2 uses an MDN — a signed receipt confirming a message arrived and verified. A signed MDN is meaningful evidence of delivery, which is why partners rely on it commercially. Configure whether MDNs are synchronous or asynchronous to match what the partner expects.

Private key material

Your private key has to be stored, because it is needed at the moment a message is sent. It is held with the partner configuration, and the field is hidden from the ordinary datastore editor so it is not displayed casually.

Be clear about what that does and does not mean. It prevents the key being shown on a normal admin screen. It does not encrypt it beyond the platform's usual protections, so anyone with database access has it — the same exposure as every other credential the platform stores. Treat database access accordingly, and keep the number of people with it small.

Certificates expire

This is the most common cause of a working AS2 link failing. Certificates typically last one to three years and then stop, usually without warning to anyone watching the right screen.

Diary the expiry of both your own certificate and every partner's when you configure them. Renewal has to be coordinated — the partner must load your new certificate before you start signing with it — so start weeks ahead, not days.

Going live

Both transports ship disabled. Enable, exchange test messages in both directions, confirm receipts arrive and verify, and only then switch production traffic. Keep the previous route available until you have seen a full cycle succeed.