Implementing EDI transactions has many challenges. Every EDI trading partner had different specifications and each one has their own process for testing and implementation. The reason for this is that every EDI trading partner has their particular business rules, their uniquely configured internal systems, and their own implementation process.
Data sent and received through EDI documents for the same transaction type, but with different trading partners, will contain different data. The relationships between data within a document will vary as will the relationships between data on related document types.
For example, a purchase order from one partner may be similar, but will not be same as a purchase order from another partner. Other transaction types, such as invoices and advance ship notices, have large variances in their data requirements.
Some EDI partners have been doing EDI for a long time and have not changed the version of EDI they employ while others are more or less current.
Requirements may differ by type of supplier. Some partners will have different specifications for suppliers of product that is sold to end consumers in stores, for drop ship direct to consumers, for pay by scan consignment, for direct to store delivery, and for “not for resale.”
The types of EDI transactions required varies. Some retailers want purchase orders and invoices only. Many also require Advance Ship Notices and the associated bar code shipping label. Some require additional transaction types such as purchase order acknowledgements, purchase order changes, order status reports, planning schedules, product activity data, inventory updates, catalogs, payment remittance advices, and others.
One constant across all trading partners is that functional acknowledgments will be sent to indicate receipt of an EDI document and functional acknowledgments will be expected to indicate the supplier has received documents.
Retailers will almost always us the ANSI X-12 standard. Industrial customers, especially in the automotive supply chain may use a different standard, the EDIFACT standard.
Either way, as discussed above, every trading partner will employ different requirements within their chosen standard. The standards dictate file formats, data element names, groups of elements, etc, but still leave considerable room for each trading partner to implement what their business needs.
The implementation process varies by trading partner. All require testing unless a third party EDI provider is used by the supplier and the third party EDI provider has obtained an exception to testing.
The testing process with some trading partners is informal, but most have their process which must be followed. Some will send a test order. Some will send a live order and then require testing for all other transaction types.
Some have a testing web site to download and upload transactions. Some assign one testing analyst for all transaction types. Some have a different person with whom to work for each required transaction type.
Occasionally a trading partner will move each transaction type to production status as testing is completed. Most will want all required transaction types to be fully tested before moving the supplier to production status.
A few trading partners like phone calls, but most strongly prefer email communication during the testing process. Some will provide fast test results in a few hours, some will take days and a few will take weeks to provide feedback. Some like lots of communication during testing and others have their process they want to have followed precisely with minimal back and forth discussion.
If all of this sounds like a big headache, we can take care of it for you. Contact us anytime to find out more.Challenges for Implementing EDI Transactions with Trading Partners by Steve Brewer