EDI: what works today and what does not

Summary

EDI is the standard format large customers use to exchange documents: instead of typing into a portal, their system generates a file and delivers it. We support X12, the North American standard, and only some of its documents.

Important: this module is halfway there, and it is worth knowing where the halfway line is. Inbound warehouse shipping orders (943) work well. Shipping orders (940) and ship notices (856) only come in if their lines use a certain format. What we send back to the partner (945) is generated but not delivered on its own, and there is no screen to see messages. Before committing to an exchange with a customer, read the three lists below and test with real files from their system.

The detail of each document is in:

To see how what arrives through EDI lands in daily operations, read Integrations: API and EDI in daily operations.

Before you start

The warehouse needs two modules: API (files come in through it) and EDI. We turn them on.
The customer has to exist, with their products set up using the same code that comes in their files. See Products and units.
The customer needs an access key, just as for the API. See Connecting a system through the API.

What works today

Receiving 943 inbound notices with their lines in W04 segments. They become an advance ship notice with its receipt, ready in the receipt list.
No duplicates. If the partner sends the same file twice (same interchange and transaction control numbers), it is recognized and nothing extra is created.
Setting aside what cannot be processed, with the reason recorded, instead of processing it halfway.
Answering the sender with the result: processed or set aside, and why.
Generating the 945 shipping advice when a shipment is closed, if the partner has it configured.
Keeping the original file exactly as it arrived.
Isolating each customer: one customer's key can never send files in another's name.

What works only with a certain format

Document	What happens today
940 (shipping order)	A confirmed, allocated shipment is created only if the lines come in W12 or W04 segments. The usual 940 carries its lines in W01, which is not read today: the file is set aside with the reason that it has no lines. See Shipping orders: 940.
856 (ship notice)	The same: only if the lines come in W04. The usual 856 carries them in LIN and SN1, which are not read today. See Inbound notices: 943 and 856.
Files with several transactions	They are read as if they were one: the lines of all of them end up in a single document. Ask the partner for one transaction per file.

What does not work yet

Common request	Status
Delivering the 945 to the partner automatically	No. The file is generated and stored, but today someone has to pull it out and deliver it. Ask us.
Warehouse stock transfer receipt advice (944)	Does not exist. When a receipt is confirmed a callback can go out through the API (see Callbacks), but not a 944.
Functional acknowledgment (997)	Does not exist. A partner that requires it for every exchange cannot be served yet.
Inventory inquiry or advice (846)	Does not exist. The stock look-up through the API does.
Receiving files over SFTP or AS2	No. The only inbound channel is the web service.
Per-partner code and unit cross-references	Not applied. The code in the file must match the catalog SKU exactly.
Dates in the file (expected arrival, ship date)	Not used. The date segment is read but does not reach the document.
Full destination address	No. Only the consignee name is taken from the 940.
A screen to see messages and their errors	Does not exist. Nothing EDI shows up in the menu.
A reprocess button	Does not exist.
EDIFACT (the European standard)	No. X12 only.

How a file comes in

The customer's system (or their EDI provider) sends the full X12 file to the warehouse web service, with the same access key as the API.
The warehouse reads the sender id from the file and looks for the partner profile within the key's customer. One customer's key can never send files in another's name, even if it knows their id.
If that interchange had already arrived (same control numbers), it returns the original result and does nothing else.
It reads the headers and lines: the product code comes after its qualifier (VN, VP, UK, UP, IN, SK or B8), with the quantity and the unit.
It creates the advance ship notice with its receipt, or the shipment, depending on the document type.
It answers with the result: processed, or set aside with the reason.

The detail of the request and the response is in Sending an EDI file.

What happens next at the warehouse

The notice or the shipment shows up in its list just as if it had been entered by hand: the system records that it came through EDI, but no screen shows it today. Operators get the new-receipt or new-shipment notification if the warehouse has it configured.
Stock only moves when the receipt is confirmed or the shipment is closed. See The life of stock.
Charges are created on confirm and close, according to the customer's rate card. See Where each charge comes from.
When one of the customer's shipments is closed, the 945 is generated (if configured), besides the bill of lading and the packing list.

Setting up a trading partner

As with the API, we do this for you: there is no screen. What we need from your customer:

Their sender id (the one in ISA06 of all their files) and its qualifier.
Which documents they will send (943, 940, 856) and whether they expect the 945 back.
The X12 version they use (for example, 004010).
A real file of each type, from their system, to check where the lines come.

We turn on the API and EDI modules in the warehouse, create the partner profile tied to the warehouse and the customer, and hand over the access key.

On the warehouse side, that customer's products must already exist in the catalog with the same code that comes in their files. If an unknown code arrives, the file is set aside.

The test before going live

Send a test inbound notice and check that its receipt shows up with all its lines.
Send the same file again and check that it is not duplicated.
Send a real shipping order from the customer's system and check that it arrives confirmed, allocated and with all its lines. If it is set aside for lack of lines, tell us before going further.
Close a shipment and ask us for the generated 945 so the partner can validate it.
Send a file with an unknown product on purpose, and check that it is set aside without creating anything.

When a file cannot be processed

The message is neither discarded nor processed halfway: it is set aside with the reason written down. The reasons come exactly as the service returns them:

Reason	Meaning	What to do
`Unknown SKU: NT-9999`	A code that does not exist in the catalog.	Add the product and resend with new control numbers.
`Unsupported transaction type: 997`	A document type we do not handle.	Agree with the partner not to send it to this address.
`ASN payload must include at least one line.`	A 943 or 856 with no lines we can read.	Review the line format with us.
`Shipment payload must include at least one line.`	A 940 with no lines we can read (the typical case: lines in W01).	Review the format with us.
`Partner has no resolvable warehouse/client.`	The partner profile has no valid warehouse or customer.	Write to us.

The system that sent the file gets that reason in the response, so the customer's integrator can see it right away.

It is different when the file's sender id does not match any partner of that customer, or the file arrives empty: then it is rejected up front with an error and nothing is stored.

Important: on the warehouse side none of this shows on screen. There is no EDI inbox and no alert to the supervisor. If your customer says they sent something and it is not there, ask for the response they got, or write to us: we can see the exact reason. Once the cause is fixed (for example, by adding the product), the customer has to send the file again with new control numbers.

Good practices

One transaction per file.
New control numbers for every different submission, and the same ones only when it truly is a resend of the same file.
Check with the customer every week whether any files were set aside: since there is no screen, the only way to find out is the response their system received.
Keep the catalog up to date before the customer launches new products.

Frequently asked questions

My customer fixed a file and resent it, but nothing changed

If they resent it with the same control numbers, the system recognizes it as a repeat and returns the original result without touching anything, even if the original was set aside. For the fix to go in, it has to be sent with new control numbers.

Does EDI move stock directly?

No, and it is right that it does not. EDI only creates documents: advance ship notices and shipments. Stock moves through normal warehouse actions, when someone confirms a receipt or closes a shipment. That way, a badly built file can never throw your stock off.

My customer sends a document type that is not on the list

It is set aside with the reason "unsupported type". The risk is that nobody at the warehouse finds out for weeks, because no screen shows it. If you are going to receive a type other than 943, 940 or 856, tell us before going live.

My customer uses their own product codes

Today the system does not translate codes: the code in the file must match the catalog SKU. The two ways out are to set up the products with the customer's code, or have their system send our code. The same goes for units of measure: check them during the test.