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.