Reliable, consistent master data is essential for supply chain success. Unfortunately, however, many businesses have inadequate procedures in place to safeguard their master data, and run the risk of experiencing costly errors as a result.
Thankfully, it is possible to eliminate data issues across individual partner connections by conducting a master data synchronisation (or master data sync). In this article we look at what a master data sync is, why it’s needed, where people often go wrong, and the correct way to handle one.
What is a master data synchronisation?
A master data sync is a process in which you and your business partner examine your master data to ensure that you are both using the same master data elements and the same information for each element.
Data must be consistent within each individual message exchange and across multiple exchanges to ensure streamline B2B integration. Usually, EDI heavily builds on unique identification numbers for all involved parties, goods and services and does not rely on natural language descriptions. E.g. one does not refer to a supplier as “Supplier A Ltd” or a customer as “Customer B Inc.”. Instead unique IDs are used, which must be known to all involved parties. For example, if you refer to a supplier as “A” and a customer as “B”, your partner must adopt the same identification approach to avoid your ERP system (and theirs) pulling through the wrong information from EDI messages.
Typically it is the larger partner – i.e. the “onboard-er” rather than the “onboard-ee” – that dictates what should be used.
Why is syncing master data important?
EDI messages save businesses a significant amount of time and money by optimising B2B processes through automation. If master data is not aligned, however, data errors will occur – and worse still, these errors may not be immediately obvious.
If spotted, errors can be fixed through time-consuming manual intervention. If not spotted, simple errors such as an incorrect delivery address for a large order can ultimately disrupt your entire supply chain and cost your business dearly.
Syncing master data thus provides peace of mind and helps ensure your supply chain runs smoothly.
When should I do a master data sync?
Master data should always be synced before a partner onboarding and whenever there is a change/update of master data on the side of one partner that is relevant to the other partner. This way there is a much reduced risk of errors happening once your connection is up and running. The mapping process is also much faster and simpler when master data has been synced in advance.
What are the most commonly used master data elements?
While master data can extend to include whatever data you want, the most common types of master data in the context of EDI are as follows…
Mailbox IDs (AKA technical sender / receiver information)
This is the ID of the mailbox that the invoice (or other message) is sent to. It is not the same as the invoice recipient or the delivery point. Essentially the Mailbox ID is like the information you put on an envelope; it may not bear any resemblance to the information contained in the letter inside. Though often overlooked, Mailbox ID is an important master data element and should be stored in the ERP system along with the above elements.
Usually unique IDs such as Global Location Numbers (GLN) or DUN & Bradstreet Numbers (DUNS) are being used. However, bilaterally agreed IDs are also possible.
The following example shows two mailbox IDs in action in an EDIFACT purchase order message.
UNA:+.? ‘
UNB+UNOC:3+7810029032309:14+7347339003422:14+211025:1750+138841++ORDERS+++4711′
UNH+1+ORDERS:D:01B:UN:EAN010′
In the example above 7810029032309 uniquely identifies the sender’s mailbox and 7347339003422 the receiver’s mailbox. Both IDs are Global Location Numbers (GLN).
Involved business partners and their IDs
As with Mailbox IDs, unique IDs such as GLN or DUNS numbers are being used to identify business partners. In some scenarios custom IDs, such as the customer’s business partner IDs can be used as well (though this is discouraged by EANCOM).
The following example shows two business partners in an EDIFACT message.
NAD+BY+7870037600032::9′
NAD+SU+7365339000045::9′
The first line identifies the buyer using a GLN and the second line identifiers the supplier using a GLN.
Usually, EDI files contain some of the following roles (non exhaustive list):
- Supplier – The party supplying the item(s) being purchased.
- Customer / Buyer – The party purchasing said item(s).
- Delivery point / Ship to – The delivery address (this should not be confused with any other address connected with the customer).
- Ultimate consignee – The party that will ultimately receive the final item(s).
- Invoice recipient – The party that receives the invoice. Significantly this is not necessarily the customer. For example, if a shop was to buy something, the invoice recipient may well be their headquarters rather than that particular shop.
For more information on the various parties used in EDIFACT, see our blog post on how to use EDIFACT parties correctly.
Usually, an EDI message exchange consists of multiple different messages, e.g. in case of EDIFACT:
- ORDERS (Purchase Order)
- ORDRSP (Purchase Order Response)
- DESADV (Despatch Advice)
- INVOIC (Invoice)
In such a case it is important that the used IDs remain consistent among the exchanged document types. If the buyer is identified in the original ORDERS message as for instance:
NAD+BY+7870037600032::9′
…the exact same GLN 7870037600032 must be provided as the NAD+BY in all other consecutive messages as well (ORDRSP, DESADV, INVOIC).
Exchanged material and service identifiers
The materials or services associated with an EDI message are identified using a unique number as well. Instead of using the supplier’s article numbers or the customer’s article numbers, usually a globally accepted and unique system is adopted. Similar to Global Location Numbers (GLN) for identifying the involved parties and mailbox IDs in EDI, Global Trade Identification Numbers (GTIN) can be used to uniquely identify exchanged goods and services. Oftentimes a combination of both is used – e.g., GTINs are used alongside with the supplier’s article numbers. Thus, the receiving system can be built on any of the two numbers.
The following examples shows an exemplary line item from an EDIFACT message.
LIN+1++4347256156543:SRV’
PIA+1+3345005260:BP’
PIA+1+34559560323:SA’
IMD+F++:::STRAWBERRIES 5X1KG RB’
The first line is the GTIN of the exchanged product. In addition the second line provides the buyer’s article number and the third line the supplier’s article number. Line four contains the free text description of the product for informational purposes only.
These are only a handful of the many possible master data parties. Different industries have different essential master data parties, and some businesses prefer to exchange more granular data than others. For example, the full codelist for parties in EDIFACT can be found here. Please note that different EDI standards use different codes/names for master data parties.
Where people go wrong
Just as IT systems and EDI solutions typically grow and evolve over time, so master data, too, is often historically grown. Over the years it is common for certain master data fields to be conflated, with conflation of a company address and delivery location being possibly the most common example.
Another very common issue concerns the use of the “technical sender / receiver” (AKA “Mailbox ID”) element, which may be, but crucially does not have to be identical to the IDs used in the EDI message.
But master data errors can happen across any of the hundreds of different master data parties. What’s more, these errors will multiply over time unless necessary measures are taken. As a result, by far the biggest master data mistake companies make is not conducting a thorough master data sync before a new onboarding.
Who should handle a master data synchronisation?
While it may seem like your EDI provider would be the most logical candidate to handle master data synchronization, in reality the best person to handle such a project is the person best acquainted with the data and how it is used by your business. Although your EDI service provider may be very knowledgeable about your partner connections, they would only act as a middleman in a master data sync project as they are not able to make key business decisions when it comes to how you want data to be used/stored. The fastest and most efficient way to complete such a project is through direct communication between the employees with the most relevant experience in both you and your partner’s organisations.
However, your EDI provider may certainly help you with decisions on how and where to store EDI IDs in your ERP system. In particular if deep EDI/ERP integration solutions are used, such as ecosio’s integrations for ERP systems like SAP, Microsoft, Infor and the like.
Want more information?
If you would like help or advice on master data, partner onboarding, or any other EDI topics, please get in touch. We are always happy to help!
You can also find a wide selection of articles, webinars, white papers and infographics in our resources section.
