EDI Concepts: Positive vs Negative Confirmation

In EDI (the process, not as a file format), we are concerned with the delivery of data- often in some form of file. These files are usually automated, repeating processes which are delivered on some kind of schedule.

One of the perennial problems in EDI is how to keep track of what has been delivered. More importantly, most of the time, you have to keep track of what hasn’t been delivered. The problem with this, I’m sure you will agree, is that it is much harder to look at a list of items to see what isn’t there than it is to see what is there.

This causes a debate to arise- often between developer/EDI profession and end users- of what confirmation style one will use- positive confirmation or negative confirmation. Positive confirmation is when I, the receiver, tell you, the sender, that I have positively received a file with name XYZ. If I can include a record-count or byte size and a timestamp, so much the better. Negative confirmation is when I, the receiver, tell you, the sender, that I did not get file ABC which was expected in window DEF.

Both of these have their problems.

Negative confirmation is very, very difficult to achieve, from the receiver standpoint. A schedule must be established and rigorously maintained, and the entire process can be very brittle. Further, it puts the receiver on the hook for making sure the file is received, rather than making the sender responsible to ensure the file is delivered.

Positive confirmation, however, is often wasteful and ultimately useless. When a process runs almost every day exactly as expected, a positive confirmation process generates vast amounts of “confirmation” data that no one will review. However, for positive confirmation to be useful, those positive confirmation notices must be reviewed diligently every time they are received. No one, no matter how well intentioned, can do that for very long; eventually we just begin to see what we expect to see.

So, I suggest the following Confirmation process- Negative Sender/Positive Receiver.
In this process, the Sender maintains their schedule and is responsible for checking it. When a file is not delivered- for whatever reason- the Sender is alerted and can act. Once the file is listed as “delivered,” a confirmation should still be forthcoming from the Receiver to acknowledge actual receipt of the file.
This style of combined confirmation helps ensure that business critical files (such as invoices or other payment related files) are sent in a timely fashion.
Positive confirmation is very easy to establish, as a Receiver. Most modern FTP server packages allow for an email to be sent in response to a file received. Failing that, an application attached to a file watcher, or some kind of Messaging Framework or Service Bus can be used to detect a new file and send the appropriate notification.

Even from the sender standpoint, negative confirmation is still difficult. Telling a computer “Tell me what isn’t here” is nowhere near as easy as your users probably think it is. However, in a follow-up post, I’ll show some quick-and-dirty code which should point to a good solution for Sender side negative confirmation.