X12_EDIFACT Data Validation and Validation Tools

Owned by Subrat Sandilya
Last updated: Aug 12, 2024
9 min read

Learning Objectives

  • Understand the importance of EDI (Electronic Data Interchange) data validation for ensuring accurate and compliant business communication.

  • Learn the different types of validation processes, including schema level checking, syntax checking, code set validation, data type validation, length validation, segment sequence validation, and segment occurrence validation.

  • Explore the debugging steps and troubleshooting methods for resolving EDI validation issues.

  • Familiarize with EDI-related tools such as Edination, EDIValidator, and EDI Notepad for validating and debugging EDI files.

Introduction

Electronic Data Interchange (EDI) is a standardized method utilized by organizations to electronically exchange business documents. The main standards for EDI encompass X12 and EDIFACT, both mandating strict adherence to syntax and structural rules to guarantee precise and efficient data transfer. Validating EDI documents against these standards is essential to uphold the integrity of business transactions and prevent costly errors.

This document offers a comprehensive guide to EDI data validation processes, covering schema level checking, syntax verification, and various other validation techniques. Furthermore, it introduces tools and methodologies that can be utilized to validate and troubleshoot EDI documents, ensuring alignment with industry standards.

Requirements

  • Proficiency in EDI standards, particularly X12 and EDIFACT.

  • Utilization of EDI validation tools like EdiNation, EDIValidator, and EDI Notepad.

  • Comprehension of the format and language of EDI documents.

  • Fundamental understanding of the business operations that rely on EDI for correspondence.

EDI Data Validation

X12 and EDIFACT are widely used for electronic data interchange (EDI). Validating X12 or EDIFACT data ensures that the exchanged messages conform to the syntax and rules defined by the standards. 

Schema Level Checking

Schema Level checking is the process of validating EDI documents against predefined schemas or standards to ensure appropriate structure and data type.

In Adetia we can do the schema level validation using the below steps

  • First, you need to come to the Configure dashboard and then to EDI. 

  • There you will find the EDI layout option and you need to create a new layout with a meaningful name. 

  • Then upload the file in the EDI schema and based on the requirement we can pass the separator definition information. 

  • Then we can test whether the file has the correct syntax or not. We can also use an online EDI validator or EDI notepad to validate this.

  • Once we click the Test Button, we will get a screen to upload a source file

  • Once we upload and submit the file, we will get a screen showing the targetFile.xml, errorRecord.xml, and ack.txt files.

 

TargetFile.xml shows the data if the file is per the standards. Suppose it is as per Standards it will parse the complete data and won’t give any error in the errorRecord.xml.

 If there is an issue with the file it will just give ISA, GS, GE, and IEA data. The transaction set will go to the errorRecord.xml with all the error descriptions.

Data Validation

a.) Syntax Checking

This validation ensures basic syntax of the EDI document adheres to the  format specified in the standard

In this we validate

  1. Segment Delimiters and Control Structures: EDI standards specify delimiters e.g. segment terminator, and element separator used to separate different parts of the EDI document. So the syntax checking verifies that delimiters are correctly used and positioned as per standard.

  2. Segment and Element Order: Each EDI transaction set (e.g., Purchase Order, Invoice) has a predefined sequence of segments and elements. Syntax checking ensures that segments appear in the correct order and that elements within segments are properly sequenced.

E.g. 

Segment Separator, Field Separator, Composite Separator, Sub Composite Separator etc.

We will also check whether the Transaction Set count is correct or not.[ST to SE line count]

In the Release Indicator field, enter the identifier for the data element separator and segment terminator as regular characters in a data file (only applicable for the EDIFACT standard).

b.) Code Set Validation

Code set validation in EDI is the process of validating the codes used within EDI documents against predefined sets or code lists. This validation ensures that the codes representing data elements such as product identifiers, currency codes, country codes, and other controlled vocabularies are accurate and valid.

In this we validate

  1. Product Codes: Identifiers used to specify goods or services traded between partners (e.g., GTIN for Global Trade Item Number).

  2. Currency Codes: Standard codes representing currencies used in financial transactions (e.g., USD for US Dollar, EUR for Euro).

  3. Country Codes: Two-letter or three-letter codes representing countries or regions (e.g., ISO 3166 codes like the US for the United States, CA for Canada).

  4. Units of Measure: Codes specifying units of measurement (e.g., EA for Each, LB for Pound, KG for Kilogram).

  5. Custom Codes: Industry-specific or partner-specific codes that are defined and agreed upon between trading partners.

E.g. if a field is supposed to contain a specific code for a country, ensure the code used in the message is valid.

Here, PA should be a valid State or Province Code. It should not exceed two characters.

c.) Data Type Validation

Ensure that the data types of elements match the specifications in the X12 standard. For instance, a field should contain only numeric characters if it is defined as numeric.

In this we validate

  1. Control Structures: EDI documents include control segments or segments with defined roles (like segment headers) that ensure data type rules across the entire document set.

  2. Segment Level Validation: Each segment within an EDI document has defined rules for the type and format of data it contains. Validation occurs at both the segment level (ensuring each segment adheres to its format requirements) and the data element level (ensuring individual data elements within segments conform to their specified formats).

 

E.g. if a field is supposed to contain a string value, ensure the value used in the message is valid.

Here, instead of PA we can’t use a numeric value.

d.) Length Validation

