Receiving purchase orders via EDI and creating sales orders with Boomi

A supermarket chain is about to become your biggest customer, on one condition: purchase orders will arrive as EDI messages, and you must acknowledge them. Today, someone in the sales office receives PDF orders by email and types them into the ERP. This article explains what a robust inbound order flow looks like, why “translate and insert” is not enough, and then builds it with Boomi B2B/EDI Management and Boomi Integration.

Why “translate and insert” is not enough

The tempting version is a straight line: receive the EDI file, convert it to the ERP’s format, create the sales order. It breaks on the first unusual order:

Codes don’t match. The retailer identifies the store by a GLN and the products by EAN barcodes. Your ERP uses customer C-1042, ship-to address C-1042-07 and item codes like OL-500.
Duplicates happen. Retailers resend orders, and transports occasionally deliver twice. Two sales orders mean two shipments.
Bad data reaches the ERP. An order for a discontinued product or at an outdated price creates a sales order that someone has to fix by hand, often after it has already been picked.
The retailer never hears back. Without a functional acknowledgement, the retailer can’t tell whether you received the order, and some retailers penalise that.

The pattern: receive, acknowledge, translate, validate, create

A reliable inbound flow has five distinct stages:

retailer ──► receive & parse (envelope, syntax) ──► functional ack (CONTRL / 997)
                       │
                       ▼
             translate codes (GLN, EAN → ERP codes)
                       ▼
             validate (duplicates, products, prices)
                ├── ok ──► create sales order in ERP
                └── problem ──► exception queue + alert to sales office

Two points are worth highlighting. The functional acknowledgement only says “the message was syntactically valid”; it is sent before any business validation. And business problems are not rejected silently: they go to a person, who either fixes the data or calls the buyer.

Building it in Boomi

In Boomi, the EDI side is configured through Trading Partner components and EDI profiles, and the ERP side is a normal integration process. Boomi’s B2B/EDI Management experience has evolved over releases, and exact tab and field names can differ in your account, so use the steps below as a guide to the order of work. We use an EDIFACT ORDERS (EANCOM) example; the X12 850 version follows the same steps with X12 settings.

Step 1: Create the EDI profile

Create an EDI profile for the retailer’s ORDERS message, with the EDIFACT standard and the version used in the retailer’s implementation guide (for example D96A).
Rather than defining every segment by hand, start from Boomi’s built-in standard definitions where your release offers that option, and then trim and adjust the profile to match the retailer’s guide.
Check the details that often cause trouble: mandatory segments, the qualifiers the retailer uses in NAD (buyer, delivery party, supplier) and how quantities and prices are expressed.

Step 2: Set up the trading partners

You need two Trading Partner components:

Your company. A trading partner with the “my company” classification, holding your own identifiers: your GLN as the interchange ID and the qualifier the retailer expects (for EANCOM, typically 14).
The retailer. A trading partner for the supermarket chain, with:
- the EDIFACT standard and the retailer’s interchange ID and qualifier,
- the communication method the retailer uses, for example AS2 or SFTP (AS2 setup is covered in Setting up AS2 with a trading partner in Boomi),
- the document types you exchange, linking ORDERS to the profile from step 1,
- the acknowledgement options: ask Boomi to generate CONTRL messages for received interchanges (or 997s for an X12 partner), at the level the retailer’s guide requires.

If you have several retailers, a Processing Group lets one process receive documents from all of them and route by partner and document type.

Step 3: Receive and acknowledge

Create a process whose Start shape uses the Trading Partner option, with your company as the receiver, the retailer (or processing group) as the sender and EDIFACT as the standard.
Boomi handles the envelope (UNB/UNZ), splits the interchange into individual messages, validates them against the profile and generates the functional acknowledgements you configured.
Route the generated acknowledgements back to the retailer. In typical setups, acknowledgement documents flow through the process alongside the orders; a Route shape on the document type sends them to an outbound Trading Partner step for the retailer. Check the documentation for your release, as the recommended way to return acknowledgements has varied.
Messages that fail syntax validation are reported in the acknowledgement as rejected. Make sure they also raise an alert on your side.

Step 4: Translate codes

Add a Map shape from the ORDERS profile to the ERP sales order profile:

Map the order number (BGM) to the customer’s purchase order reference field in the ERP.
Use Cross Reference Table lookups inside the map to translate the buyer and delivery-party GLNs into the ERP customer C-1042 and ship-to C-1042-07, and EAN barcodes into item codes. Keeping these translations in tables rather than in the map lets the sales office maintain them without a redeploy (see Cross-reference tables in Boomi).
Convert dates from EDIFACT format (20261023, format code 102) to what the ERP expects.

Retailer value	Meaning	ERP value
`5200000000017` (NAD+BY)	Buyer GLN	`C-1042`
`5200000000123` (NAD+DP)	Store 7 GLN	`C-1042-07`
`5201234567890` (LIN)	EAN of the product	`OL-500`

Step 5: Validate before creating

Between the map and the ERP call:

Duplicate check. Query the ERP for an existing sales order with the same customer and purchase order number (PO-45871). If one exists, don’t create another; log it and stop.
Business checks. Use a Business Rules shape (or Decision shapes) to check that every product exists and is active, quantities are positive and prices match your price list within an agreed tolerance.
Exceptions. Orders that fail go to an exception path: write them to a table or a queue the sales office works from, and send an alert with the PO number, store and reason.

Step 6: Create the sales order

Call the ERP with its connector to create the sales order. Store the ERP’s sales order number together with the retailer’s PO number, so later documents (order response, despatch advice, invoice) can refer back to it.

Step 7: Test with the retailer’s files

Run the retailer’s sample files through the process in Test mode first. Then run a test cycle with the retailer: they send test orders, you check that the acknowledgements reach them and that the sales orders in your test ERP are correct, line by line.

Before you go live

Acknowledgements on time. Confirm with the retailer which acknowledgement they expect and how quickly.
Monitor received documents. Use process reporting and the EDI tracking information to see what arrived, what was acknowledged and what failed.
Owner for exceptions. Someone in the sales office must check the exception queue every day.
Code tables complete. Load all stores and active products into the cross-reference tables before the first live order, and agree on who updates them when the retailer opens a new store.
Plan the next documents. ORDRSP, DESADV and INVOIC will follow. Reuse the same trading partner and code tables.

Summary

A purchase order flow that only translates and inserts works until the first unknown store or resent order. Receiving, acknowledging, translating, validating and only then creating the sales order keeps bad data out of the ERP and the retailer informed. In Boomi, trading partner components and EDI profiles handle the EDI side, and an ordinary process with maps, cross-reference tables and business rules handles the ERP. For the bigger picture, see our guide B2B integration and EDI: what it is and when you need it.