I think we've probably all been victimized by the business exec who demands that "EDI" adds a capability that is really a function of SAP (or whatever ERP you're using). I'm not talking about that; I'm referring to taking something you're already doing, or outputs from you're ERP that are already enabled, and using them to better advantage. Let me give you a couple examples.

Our largest eCommerce customer transacted with us over a secure internet connection, sending large volumes of orders and receiving corresponding PO acknowledgments and invoices. The thousands of users of their proprietary eProcurement system shopped an on-line catalog we populated to build orders, and were able to later verify the suppliers' (it was a multi-supplier catalog) availability and ship dates on the application after the POA was received and posted. Unfortunately, due to the time lag in processing the POAs on their end and populating their application database, users were often in the dark for some time on when their items would be shipped. We were asked to see if we could develop a solution to their problem.

This was actually pretty easy to resolve. We already received the SAP IDOC for the POA, which contained the required estimated ship dates. It also contained the email address of the user who placed the order. Through the use of a 'style sheet' and a special process, we created a beautifully formatted email that went directly to the end user from the same data we used to populate the 855 POA posted to their server. The users were happy that they received the info they needed, and our sellers were happy that a huge customer was satisfied. And you know what? We were happy, too, in having another capability we could provide to other customers. It turned out to be a fairly common, easy to implement little extra we could offer in the course of a project.

Another example is centered around using the large amount of data provided by your ERP to support a specific EDI transaction for a different transaction. Before we were able to support the outbound ASN, we would on occasion be approached by a large customer with the old 'do the ASN with us, or else' mandate, usually during a contract negotiation. After looking at the expense, resource, and time required to develop the output in our ERP system, we would reluctantly decline.

However, in a thorough review of the customer's data and timing requirements, we discovered that the application data being generated to support the customer's electronic invoice also included the data they required on the ASN. So, we ended up 'double-mapping' the outbound invoice data into both an 810 and 856, and were able to deliver the ASN to meet their required timeframe. Now, this wasn't a panacea that allowed us to add the 856 to our list of supported transactions at that point, since there were still some problematic situations (such as drop ships) that would be challenging, and some customers required data for their ASN not included in the invoice file. However, it did allow us to review individual requests on a case-by-case basis until we actually added the true ASN capability.

In both scenarios described above, we took great pains to avoid doing 'one offs'. We had a strong bias toward 'saying yes', and we wanted to use the capabilities of our translation environment, the richness of the data, and the creativity of our analysts to not only solve individual problems, but to do so in a way that could help us down the line with other partners. In the vast majority of cases I've seen, the limitations in what can be done with EDI is with the back-end ERP system, not with the EDI process itself. What we discovered was that a little 'out-of-the-box' thinking can not only address an immediate problem, but with a little planning can also give you ammunition to help you in the future.

Lastly, let's not overlook those transactions the 'big retailer' forced you to do by holding the proverbial gun to your head. Do they actually save you time? Are your transactions with the retailer now less prone to error? If those answers are 'yes', you may want to take a look at the other customers you have out there who are transacting via mail or phone. Would you want to move any of them into an electronic relationship? If the incremental cost of leveraging the transactions you're doing with the retailer for use with other partners is relatively small, it could be worthwhile to expand your program. The traditional selling points of EDI are that it's faster, more accurate, and cheaper than manual transactions, so if that's what you've actually experienced then you ought to see if you can get a little more use out of your investment.

Please contact me with any questions or comments at This email address is being protected from spambots. You need JavaScript enabled to view it.. Thanks for reading!