Inbound orders and acknowledgements
Lesson 8 of 22 8 min read
Settings that decide where retailer orders are fulfilled and how their products are matched, plus the order acknowledgement and the X12 functional acknowledgement.
The purchase order is where every retailer flow begins, and the acknowledgement is often the
first thing a retailer checks you've got right. This lesson covers the settings on the Order
and Order Acknowledgement Configurations, and explains the separate, more technical
functional acknowledgement.
Inbound orders
Decision: which warehouse fulfils these orders?
| fulfillmentLocationId | When set, every order from this EDI Integration is assigned to this fulfilment location: the warehouse or facility responsible for fulfilling it. |
|---|
Use it when all of a retailer's orders ship from one place, for example a 3PL that handles your retail trade while your own unit handles direct orders.
Decision: how should order lines be matched to products?
| edifact.productIdentifierPriority | For EDIFACT messages, the order in which product identifier types are tried when matching a line to a product, for example gtin then supplier-code. If the first type finds no match, the next is tried. |
|---|
This setting appears on almost every EDI document type. It answers the same question each time: which code on the line should we trust first?
Tip
If a retailer's GTINs are reliable but their own codes change between seasons, put gtin
first. If they reuse barcodes across pack sizes, the supplier code may be the safer first
choice. Ask the retailer which they consider authoritative.
Order acknowledgements
An order acknowledgement (or order response) tells the retailer you've received and accepted their order.
| identifierTypeMap | Maps product identifier types to alternative types when building the acknowledgement, so you can send identifiers back in the form the retailer expects. |
|---|---|
| edifact.productIdentifierPriority | The product identifier priority for EDIFACT acknowledgements, as for orders. |
| paymentTermsDescription | The payment terms to state on the acknowledgement when the order it answers doesn't carry any, for example Net 30 Days. An acknowledgement has no terms of its own, so it takes them from the order and falls back to this. Required by partners that make the terms description mandatory, such as Backcountry. |
Functional acknowledgements (X12 only)
A functional acknowledgement is different from an order acknowledgement. It's a technical receipt that says "your message arrived and could be read", not "we accept your order".
The key facts:
- There is no setting to turn it on. It's produced by a document-to-document map from the
received document type to
functional-acknowledgement, for exampleordertofunctional-acknowledgement. Turning that map on for an organisation is what decides whether a partner is acknowledged. - Maps exist for
orderandorder-change. - Only X12 has one. EDIFACT (used for inventory and sales reports) and Tradacoms (used for remittances) have no acknowledgement message, so those documents can't be acknowledged this way.
- One acknowledgement is produced per received document, which means one per transaction set.
- A message that fails to parse produces no Documents, so it isn't acknowledged at all.
No functional acknowledgement can mean a parse failure
If an X12 partner says they never received a functional acknowledgement for a message, check whether the message failed to parse. Unparsed messages create no Documents and so get no acknowledgement.
A US partner for Northfield Pantry
Northfield signs a second retailer, a US outdoor store that trades in X12. Its specification
requires a functional acknowledgement for every purchase order and order change, and an order
acknowledgement that always states payment terms. Its orders never carry terms. The Supply
Lens team turns on the order and order-change to functional-acknowledgement maps, and
sets paymentTermsDescription to Net 30 Days on the Order Acknowledgement Configuration.
Recap
fulfillmentLocationIdsends every order from the Integration to one fulfilment location.edifact.productIdentifierPrioritysets which product code is tried first, with fallbacks.identifierTypeMapandpaymentTermsDescriptionshape the order acknowledgement for the retailer.- A functional acknowledgement is a technical receipt, X12 only, switched on by a map rather than a setting.
- Messages that fail to parse produce no Documents and no functional acknowledgement.
Quick guides for this topic
Your progress is saved in this browser. Create a free account to keep it everywhere, take quizzes and earn certificates.