EDI requirements for Walmart suppliers running Odoo

What Walmart publishes, and where the EDI detail lives

Walmart's public supplier pages cover the application path, the Standards for Suppliers that every supplier and facility is held to, and the setup identifiers: a US federal tax identification number on application documents and a Dun and Bradstreet registration. The public material stops before the EDI specification, transaction-set list and integration guideline.

That absence is the shape of the programme. The document set, the testing sequence and the scorecard that apply to you arrive through Walmart's supplier systems after vendor setup, scoped to your department and channel. So the useful first questions go to your buyer or merchant contact: which documents your category trades, which channel you are being set up for, and where your integration guideline lives. The free Requirement Check reads whatever you are given and turns it into an Odoo-side scope.

The documents behind a mass-merchant mandate

A mass-merchant programme generally runs a four-document loop with an acknowledgment discipline on top. The order arrives as an 850 purchase order. An 855 order acknowledgment answers it inside the programme's window. The 856 advance ship notice precedes the freight, structured shipment, order, pack, item, and the 810 invoice has to match the order it bills. The 997 functional acknowledgment confirms receipt of each envelope, and large programmes read its absence as non-receipt.

Change orders, inventory feeds and sales reporting ride on further sets where a category trades them, and the X12 catalog covers each number in plain language. Which of them your agreement actually mandates is a guideline fact, so collect it from your setup material and read it before scoping anything.

Which route your files travel

Mass-merchant suppliers reach their retailer three broad ways: a platform that translates and bills per document, a direct connection over AS2 where the mandate allows one, or web forms at low volume. If your setup names SPS Commerce, the Odoo side of an SPS Commerce connection is covered separately. Whichever route your programme runs, the route only moves the files. The mapping between their documents and your Odoo records is the part that decides whether the connection holds, and it is the same work on every route.

What changes inside your Odoo

There is no X12 in Odoo, so a Walmart programme is a connector sitting on top of it. The four Odoo-side mechanisms are the same ones every retail mandate exercises. Packagings carry the casepack, per product, with a Unit Name, Quantity and Reference Unit. The GS1 nomenclature maps the GTIN to the product Barcode field and the SSCC to the Package name, which is what the 856 hierarchy and the carton labels are built from. The retailer's PO number belongs in Customer Reference, the field Odoo exposes as client_order_ref, because every document coming back quotes it. And the Delivery Date against Expected date decides what your warehouse promises into the routing window.

Mass merchandise adds pressure on the item master: department numbers, item identifiers and casepacks have to agree across your Odoo, their item file and your labels, and the mismatches surface as receiving exceptions weeks later.

Testing and enforcement, in general form

Large programmes test in stages: connectivity, then document validation against the guideline, then a watched production window. Enforcement runs on scorecards and deductions, and the deduction reaches you as a line on the remittance advice with a code on it. How chargebacks land in Odoo covers counting them, and the rates and windows that apply to you are guideline facts to collect in writing before a go-live date is agreed.

For the wider US picture, see US retail EDI compliance. The grocery mirror of this page is Kroger EDI requirements, and Canadian general merchandise runs through Canadian Tire EDI requirements.