Accountability of EDI Transactions
EDI and other data that is part of an e-commerce transaction needs to get to where it needs to go in a reliable way. It needs to get there. Get there once. And be able to let the sender know if there was a problem with it, either not getting there, or being corrupted, in either case triggering a resend or some other remediation.
Early in my integration career I was working on a medical supply chain. Accuracy was important as you can imagine. And there was a good deal of stress that we shared as we brought our products on-line and let them encounter real data.
We tried to ensure that the data that we sent to suppliers was received, and when things when wrong we were on the phone quickly asking for confirmation that orders were received. As time when on we became better both at reliably getting data to the correct place, and in determining when problems where really problems.
“There was one Vendor that sold capital equipments. So they received few orders, but when they did, their orders were for a high dollar items. They also kept shutting down the system that we sent orders to. I think years went by where every order was accompanied by a phone call to their systems administrator asking that they re-boot their server.”
The EDI way
The easiest and most EDI like way to establish accountability of EDI transactions is the use of a 997 transaction. Basically a 997 works as an acknowledgment. The name of this document actually is Functional Acknowledgment. So we are acknowledging that a specific functional EDI component was received, and possibly how it was received.
If you are versed in the EDI enveloping levels you have already realized the link of between the 997 and the GS level of the EDI envelope. Also you may remember that you can request a 997 be returned for your transaction in the ISA segment in ISA_14. But merely setting up your ISA to request a 997 does not actually force your trading partner to comply. Your trading partner may not be able to, or may not wish to return a 997 for either business or technology reasons.
Assuming that you are able to get a 997 back. Just receiving the 997 does not mean that all is well with your transaction. The 997 is an EDI transaction. It can contain data indicating just the success of receiving the data, or a few validation levels indicating data corruption in transit or rejection for business process reasons.
The Transport Technology way
Another way is to place the accountability on the transport of the message. Using AS2 or other transport technologies that attempt to guarantee delivery of messages, it is possible to extend our reliable message solution to transactions of multiple types. AS2 and other transport solutions return an MDN or message disposition notification letting the transporting party know that its message has been received.
The BPM way
In spite of the facility of EDI to process and utilize 997s and of AS2 to utilize MDNs, the most exciting method of assuring message delivery and accountability is utilizing business intelligence. For me, I remember a system that we developed to help us with the health care supply chain. We simple began tracking the response time that was typical for each of our supplier trading partners. After gathering trending data, we applied alerts when responses were overdue by a specified degree of variance from the norm.
Since this process relied on the past 6 months of performance as the baseline, it was adaptive to changes in the vendor. We could also manually change the amount and degree if we started getting false alerts. In this way we had a way to react to failed transaction without requiring agreement and arrangements with the trading partner to confirm receipt or processing of transactions.
The Business Agreement
Even in cases where you have implemented a BPM process to alert to failed transactions, you have to have an agreement and arrangement with your trading partners that allow you to deal with failures in transmission and processing of your e-commerce transactions. At a minimum this needs to include contact information for support teams on each side of the transaction. It does no good to know there is a problem with a transaction but to be unable to solve the problem because the other party is unavailable.
In the end, it is what you have agreed with our trading partner that make the sender or receiver responsible for processing the transaction.
Subscribe to "The Integration Engineer" by Email
Find out about the tools and services available at The Integration Engineer's Consulting site.
