Sending EDI Documents

Sending EDI Documents

How an outbound document is produced

Outbound documents are built by a script calling edi.emit, or automatically as a turnaround or an acknowledgement. There is no "compose a document" screen — the data comes from your system, so the trigger lives where that data is.

edi.emit({
  partner: "ACME Steel",     // the partner record
  set: "855",                // transaction set
  spec: "855-acme",          // outbound mapping spec
  data: { purchaseOrderAcks: [ ... ] }
});

Emitting does five things in order: reserve a control number, build the envelope with every trailer count computed, validate the result by round-tripping it, deliver it over the partner's transport, and log it in the console as an outbound transaction.

Control numbers

Each partner record carries an interchange control number counter. Emitting reserves the next value atomically — two documents built at the same instant cannot take the same number.

If you are migrating from another EDI system, set the counter above the last number that system sent, so the sequence the partner sees keeps climbing.

Choosing a transport

One picker on the partner form, Outbound delivery, selects how documents reach them. The options and what each needs:

Push to partner's server — direct from DataMagik

DataMagik dials the partner's FTP, SFTP or FTPS server itself, from the cloud. Nothing on your site is involved.

1. Create an FTP connector record (Connectors > File Connectors) with the partner's host, port, protocol and credentials.
2. On the partner, choose this transport and select that connector.
3. Set the remote folder, and optionally a filename pattern. The default filename carries the transaction set and the interchange control number.

Confirming it worked: the console row shows status sent. A failure shows failed: with the connection error, or undelivered: with a configuration reason such as connector-not-found or connector-disabled.

Partner collects from our file gateway

Instead of pushing to them, you stage the document in your own hosted gateway and the partner collects it. This is the delivery mode with the fewest moving parts: no credential of theirs to hold, no firewall of theirs to negotiate, no retry loop to own.

1. Create a gateway principal and link it to this trading partner.
2. Give the partner a login on that principal.
3. On the partner, choose this transport and set the outbound folder (defaults to edi).

The document is staged at /outbound/<folder>/<file>. Partners can only read /outbound; they cannot write into it.

Confirming it worked: two separate facts, and the difference matters when someone asks "did they get it?". Staging is recorded when the file is placed; collection is recorded separately when the partner actually downloads it, and shows as a "Collected" line on the transfer in the transfers console.

Email the document as an attachment

The built document is attached to an email. Configure the recipients and the sending account on the partner. Useful for low-volume partners and for a human-readable copy alongside a machine transport.

Confirming it worked: the console shows sent; delivery beyond that is whatever your email provider reports.

Plex mailbox

The document is handed to a Plex EDI mailbox over the Plex Connect API. See Talking to Plex for the full setup — it is the one transport that can also retrieve.

Push via on-site connector agent (SFTP or FTP)

The transfer is performed by a connector agent running inside your network. Choose this when the target is a machine on your LAN rather than a partner on the public internet.

Outgoing delivery script (or none)

The default. The partner's outgoing script is run with the built document in its input context, and performs the transmission itself using any API it likes.

Sending a document again

Open the document in the console. An outbound document has two actions, and which one you want depends entirely on what the partner has already recorded.

Resend is the right answer to "we never got 000000101" — they are asking for that document, and it has to arrive under that number. Sending a new number instead would look to them like a second order.

Regenerate is the right answer when they did record the number and want a clean copy: a partner that already has 000000101 will reject a repeat of it as a duplicate. The business content is untouched and only the envelope is rewritten, with trailer counts recomputed, so they receive the same order under a number they have not seen. Regenerate asks for confirmation, because it spends a number from a sequence partners watch.

There is no "upload a file to send" action: outbound documents come from edi.emit, a turnaround, or an acknowledgement. The console's only paste-in field is Reconcile ack…, which ingests an acknowledgement a partner sent you and transmits nothing.

Delivery status vocabulary

Delivery is best-effort and never fails the build: the document is always produced, validated and logged, so a transport outage costs a retry rather than the document.