We often get companies come to us when they want to implement EDI. And one of the points of confusion is often around where EDI fits in with their business processes and software. They ask what comes first – is EDI the cart or the horse, the chicken or the egg?As a general rule, we say EDI should support your business processes, not rule them. We suggest companies map out their process, whether it be existing or what they want them to be, then insert EDI at points that it can help. For example, if you want to scan inventory in when it arrives, you’ll probably choose to use an advanced shipping notice to get the data into your software ahead of time and have your suppliers attach scannable SSCC labels to their shipments. If your software conducts two-, three- or four-way matching, you’ll need to make sure you exchange the relevant messages that are used in those checks. The other thing is, you don’t want to make your project bigger than Ben Hur – it’s ok to phase in different stages. Start with where it’s simple to bring EDI into the process. Then if there are other pain points down the track that can be resolved with EDI, then add them into the mix. A key reason for why projects can go awry is biting off more than one can chew. Different industries, and even different businesses or different software all operate in their own ways. And there’s good reason for that. It’s important that you get your processes in a place that suit your business needs. EDI should ideally be used to bring in automation and to reduce your team’s workload. Here at MessageXchange, our software can help with the EDI portion, but our powerful business process management layer can help fill gaps between EDI and your processes and software. MessageXchange is flexible enough, and smart enough, to cater to processes regardless of their complexity. For example, two-way matching can be conducted within MessageXchange itself by taking the EDI order and invoice and reconciling them against each other, then sending the result on. It can do the same with three-way matching by including the shipping notice too. It can even enhance the data in your message. For example, if you find it’s difficult for you or your suppliers to include a supplier number or GLN, MessageXchange can insert that into messages for you. Looking for more information on this topic? Get in touch with us below.

Request a call

Chat with one of our experts

Just fill out your details below and we'll be in touch within one business day.

Onboarding suppliers to EDI can be costly and time consuming. A typical onboarding process will involve these steps:

1. Engaging suppliers Letting them know you’ll be onboarding them to EDI.
2. Getting them familiar with requirements (MIGs) All requirements are normally shared via a message implementation guide (MIG)
3. Schedule in testing Set up a time and deadline for testing of messages to start
4. Test Send and receive EDI messages from your suppliers to ensure they are sending the correct data.
5. Go live!

If you’re onboarding large amounts of suppliers it’s important to keep things efficient. Here are some things to keep in mind.

Testing is the most time-consuming process

Testing is time consuming because it requires a lot of back and forth checking and communication with your suppliers. This takes time and puts more pressure on you to keep things moving along. A more efficient solution is to use a message compliance testing tool (MCT), like Colladium. It allows suppliers to test their EDI files, often through an online portal, without your team needing to check them. This means you don't have to wait for your EDI team to match up availability with theirs. In fact, your resources don’t need to be involved at all. This also allows the supplier to fix up any issues with their mapping or EDI file generation so that when they go live, you're not scrambling to resolve issues.

Make templates for your communications

This makes it easy for anyone in your team to communicate with suppliers consistently and accurately. The templates should include who your suppliers should contact, the expectations and requirements to onboard and their scheduled time for testing. Just be aware it is pretty normal for these templates to evolve over time as you and your suppliers learn. These templates can also be tailored to the supplier’s knowledge and readiness for EDI.

Communicate internally

It’s key that everyone within your business is on the same page when it comes to onboarding. A step by step process should be finalised and communicated to your EDI team. This process should establish the roles for each part of the process and who to contact. Have more questions? Ask our experts by getting in touch below.

Request a call

Chat with one of our experts

Just fill out your details below and we'll be in touch within one business day.

In most industries, there’s an EDI standard – whether it be EDIFACT, GS1 XML, ANSI X12 or something else. While standards are fantastic because they make it easier for companies to trade with each other (because they don’t need to setup different messaging standards with each trading partner), ERP software generally doesn’t export the standards out of the box, if at all. Typically, software exports an XML or CSV document. So this is where mapping comes in.

What is mapping?

