Electronic Data Interchange (EDI) based business data exchanges are becoming increasingly popular among all types of businesses ranging from global multinational corporations to small and medium enterprises. The main reasons for this wide adaptation are the structured nature of these EDI documents, which enhances the efficiency, accuracy and the speed of business transactions, minimizing the manual effort required in processing and validating such data.
This structured approach requires both parties to follow an agreed-upon set of guidelines when creating and processing EDI documents. These guidelines are typically based on a selected EDI standard and version, which is then customized to address the specific data needs of the business use case. Once established, both parties must ensure that the EDI documents they exchange comply with these guidelines or specifications.
Non-compliance with these EDI specifications can lead to processing errors and rejections at the receiving end, resulting in disruptions to critical business operations, missed deliveries, inventory shortages, payment delays, and, in some cases, financial penalties. Therefore, it is crucial to ensure that the EDIs created on behalf of your business meet all specifications before sending them to your business partner.
With modern EDI processing software like Aayu Technologies’ EDI Generator, the software automatically validates the EDI documents you create and alerts you to any validation issues. This enables you to correct errors and revalidate the EDI before sending, ensuring everything is accurate and compliant. In this article, we’ll cover some of the common validation errors you may encounter in EDI Generator and offer effective solutions for resolving them.
This guide assumes you already have a basic understanding of concepts such as the general structure of an EDI, as well as EDI segments and elements. If not, we recommend starting with this introductory guide to familiarize yourself with these concepts first.
As mentioned earlier, both business parties must agree on a common EDI specification before establishing EDI connectivity. When working with large corporations like Walmart, Amazon, or Best Buy, these companies typically have established EDI specifications and expect their partners to comply. These specifications are usually provided as structured documents, often in PDF format or other common formats like MS Word. This document serves as a reference when creating EDIs for that partner, so it’s essential to review and understand their requirements and conditions. Additionally, having this specification on hand is helpful when troubleshooting EDI validation issues, like those we’ll be discussing next.
There are three types of common validation errors that may occur due to the inclusion or omission of a specific segment.
In any such scenario, you will encounter a validation error similar to the below in EDI Generator.
SyntaxError: Failed to match Rule {mandatory 0:ABC - O/1} at segment #14; found XYZ*12*
In this example, ABC and XYZ are placeholder segment names, and in a real use case, these would be replaced with the actual segment names relevant to your specific EDI validation error. For clarity in the following explanations, the segment name listed first within curly braces will be referred to as the “expected” segment (ABC in this case), while the segment listed second will be referred to as the “actual” segment (XYZ in this example).
Once the “expected” and “actual” segment names have been identified, the next step is to consult the corresponding EDI specification to locate these two segments and determine their relative positions within the EDI structure. Based on their presence and relative positioning in the specification, three possible scenarios can arise.
Let’s consider a scenario where a validation error of the mentioned type occurs in an 810 (invoice) EDI. In this case, the expected segment is “TDS”, and the actual segment is “CAD”. The positioning of these segments in a sample specification is outlined as follows.
In this example, the “expected” segment appears before the “actual” segment. This indicates that the “expected” segment is missing in the generated EDI. To resolve the issue, the fields associated with the “expected” segment (in this case, TDS) need to be properly populated.
This scenario occurs only when the “expected” segment is designated as either “Mandatory” or “Must Use” in the EDI specification.
Let’s consider another scenario where a validation error of the described type occurs in an 810 (invoice) EDI. In this case, the expected segment is “FOB,” and the actual segment is “DTM.” The positioning of these segments in a sample specification is as follows.
In this example, the “actual” segment appears before the “expected” segment. This indicates that the number of occurrences of the “actual” segment in the generated EDI exceeds its allowed maximum usage. For instance, in this case, there could be more than 10 DTM segments present in the generated EDI. To address this issue, any extra occurrences of the “actual” segment need to be removed from the EDI.
This scenario arises only when the “actual” segment has a defined finite “max use” limit.
Let’s consider a 3rd scenario where a validation error occurs in an 810 (invoice) EDI, with the expected segment being “TDS” and the actual segment being “PO1.” In this case, “PO1” is not listed as a valid segment in the corresponding EDI specification.
Here, the issue is that the “actual” segment in the generated EDI is unexpected or not permitted. To resolve this, steps must be taken to remove the invalid segment (“PO1”) from the EDI.
Following are some common errors that can happen due to data condition violations between elements of the same segment.
In certain EDI segments, at least one element within a group of elements is required to have a value. For example, the REF segment, used to specify references related to the current EDI, requires at least the 2nd or 3rd element to contain a value. If neither of these elements has a value, a validation error similar to the following will appear.
R0203 failed: At least one of Reference Identification (REF02), Description (REF03) is required
Here the error code R0203 indicates that the “At least one required” (R) condition has been violated for elements at positions REF02 and REF03. To resolve this error, you will need to provide an appropriate value for the field corresponding to either REF02 or REF03 (or both).
In certain EDI segments, if a particular element contains a value, a corresponding element is also expected to have a value, and vice versa. For example, the TXI segment, used to specify tax information related to an invoice, has this condition for its 4th and 5th elements. If only one of these elements has a value, a validation error similar to the following will appear.
P0405 failed: If any of Tax Jurisdiction Code Qualifier (TXI04), Tax Jurisdiction Code (TXI05) is present, the other is required
Here the error code P0405 indicates that the “If any of present, other is required” (P) condition has been violated for elements at positions TXI04 and TXI05. To resolve this error, you will need to provide appropriate values to both TXI04 and TXI05 (or specify none of those 2).
In certain EDI segments, if a particular element contains a value, a corresponding element is also expected to have a value. Unlike the previously discussed rule, this only works in one direction. For example, the TXI segment, used to specify tax information related to an invoice, has this condition for its 8th and 3rd elements. If a value was provided for the 8th element, but not for the 3rd element, a validation error similar to the following will appear.
C0803 failed: If Dollar Basis For Percent (TXI08) is present, then Percentage as Decimal (TXI03) is required
Here the error code C0803 indicates that the “If X is present, Y is required” (C) condition has been violated for elements at positions TXI08 and TXI03. To resolve this error, you will need to provide an appropriate value to TXI03 as well (or remove the value of TXI08).
In addition to segment-level errors, validation errors can also occur due to incorrect values in specific elements. These errors vary based on the data type of the element. Below is an example of a validation error indicating an invalid value in a date-time type field:
Bad value 'abcd' on 'Time' (DTM03) of Date/Time Reference (DTM) segment : must be a time: HHmm, HHmmss, HHmmsd or HHmmssdd
In addition to generic data type errors, there can also be partner-specific data validation errors, particularly when composing an EDI for a well-known partner like Walmart. Below are two examples of Walmart-specific validation errors related to the REF02 element. These types of validation errors are typically straightforward and can be corrected relatively easily.
Reference ID for Internal Vendor Number (IA) must be the Walmart-assigned 9-digit vendor number
Reference ID for Department Number (DP) must be a zero-padded 5-digit number
In this article, we discussed some of the most common EDI validation failures you may encounter in an EDI Generator. These validations act as safeguards to prevent the exchange of invalid EDIs with your business partners, playing a crucial role in minimizing time, effort, and potential financial losses due to erroneous EDIs. Therefore, it is essential to thoroughly understand the meaning of these validation error messages in order to address them promptly and efficiently.
Udith is the Chief Technology Officer at Aayu Technologies. With over 9 years of experience in the enterprise software industry, he has been instrumental in architecting, developing, and maintaining a range of enterprise software solutions, particularly B2B communication software, with a significant focus on cloud technologies.