Correction processes for flawed EDI data Part II

In the first part of our series on correction processes, we have introduced to you several courses of action that you can use to inform partners about mistakes and have them remediated. In this article, we now discuss two EDIFACT message types that you can use to give structured feedback: The CONTRL and APERAK messages.

Both the CONTRL and the APERAK pursue the goal of sending the processing status of EDI data back to the data sender in a format that applications can handle. Thus, both message types are - like EDI data in general - not designed in a way that a large group of people knows how to read them. Also, as mentioned in the first part of our series, they are rather suited for processes with a lower error criticality as you cannot expect immediate improvements by the data sender.

With the CONTRL, you can cover two functions: On the one hand, the message serves as the acknowledgment of the receipt of a preceding EDI transmission. This is particularly useful if the data exchange protocol does not include an own acknowledgment of receipt or if it has not been activated. On the other hand, it informs the data sender whether his transmission was generally accepted or rejected.

This feedback may be designed with more or less details: Only the segment with information on the status of the complete transmission is mandatory. However, additional status information on a group of EDIFACT messages (summarized in one or more UNG/UNE groups), single messages, segments or data elements may also be reported back. If flaws are reported, they can be described by means of a list or error codes.

As this list of error codes is not very comprehensive and the CONTRL does not allow a more detailed description of errors, it is less suited than the APERAK to give exhaustive feedback on semantic errors. However, you can at least highlight with the CONTRL at which parts within a message there are flaws. This will reduce the need for consultation between data sender and data receiver and help the data sender to recognize fundamental syntactical errors.

On could understand the APERAK as the big sister of the CONTRL. She is more detailed and may contain more contact details and references regarding a certain message amongst others. For her description, we were geared to the VDA 4937. This message is an application recommendation of the German Association of the Automotive Industry for the APERAK. EDI partners can use it to exchange standardized feedback data. Like the CONTRL, you can also use the APERAK as an acknowledgment of receipt, thus there is a certain functional overlap between both EDI message types.

However, while the CONTRL knows only the status 'rejected' or 'accepted', you can additionally depict warning with the APERAK. This might for example be reasonable where an EDI message could be processed, but only with a slight correction process at a subordinated detail. Moreover, adopters can create detailed code lists, like the German Association of the Automotive Industry has done with the VDA 4937, for example. With the help of free texts, you can also address feedback to a broader group of people. In principle, it is even possible to hand over the result of checks from the final receiving system to the EDI system, to convert them into an APERAK and to transmit them to the data sender.

In the end, CONTRL and APERAK are only useful if their result is considered by the data sender. Although it would be desirable if all of your partners would route the feedback data to the system where the faulty message has been created, you should not reckon with the willingness or aptitude of all data senders to do so. However, unwilling or unable partners could map the content of the CONTRL or the APERAK into a format from which they can create a PDF file. In this process, they could also paraphrase error codes by means of a replacement table into more intelligible content. In a second step, the PDF file is sent via email to a person on the side of the data sender that is responsible for data quality.

Especially if you intend to introduce the APERAK exclusively, you should consider whether you send feedback only for defective EDI messages or for all. Although the message volume will be less if you opt for the first option. we recommend to send an APERAK in both cases. Otherwise, the data sender will not be certain whether his message was processed at all, frequent inquiries at your EDI team will be the consequence.

Please find here part I of our series.