A mapping translates a file from one format to another. For example, if your software exports an XML file but your customer requires an EDIFACT message, the mapping process transforms the XML to EDIFACT. The way MessageXchange work allows the mapping process to also incorporate business rules. For example, it can be used to enrich data, perform calculations and more. This is particularly helpful for those companies whose software doesn’t export all the information that a customer requires. A mapping is setup once and then it just runs. There’s no intervention needed when a new message comes in, the whole process of mapping a file is automated.

When would I use it?

As I mentioned above, mapping is typically used when software isn’t able to export the file format required by a company’s trading partners. It’s the way to mediate between your software and that of your trading partners. It can even cater for your trading partners who have different requirements – logic can be setup to use certain mappings for certain customers. Mapping cover all message types too – so if you receive an order, the purchase order can be mapped from XML to EDIFACT, but the POR, ASN and INV can be mapped from EDIFACT to XML, for example.

What are the benefits of mapping?

It allows a company to easily comply with their trading partners’ requirements

There’s no changing your software or investing in additional staff or other resources to manage this.

It automates processes

It’s ‘set and forget’. It just runs.

It’s scalable

There’s no extra work to do if your message volumes increase. Once the mapping is setup, any new messages that are exchanged automatically go through this process. If you're needing help with your mapping get in touch with our EDI experts by filling in the form below.

Request a call

Chat with one of our experts

Just fill out your details below and we'll be in touch within one business day.

When you onboard suppliers it’s important for them to understand what the requirements are for the messages they need. A Message Implementation Guideline (MIG) refines a generic EDI standard such as UN/EDIFACT and details how it will be used for your company. In simple terms, it tells your suppliers what messages they need to send, what information the messages contain and how they’re formatted.Here are important things you need to know…

Choosing an EDI standard

There are different EDI message standards used around the world. Once you choose a standard it will be used as the base for your MIG. Here are a few of the common ones and where they’re most used:

UN/EDIFACT	Standard coined by the United Nations and the most commonly used worldwide, and heavily used in the Australian retail supply chain industry.
ANSI X.12	Commonly used in North America
EANCOM	Commonly used in the European retail industry
ODETTE	Commonly used in the European automotive industry
EbXML	Global standard developed by United Nations body for Trade Facilitation and Electronic Business Information Standards (UN/CEFACT) and Organization for the Advancement of Structured Information Standards (OASIS ).
TRADACOMS	Commonly used in the UK retail industry
HIPAAhow	Commonly used in the North American Healthcare industry
SWIFT	Commonly used by financial institutions worldwide.

 

Choose the message types you want to use with your suppliers

This comes down to what your objectives are as a business. Here are some of the common messages and what they do:

• Purchase order Sent from buyer to supplier to order goods or services

• Purchase order change Sent from buyer to supplier if the original purchase order has changed

• Purchase order acknowledgement Sent from the supplier to the buyer to acknowledge receipt of the order

• Purchase order response Sent from the supplier to the buyer to let them know how much of the order can be fulfilled, and any discrepancies from the original order

• Advance shipping notice (or despatch advice) Sent from the supplier to the buyer to let them know when and how the goods will be shipped

• Invoice Sent from the buyer to the supplier for payment of the goods or services

• Recipient created tax invoice (RCTI) Sent from the supplier to the buyer for payment of the goods or services

• Remittance advice Sent from the buyer to the supplier to confirm payment

• Price/sales catalogue Sent from the supplier to the buyer with up-to-date product and pricing information

• Product activity data Sent from buyer to the supplier with the number of units sold and units on hand

• Transport instruction Sent from a buyer to a transport supplier (and related parties) to communicate transport arrangements

• Transport response Sent from a transport provider to confirm instructions

• Functional acknowledgement An automated response sent from a receiver of an EDI message to confirm receipt of the message.

Find out what data your ERP system requires to process your message types

This is important because it’ll determine what fields and values you need from your partners. This includes things like:

• character limits
• whether only integers are allowed
• if it needs to be number
• how many decimal places
• whether the field is dependent on another field (conditional)
• whether a field is used for particular use cases only
• how calculations are made.

From here you can provide a list of values that can be used, If not, all values in your chosen EDI standard. We have a range of MIGs from various companies you can check out here.

Putting your MIGs together

