Define the business event before mapping the message
An EDI connection is useful when the trading partners agree what a message means and what action it permits. A successfully transmitted document does not establish that the receiving warehouse accepted its quantities, that goods physically arrived, or that an invoice is payable.
For a China logistics integration, document each event from the commercial instruction through shipment and financial reconciliation. Then choose the transaction format, implementation version and partner-specific guide. Asking a provider whether it “supports EDI” is only the beginning of that discussion.
Keep the three message purposes distinct
X12's transaction-set directory describes the 856 Ship Notice/Manifest, 810 Invoice and 214 Transportation Carrier Shipment Status Message. Their purposes differ even when several fields refer to the same order.
| Message | Business question | Acceptance check to agree |
|---|---|---|
| ASN or shipment notice, such as X12 856 | What is being shipped, and how is it packed? | Purchase-order references, item quantities and package hierarchy are usable |
| Invoice, such as X12 810 | What is being charged and on what basis? | Currency, references, charges and matching rules are correct |
| Carrier status, such as X12 214 | What transport event occurred? | Shipment reference, event code, location and timestamp resolve correctly |
These examples do not prescribe X12 for every partner. A recipient may use another standard or a portal. Nor does a transaction-set name specify every required field. Obtain the actual partner guide and test against its required values, identifiers and permitted message sequences.
Design separate technical and operational acknowledgements
Create at least three observable outcomes: transport received the file, the document passed the agreed syntax checks, and the business application accepted or rejected its contents. Where the partner uses formal acknowledgement messages, map those according to its guide; do not invent a universal acknowledgement sequence.
An illustrative ASN lists 120 units, but its product identifier is unknown to the warehouse. The file can arrive successfully and pass syntax validation while receiving cannot use it. If the dashboard turns green on file delivery alone, purchasing may assume the shipment is ready to receive. Show the business rejection, affected lines and owner instead.
Physical receipt is another event. An accepted ASN for 120 units remains an expectation until the warehouse counts and records the delivery. A receipt of 118 must produce a discrepancy, not an automatic adjustment that conceals the shortage.
Agree identity, time and change rules
Maintain a mapping register for seller item codes, supplier item codes, purchase-order lines, cartons and transport references. Specify the unit of measure. Twelve pieces and twelve cartons can both be syntactically valid while representing very different stock.
Record timestamps with their time-zone context and separate event time from the time the message reached the integration. A delayed carrier update should not appear to be a newly occurring movement. GS1 EPCIS provides a useful event-data framework for discussing what happened, when, where and why; adopting the vocabulary does not make inconsistent source events accurate.
Also agree how changes work. Can a notice replace an earlier one? Must a cancellation identify the original document? What happens if receiving has already started? Put those rules in writing before choosing an automated retry policy.
Test the cases that a clean sample file misses
Use partner-approved test documents to cover practical failures:
- A duplicate delivery of the same document must not create a second receipt or invoice.
- An amended quantity must reach the correct version of the order.
- An unknown product must produce a visible rejection with a responsible owner.
- A partial shipment must leave the correct remainder open.
- An out-of-order status update must not move a delivered parcel back into transit.
- A disputed invoice line must remain distinguishable from an accepted shipment.
Define a stable document identity and replay procedure. Retrying after a timeout should recover the existing transaction where appropriate, rather than make a second commercial instruction.
Reconcile the connection after launch
At agreed intervals, compare expected documents, technically received documents, accepted business records and unresolved exceptions. Track the age of the oldest actionable rejection as well as total message volume. High traffic can coexist with a small number of costly failures.
Keep a named business owner for quantities and charges, alongside the technical support contact. The integration is ready for routine use when a rejected line can be traced back to its source, corrected under an agreed rule and replayed without creating duplicate inventory or financial records.
Sources and verification links
Operational rules can change. Check the linked primary sources and confirm shipment-specific requirements before booking.