Automotive EDI. What’s the Big Deal?
Electronic Data Interchange (EDI) isn’t just "nice to have" in the automotive supply chain world, you need this to be compliant or you could face the prospect of losing business. Almost every ERP package you can buy out there will have some mechanism to support EDI, but automotive EDI is a lot different than other industries.
You will need to make sure during your ERP selection process that the package you are looking at is able to support:
- Protocols your customers need (FTP, FTPS, OFTPS, ANX, AS2, HTTPS etc.)
- Standards that your customer demands (ANSI X12, EDIFACT, VDA, Odette)
- And, even more importantly that they can seamlessly handle the automotive EDI documents you are both receiving and sending on a day to day basis.
The most common order/demand EDI documents in the Automotive world are typically Planning Schedules
(830 or DELFOR) and Shipping Schedules
(862 or DELJIT). While there is still sometimes a requirement for a Purchase Order (850, ORDERS), it is the 830 and 862 that are typically driving the most of your automotive supply chain planning. In fact I would go so far as to say if the ERP package you are looking at starts talking about EDI and focuses solely on 850 documents then that should raise some red flags-- not only because they don’t know your industry, but I would question whether they were capable of handling a planning or shipping schedule from your OEM.
One of the main differences in the automotive EDI world is that planning schedule (830 or DELFOR) could be received weekly showing a forecast. And then a shipping schedule (862 or DELJIT) is received daily that overlays the forecast and shows the date and time that the truck will be arriving to pick up the goods. Depending on who you are shipping to, your customer may just send a planning schedule (for example Nissan does this) that they intend for you to use both for planning and shipping.
There are a bunch of 'gotchas' in that process: "I might need the 862 to overlay the 830, I need the time of the truck to be shown so I know what to stage and when, and I need to ship against the 862 but still use both the 830 and 862 for planning."
If that’s not complicated enough, the big three in North America like to send you the information in these documents with cumulative quantities (CUM’s). CUM means that they won’t tell you that you need to ship 200 parts today on the 7am truck, instead they will tell you that your cumulative quantity that you’ve shipped them over the current model year should be at 12,500. The system needs to calculate the math to figure out that consequently, since we’ve already shipping 12,300 parts, we need to ship 200 today at 7am.
Your new ERP system will also have to have a mechanism for managing those CUM’s in the event of a discrepancy between what you say you’ve shipped and what the customer has actually received. In addition to CUM, you will find that many OEM’s will ship using RAN (release authorization number) and Kanban which throws further wrinkles into the whole process of Automotive EDI. Whatever system you select will need to pull this information in seamlessly with little or no manipulation of the data and make sure your ERP choice supports both CUM and RAN!
If that all isn’t hard enough, you may also need to consider sending EDI to your suppliers in order to be compliant with your Trading Partner. Next time I’ll talk more about outbound EDI in the automotive world and focus a lot on the Advanced Ship Notice (ASN). Until then stay safe!
Posted by Andrew Robling, Principal Product Manager