Acknowledgements
A receipt is not a confirmation. It says the document got there, or that it did not, and it is the only way to know the difference between delivered and read.
Sending a document tells you it left. An acknowledgement tells you it arrived. Without one, a document that vanishes looks exactly like a document that was delivered and acted on, and you find out at the end of the month.
Two layers, answering two questions
| Layer | The question it answers | EDIFACT | X12 | UBL |
|---|---|---|---|---|
| Envelope | Did the interchange arrive, and could it be read at all? | CONTRL | 997 | MessageLevelResponse |
| Document | Was the business document accepted? | APERAK | 824 | ApplicationResponse |
Each layer is agreed on its own, so a partner on X12 owes you an 824 only where the agreement says so, and a message with nothing on one of its two lines is not necessarily missing anything.
Two limits are worth knowing before you agree a layer with somebody. The envelope layer on UBL is the Peppol Message Level Response, and it answers the five Peppol business documents only: an order, an order response, a despatch advice, an invoice and a credit note. A Danish OIOUBL document has no envelope layer at all and is answered at the document layer alone. And nothing acknowledges an acknowledgement, in any format, or two systems would answer each other for ever.
The first is technical: the file arrived, the syntax was legal, the envelope was addressed to someone who exists. The second is a business answer: the invoice was accepted, or it was rejected because the reference is missing.
A document can pass the first and fail the second, and that is the case worth catching. The interchange was fine; the invoice was refused. Nothing is wrong with your EDI and you are not getting paid.
What the states mean
| State | What it says |
|---|---|
| Not expected | You did not agree to one for this document. Its absence means nothing |
| Pending | You expect one and it has not arrived. Normal, up to the deadline |
| Positive | It arrived and it was good |
| Negative | It arrived and the document was refused. The reason is on the message |
Each message carries both states independently. A message can be positive on the envelope and pending on the document, which is the ordinary state of affairs for the minutes between a partner receiving your invoice and their system accepting it.
Overdue
Pending stops being normal at the deadline the agreement sets. After that the message shows as overdue and turns up in the operations workspace as something to chase.
It does not mean the document failed. It means you expected an answer by now and have not had one, and the two things to check are whether the partner actually sends that receipt and whether your deadline matches their reality. A partner who batches overnight will look permanently overdue on a fifteen minute deadline, and a list that is always red gets ignored.
Reading a negative one
A rejection carries codes and text from the partner's system, and the module keeps them as they were sent, with the document they refer to. That matters because the codes are the partner's, not ours: the module does not translate them into something friendlier and lose the original in the process.
The detail rows say which document was refused, what the sending system called the problem, and when. That is what you quote when you ring them.
Answering, when you are the receiver
The inbound agreement decides whether you send receipts, per layer. Sending them is generally good manners and often a requirement: a partner who asked for a receipt is a partner whose system is waiting for one, and their message will go overdue on their side if you never answer.
One receipt goes out without anybody agreeing to it in advance. Where an arriving interchange cannot be read at all, the envelope acknowledgement that answers it is a refusal, carrying the syntax code that says what was wrong with it. That is the one case where the answer is negative by itself rather than because a document inside was refused, and it is worth knowing about before a partner rings to ask why they got one.
Correlation
A receipt has to be matched to the document it answers, and the reference the partner echoes is not always the one you would expect. The module records how confident the match was and why, so a receipt that landed on the wrong message can be seen to have done so rather than quietly being believed.
In practice you will not think about this until a partner changes their system. When they do, the confidence field is the first thing to look at.
AS3 receipts are a third kind
On AS3 the receipt is part of the transport rather than a document your partner’s application sends, and it does not come back on the same connection. The envelope is uploaded to their server and nothing is confirmed at that moment. The message stays at stored until the signed receipt is written back into our directory and verified, which can be the next day.
So a stored AS3 message is not a stuck one. Read the date against what the partner agreed.
A receipt that never arrives is noticed by us and not by Dynamics. The message log will go on saying stored, and nothing on it turns red. Where AS3 receipts matter to you, agree a deadline with the partner and ask us, rather than waiting for the row to change.