Master data is the orphan: the ERP-side work nobody owns
An EDI manager wrote up a week of failure cases and reached a conclusion I keep coming back to. In almost every case, the EDI transaction did exactly what it was told to do. It carried bad or incomplete data faithfully from one system to another. The EDI problem was usually a master-data problem, a process-timing problem or a business-rule mismatch that happened to become visible in an EDI document. Reading the ERP communities confirms it. Different vocabularies, same four faults.
Units of measure
An SAP SD consultant who has done EDI since 2013 wrote a whole post telling people not to ignore units of measure. The inbound order carries the customer's unit code, SAP converts it through its unit table, and an unassigned code fails one way while a unit missing from the material master fails another. The war story was a third-party warehouse test that failed because the outbound message sent the internal code for pieces while the warehouse expected the ISO code. The four remedies listed, in order of preference, were to accept being a multi-unit organisation, push the conversion to the network or middleware, substitute materials, or write conversion rules in SAP, which the post describes as far from well known. On JD Edwards the same fault appears as the inbound order program failing when the EDI unit differs from the item master. On SYSPRO it is an error code on the import. On a mid-market system the case-to-each conversion becomes, in one practitioner's words, the thing that is actually painful, after the EDI file itself was fine.
Location numbers
The same SAP consultant's second post was on partner determination: how the system works out which customer an inbound order belongs to. The two designs are one partner profile per customer with the location-number mapping kept in SAP, or one profile for the network with the mapping kept there. The traps listed are the retailer's. A large American retailer sends only the buyer in the message and no sold-to, so the most reliable source of the sold-to is the envelope's sender. Another retailer started sending fictional location-style numbers with wrong check digits per product group. And location numbers live in two places in SAP, the partner table and the customer master, and might need to be maintained twice. A practitioner on the EDI subreddit told of a customer who had to argue with their SAP consultant, from a very large consulting firm, about the need to hold the retailer's location numbers rather than the internal partner code. On JD Edwards the address-book cross-reference is one of the three things the inbound program fails on.
Part numbers
JD Edwards fails on the item cross-reference. SYSPRO walks a chain of customer stock code, then stock code, then supplier catalogue number, and treats what it cannot find as non-stocked. A consumer-goods company on NetSuite set up cross-reference tables to map retailer part numbers to internal SKUs during translation. A supplier on Epicor tracks a retailer's discount codes in a user-defined field. A manufacturer on an Infor suite proposed an operating model in which the EDI team owns mapping and message management but customer service owns part cross-references, price-list problems and minimum order quantities, because those are business facts, not integration facts. And from the retailer side, a practitioner recalled a retailer that sent the wrong product code on its own purchase order and charged back every supplier who echoed it.
Pack levels
Pack hierarchy is master data too, and it is the one most often missing. On JD Edwards the ASN's hierarchy is derived from the packaging set-up rather than configured: no packaging gives shipment, order and item; cartons add a pack level; pallets and cartons add a tare level. On Acumatica a unit shipped in two boxes needed a non-stock kit with the boxes as stocked components before the adaptor could build a compliant ASN. On NetSuite a user asked for case-pack quantities to be used by automatic packing so the ASN labels could be built at case level, and got no answer. An EDI programme manager's version is the one I quote most: if the customer requires pallet-level detail and your warehouse does not capture pallets, that is not really a mapping problem. The ASN is just where you discover it.
Who owns it
The reason these four faults recur is not that they are hard. It is that they are owned by nobody. In a long thread on how to structure an EDI function, an IT veteran at a large manufacturer said they were in charge of EDI but it was not their full-time job, and they also owned SKU data because sales would not allocate the resource. An IT manager at a smaller manufacturer summarised the gap: sales does not handle SKUs, shipping does not handle labelling. The advice that drew the most agreement was to get a master-data manager to handle everything SKU-related, because a good one makes EDI flow correctly and keeps shipping and warehouse compliance honest. The Infor proposal above is the same idea written as a job description.
What I do about it
Give each of the four a named owner before touching a map: units and pack configurations to whoever owns the item master, location numbers to whoever owns customers, part cross-references to customer service or sales operations, and the date and timing rules to whoever runs the overnight jobs.
Keep the retailer's identifiers in the ERP, not only in the network. The location numbers, the part numbers, the unit codes. If they live only in the network's maps, leaving the network means rebuilding them, and a failure in the network's map cannot be diagnosed from your side.
Validate on entry, not on failure. A new item without an outer GTIN, a new ship-to without a location number, a new customer unit without a conversion factor should be stopped at creation, because the EDI will faithfully carry whatever is there.
Test with the ugliest real order. The one with three units of measure, a store the retailer added last month and a product that comes in an inner and an outer. That order finds all four faults in an afternoon.