This is where you take everything from the previous steps and document it. Writing MIGs can involve a bit of work and so you can get an external party to help. This where an EDI provider, like MessageXchange, comes in. We can assist or lead the MIG writing process, developing it from scratch or upgrading your MIG. Find out more here. Have more questions? Ask our experts by getting in touch below.

Request a call

Chat with one of our experts

Just fill out your details below and we'll be in touch within one business day.

The retail industry has been using EDI for decades. It’s been proven to give retailers more visibility, better accuracy and truckloads of savings. And there are even benefits for suppliers too, especially those who fulfill large volumes of orders. The use of EDI is mature in the retail industry and covers basically all use cases of the procurement process. Let’s have a look at the different EDI message types that are used in the retail industry and why.

Purchase order

This is sent from a buyer (retailer) to its supplier. It will tell the supplier exactly what they want supplied. It will tell the supplier where to ship the goods to, and it might even tell them when the retailer expects the goods by. A purchase order typically starts the procurement process. In the EDI world, you might see a purchase order referred to as ORDERS (EDIFACT) or 850 (ANSI X12).

Purchase order response

A purchase order response is sent from the supplier to the buyer (retailer) to let them know whether or not they can fulfill what’s been requested on the order. Typically, there are three scenarios – the supplier accepts the order in full (if they can fulfill everything as requested), the supplier rejects the order in full (if they won’t fulfill any of the order), or the supplier proposes changes to the order. Changes on the order response are typically changes to the quantity, the price or the delivery date. In the EDI world, a purchase order response can be called ORDRSP (EDIFACT) or 855 (ANSI X12).

Purchase order change

A purchase order change comes after a purchase order or purchase order response. It’s sent from the buyer (retailer) to the supplier. As the name suggests, it can be used to make changes to the original purchase order. Or if the supplier sends a purchase order response, some retailers send a purchase order change to confirm the supplier’s changes (response).

Advanced shipping notice

This can sometimes be referred to as a despatch advice. It’s sent from the supplier to the buyer to let them know what’s being shipped and when. There are a couple of ways that retailers use a despatch advice. The first is a relatively simple one – it basically tells them how many of each product is being shipped, to where and when. It just gives retailers a bit of visibility. The second one is much more detailed. The retailer requires the supplier to tell them exactly what’s being shipped, how, to where and when. These ASNs have SSCC, or serial shipping container code, details on them. SSCCs are unique numbers that identify a unit. This can be a pallet, carton or something else. The supplier tells the retailer how many of each product are going into each pallet, for example, and what the corresponding SSCC number is. The retailer may also require the supplier to tell them the batch number, best before and expiry dates of the products in that pallet. The supplier then prints labels, with the SSCC number represented as a barcode and sticks it onto the pallet they’re sending. This information is sent to the retailer on the ASN ahead of the goods being sent. When the retailer receives the goods, they can scan the barcode to know exactly what’s on the pallet. In the EDI world, this message is called DESADV (EDIFACT) or 856 (ANSI X12).

Invoice

An invoice is sent from a supplier to a buyer to let them know what to pay them for the goods or services they’ve supplied. Unlike invoices that you might send and receive by email, EDI invoices don’t typically have bank details on them, because these are usually agreed on as part of the supplier agreement. The EDI invoices generally just outlines the total to be paid, the breakdown of what’s to be paid and sometimes the payment terms, although these can also form part of the supplier agreement. In the EDI world, you might see the invoice referred to as INVOIC (EDIFACT) or 810 (ANSI X12).

Product catalog

A product catalog gives the retailer details of the products you’ll be supplying to them. It can be as simple as supplying them with the GTIN or item number, product description and unit price. In the EDI world, this is called a PRICAT (EDIFACT) or 832 (ANSI X12).

Functional acknowledgement

Unlike the other message types we’ve discussed here, functional acknowledgements aren’t your typical procurement messages. These are usually handled behind the scenes. They tell the sender of the message whether it’s been received and if it’s A-OK or why it might have been rejected. In the EDI world, these are called CONTRL (EDIFACT) or 997 (ANSI X12).If you have any questions or need help getting started, just get in touch!

Request a call

Chat with one of our experts

Just fill out your details below and we'll be in touch within one business day.