Length validation in EDI is the process of verifying that the length of data elements within an EDI document conforms to predefined standards and specifications. EDI standards, such as ANSI X12, EDIFACT, and others, define specific maximum lengths for each data element to ensure consistency and compatibility between trading partners' systems

In this we validate

  1. Segment Length: Each segment within an EDI document has predefined lengths for its data elements. EDI checks that the length of each segment does not exceed the maximum specified length.

  2. Data Element Length: Within each segment, individual data elements (e.g., fields like customer ID, product code, etc.) have specific maximum lengths defined in the EDI standard. Length validation ensures that the data elements do not exceed these maximum lengths.

  3. Composite Data Elements: Some data elements in EDI  consist of sub-elements (components) with specific lengths. Length validation also applies to these composite data structures to ensure all components adhere to their defined lengths.

E.g The ‘customer name’ field (e.g., N1 segment) has a maximum length of 50 characters. If the fields exceed their specified maximum lengths during transmission, the EDI software would flag it as an error.

 e.) Segment Sequence Validation

Segment sequence validation in EDI is the process of verifying that segments within a transaction set (or document) are structured and ordered correctly according to the rules defined by the EDI standard being used such as ANSI X12, and EDIFACT.

In this we validate

  1. Transaction Set Enveloping: Each EDI transaction set begins with an envelope segment (like ISA/IEA in ANSI X12) and ends with a corresponding terminator segment. Segment sequence validation includes checking that these envelope segments are present and correctly positioned.

  2. Segment Order: Within the transaction set, specific segments must appear in a predefined order. For example, in an EDI purchase order (ANSI X12 850), the segment sequence typically includes segments such as BGN (Beginning Segment), CUR (Currency), N1 (Name), PO1 (Item Detail), CTT (Transaction Totals), and SE (Transaction Set Trailer).

  3. Looping Structures: Some segments in EDI documents can occur multiple times in a loop structure. Segment sequence validation ensures that segments within loops are repeated according to the defined rules and do not violate loop limits or constraints.

  f.) Segment Occurrence Validation

Segment occurrence validation in EDI is the process of verifying that each segment within an electronic document appears the correct number of times according to the rules defined by the EDI standard such as ANSI X12, and EDIFACT. It ensures that mandatory segments are present and that optional segments are used appropriately.

In this we validate

  1. Min/Max Occurrences: Each segment within an EDI transaction set has predefined minimum and maximum occurrence requirements. For example, a purchase order (EDI 850) may require at least one BGN (Beginning Segment) and exactly one SE (Transaction Set Trailer).

  2. Looping Structures: Some segments in EDI documents can occur multiple times within specified loops. e.g., the N1 (Name) segment in an invoice (EDI 810) may repeat to identify different parties involved in the transaction. Segment occurrence validation ensures that segments within loops comply with defined loop limits and constraints.

  3. Envelope Segments: Segment occurrence validation also includes checking the presence and correct usage of envelope segments (like ISA/IEA in ANSI X12) that encapsulate the entire transaction set.

E.g. The transaction set must begin with a BGN (Beginning Segment) and end with an SE (Transaction Set Trailer), each occurring exactly once.

Debugging Steps 

 

  1. If the issue is related to Inbound File processing, cross-verify if the relationship has all values defined as per the Input EDI file.

  2. Check that the Partner ID and Host ID defined in Trading Partner are similar to the file.

  3. Check the Kernel Application.log file for a detailed error description. (https://support.adeptia.com/entries/21796646-Application-logs-location)

  4. Try using the "Skip Compliance Check" option while defining the relationship. If it works after checking this option, then your file may have some issues.

  5. Check if your Inbound file is valid or not by validating it in third-party EDI software or Can also validate through EDI Schema.

  6. If an issue occurs while Outbound File Processing, then check if you have applied Filters on ISA, GS, ST, SE, GE, and IEA.

EDI Related tool 

EDI (Electronic Data Interchange) tools facilitate the exchange of business documents and data between companies in a standardized electronic format. Here are some notable EDI tools and a brief guide on how to use them: 

  1. EdiNation:

EdiNation is an online tool for validating EDI files. It supports various EDI standards and provides a simple interface for quick validations.

How to Use:

  1. Access the Tool:

    1. Visit the https://www.edination.com/edi-translator.html

  2. Upload and Validate:

  3. Upload your EDI file through the website's interface.

  4. Run the validation process to check for errors and compliance issues.

  5. Review the validation results and correct any identified issues.

  1. EDIValidator:

EDIValidator is a simple online Validation tool specifically for validating X12 messages.

How to Use:

  1. Access the Tool:

    1. Visit the https://www.edivalidation.com/app

  2. Upload and Validate:

    1. Sign up on the EDIValidator website.

    2. Upload your EDI file through the website's interface

    3. Run the validation process to check for errors and compliance issues.

    4. Review the validation results and correct any identified issues.

  1. EDI Notepad:

EDI Notepad supports multiple EDI standards and versions, ensuring that documents are validated against the correct specifications.

If you want to view the Parsing errors of your EDI file then you have to use some third-party tool such as EDI Notepad.

How to Use:

  1. Download the EDI Notepad from its official website.

  2. Choose your EDI file from your local machine through the application interface and ensure that the extension of the file should be .edi

  3. Run the validation process to check for errors and compliance issues.

  4. Review the validation results and correct any identified issues.

Choose an EDI file from the location:

See the validation result.

  1. Compliance Check:

In EDI transactions there is an option in the transaction configuration, this will enable you to do the inbound validation on runtime.

Compliance check works only at the Runtime level.