EDI 101

Yes, we’ve all heard it before – “We automate our retail connections through EDI.” But do you really? Below, I will explain why your direct 1:1 EDI connection is not enough.

Each Retailer Uses Different Types, Versions & Mapping

Every retailer has its own unique specifications and mapping. Even if you already have all the required EDI connections in place for one retailer, this does not confirm that you will be able to sell on multiple retailers, as each has its own requirements, versions, mapping and frequencies. With each new retailer added, a lot of work is required to get everything up and running smoothly. So, even if you had an EDI 846, which is used for inventory (explained below) in place for one, it doesn’t necessarily mean that the exact same file will work for another. 

And even if they do support the same EDI type and version, the mapping and variables that are used internally can be different. Also, the frequency of receiving these files can vary; for example, one retailer would want you to push inventory every hour, whereas the 2nd would want it daily. Often, to send/receive EDIs, you’ll be obligated to do it through a VAN, which charges a lot of money for every file you send and receive. 

Why should you automate your existing EDI integrations? 

Let’s jump right into the nitty-gritty technicalities of how automation improves each EDI transaction – because that’s what we really want to know, right? 

EDI 846

An EDI 846 Inventory Inquiry/Advice transaction set is used to communicate inventory information between manufacturers, suppliers, and resellers. So basically, when it comes to marketplaces or drop ship, if the product data is already set, customers can begin shopping once an 846 is placed.

Automating an 846 allows these transactions to occur quickly, efficiently, and systematically – with no manual work on your side. When dealing with multiple retailers and their own 846 requirements regarding mapping, frequency, and sometimes even the data itself, it can be overwhelming, time-consuming, and frustrating. Using an automation platform, like Cymbio, can help you streamline the process and not to worry about complying with each retailer’s needed adjustments.

EDI 850

An EDI 850 is an order received  – it generally provides the same information you find in a paper Purchase Order (PO) document. Automating your 850’s will alleviate dealing with: items, prices, quantities, shipping details, and payments.

When dealing with drop ship, the 850 will include all necessary information required to produce a branded packing slip like gift messages, all related prices & taxes, return instructions and more. Although 850 has, like all other EDIs, a generic structure, due to the fact that every retailer and marketplace has their own unique processes, and as IT teams tend to sometimes “band” EDIs to meet their needs, eventually, each 850 you receive needs to be mapped differently (even when it’s the same type and version). 

This means that every time you want to start receiving orders from your retail partner, your IT team (if you have one) will need to do a lot of heavy lifting of mapping and adjusting your systems flow. Instead, by automating the process with an automation platform, like Cymbio, you can rest assured no matter what type, structure, or mapping the retailer is using, you will always get the data in 1 standardized way.

EDI 856

After an 850 has been sent to you, you’ll be expected to send back an 856, which includes a shipping notice with the information about the shipping. Here you’ll find that there are few structures being used: SOIP, SOPI, No Pack, for example. These refer to the data hierarchy, SOIP (which stands forShip, Order, Item, and Package). You’ll also need to include which carrier you used and sometimes even in which method.

Unfortunately, each trading partner can call the same shipping method or service level differently – which means that UPS Ground has more than 20 types of naming conventions and/or SCAC codes. Automating this process will allow you to send your data in one unified format no matter what trading partner you send it to, and enable the automation platform (Cymbio) to convert and adjust it for you.

EDI 855 & 865

The issue with EDIs isn’t just about types, formats, mapping and different frequencies. What can make this issue more complex is that there are different flows and processes. For example, some retailers would expect you to send an 855, which is an acknowledgment that you can ship the goods, and in some cases, this file can also be used for cancellations or shorting orders.

That is also the case with the 865, an EDI that few retailers require you to send back after they made a change to the original Purchase order (850). These changes are done by retailers, usually via an 860 (see below).

EDI 810, 820 & 180

This group of EDIs is related to the financial part of the process. An 810 is an invoice usually sent by the supplier to the retailer, the retailer sends an 820 once a payment has been made, and the 180 is a return/refund used by the supplier to notify that  goods were returned and can be refunded.

Not all of your trading partners will use all of these EDIs, but when they do, each will have a set of rules and requirements you’ll need to find a way to comply with. Once again, your team will need to flag internally if an 810, for example, is used or not, when they should be created, and in what format. Automating the process will ensure you’ll get paid on time and accurately.  

EDI 870 & 860

Unfortunately, a small part of the orders will be canceled. Either by the end-customer who changed their mind, the retailer who decided that there is a fraud potential, or by your logistics team due to being out of stock. One might think that there are few cancelations and that this can be done manually, but automating this part is crucial. First, as although it seems like merely a quick task, these tend to take longer. Also, doing these operations manually can cause human errors, which will eventually cost a lot of money and hurt customers’ satisfaction.

An 870 is used by suppliers who wish to cancel an order, while retailers use 860s. Think about the headache and money loss that can occur if you shipped goods for an order that was already canceled, and now your team will try to intercept it and send it back to the warehouse.

EDI vs. API

Even though comparing these two is very difficult as they are two completely contrasting processes, it’s important that we point out the differences. While EDI is a file type/data structure transferred between trading partners via FTP/SFTP/AS2 or other methods, API is an interface that defines interactions between applications. Usually, APIs send and receive data in an XML/JSON format. So even though these two aren’t comparable, in the industry today, we tend to distinguish between these types of integrations.

Why is this important? As traditional retailers are using EDI, digital-native brands usually lack these capabilities as they use newer technologies that utilize APIs. And while legacy brands are using EDIs, new emerging marketplaces have only APIs – resulting in a “failure to communicate” situation, leading to a loss in sales. Working with an agnostic automation platform for data structures, file types, transportation methods, push vs. pull, frequencies, formats, versions and more, will allow you to focus on what you do best and not to worry about integrations. 

Existing EDIs

Even when you have existing EDIs and you are confident that no additional changes need to be made – there are still large amounts of manual work required. In most cases your operations, product and sales teams need to manually update all line sheets, product data and image adjustments.