Articles in this section

Understand the EDI validation rules

To successfully exchange EDI data with trading partners, you must ensure that the data complies with EDI standards and the specific guidelines set by each trading partner. Verifying that all mandatory and optional segments/elements are populated correctly by processing the EDI data according to the file definition compliance rules is important. Finally, the EDI document must be validated against its EDI standards before it’s sent to the destination.

For X12 format validation, the compliance check must adhere to X12 Org standards. Each trading partner may also have specific requirements for processing the EDI data rules.

While editing an import or export in Flow Builder, after you select the file type as EDI x12, the file definition rules are present in the File parser/generator helpers.

Important

  • For EDI document validation for trading partners, if you set the skipEDIValidation field to "true", only structural validation is performed. By default, the setting’s value is "false", so the input EDI file triggers validation against the EDI standards configured in the file definition rules for the trading partner’s EDI documents.

Note

The supported data types are string and number.

EDI compliance validation includes the following file definition entities:

  • ED Loop or Segment level:

    • Mandatory/Optional Segments

    • Max Use Segments

    • Looping Groups

  • EDI Element level:

    • Min/Max element lengths

    • Qualified elements (Codelist lookups)

    • Element Type

    • Mandatory/Optional elements

    • Conditional elements (relationships)

For the X12 file type, it is recommended not to update the below field names in the File Definition Rules to avoid errors. The below fields are synced to the EDI Dashboard only if they exist in the X12 file.

  • ISA13: Interchange Control Number

  • GS06: Group Control Number

  • GS01: Functional Identifier Code

  • ST02: Transaction Set Control Number

  • ST01: Transaction Set Identifier Code

  • BEG03: Purchase Order Number

  • BCH03: Purchase Order Number

  • BAK03: Purchase Order Number

  • BIG02: Invoice Number

  • BSN02: Shipment Identification

  • ISA05: Interchange Sender ID

  • ISA07: Interchange Receiver ID

  • GS02: Application Sender's Code

  • GS03: Application Receiver's Code

  • Document Number: The primary document numbers such as 850, 860, 810, 856, and 855 should not be updated as per the Celigo EDI standards.

A file definition is designed to process EDI files based on the following components:

Elements

An element is an individual item within an EDI document. For example, within many documents, such as the purchase order or invoice, you will find data elements such as city, state, country, item number, quantity, and price. An element is a placeholder between two different special characters. A delimiter character separates each element.

  • Delimiters/Separators: A special character that indicates semantic data's end and/or beginning.  Delimiters are required since some elements are variable in length.

  • Terminators: A special character that marks the end of a segment.

Segments

A segment is a group of related data elements and a structural component of any EDI message. A segment starts with a three-character data identifier and ends with a segment terminator. In an EDI file, each line is considered to be a segment.

  • At the segment level, the value of the required object defines if the segment is mandatory. If the value is true, the field is expected to be present. If the value is false, the field is optional.

  • At the element level, the value of the required object defines if the segment is mandatory. If the value is true, the field is expected to be present. If the value is false, the field is optional.

  • The minLength, maxLength, and type (datatype) are elements within each segment element.

    • minLength: The minimum length of an element

    • maxLength: The maximum length of an element

    • Type: The data type of an element. The valid values are String and Number.

EDI specification for a segment

Segment.jpg

Example of Segment rule structure for X12 for the segment mentioned above for element BEG01

{      
"maxOccurrence": 1,
"skipRowSuffix": true,      
"required": false,      
"elements": [
        {
          "name": "BEG",
          "value": "BEG"
        },
        {
          "name": "Beginning of a segment",
          "value": "BEG01",
         "maxLength": 5,     ⇐ Defines the max field length
          "minLength": 1,       ⇐ Defines the min field length
          "type": "String",     ⇐ Defines the datatype
          "required": true    ⇐ Defines if the field is mandatory or not
        }
      ]

Loops

A loop is a logical group of segments that can have sub-loops with other groups of segments. Loops can have mandatory and optional segments. The first segment listed in the loop is mandatory.

EDI spec for Loop

Each Loop can contain one or more types of segments

Loop.jpg

Example of Loop rule structure for X12

{  
"name": "PO1",  
"maxOccurrence": 100000,  
"container": true,  "children": [
    {
      "skipRowSuffix": true,
      "required": true,
      "elements": [
        {
          "name": "PO1",
          "value": "PO1"
        },
        {
          "name": "Assigned Identification",
          "value": "PO101",
          "maxLength": 5,
          "minLength": 1,
          "type": "String",
          "required": true
        }
      ]
    }
  ]
}

Relationships

A relationship exists when two or more linked elements are present in a segment. A relationship consists of one required and conditional element (if one element is present, then other elements must also be present). It includes an array object relationship, which refers to the dependency for an element in the segment.

Types

X12 & EDIFACT Representations

File definition rule representation

Case 1

(One or more)

At least one of the specified elements must be present.

ANSI X12: R030405

"Relationship": [        "R,03,04,05"    ]

Case 2

(If first, then all)

If a specified element is present, then all of the specified elements in a dependent element set are present. 

ANSI X12: C030405

"Relationship": [        "C,030,040,050"    ]

Case 3

(One or none)

Only one of the specified elements can be present.

ANSI X12: E030405

"Relationship": [        "E,03,04,05"    ]

Case 4

(If first, then at least one)

If a specified element is present, at least one of the elements specified in a dependent set of elements also must be present. 

ANSI X12: L030405

"Relationship": [        "L,03,04,05"    ]

Case 5

(All or none)

All of the specified elements must be present or absent.

ANSI X12: P030405

"Relationship": [        "P,03,04,05"    ]

Case 6

(One and only one)

Only one element must be present.

ANSI X12: N/A

"Relationship": [        "O,030,040,050"    ]

Case 7

(If first, then none)

If the first element is present, other elements are not applicable.

ANSI X12: N/A

"Relationship": [        "I,030,040,050"    ]

Breakdown of the File definition rule Relationship representation

"Relationship": [ "R,03,04,05" ]

  • R: The first character in the object that represents the case type (mentioned in the above table).

  • 03,04,05 - The elements in a segment. For X12 format elements, the length is two characters.

EDI spec for Relationships

Syntax rules:

  • If PO103 is present, then PO102 is required

  • If either PO106 or PO107 is present, the other is required.

Example of Relationship rule structure for X12

{
  "name": "PO1",
  "required": false,
  "maxOccurrence": 3,
  "container": true,
  "children": [
    {
      "skipRowSuffix": true,
      "required": false,
      "elements": [
        {
          "name": "PO1",
          "value": "PO1"
        },
        {
          "name": "Entity Identifier Code",
          "value": "PO101"
        },
          "name": "Entity Identifier",
          "value": "PO102"
        },
        .
        .
        .
        {
          "name": "Currency Code",
          "value": "PO112"
        }
      ],
      "relationship": [
       "C,03,02",
       "P,06,07" ]
    }
  ]
}

Codelist

An array of objects holds the possible set of values permitted for a field. The enum field includes the expected set of values to be validated against.

EDI spec for Codelist

Codelist.jpg

Example of Codelist rule structure for X12

{
  "name": "Entity Identifier Code",
  "value": "BEG01",
  "type": "String",
  "maxLength": 5,
  "minLength": 1,
  "required": true,
  "enum":
       [
         "00",
         "01",
         "07"
        ]
Was this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Please sign in to leave a comment.