To successfully exchange EDI data with trading partners, you must ensure that the EDI data in your exports and imports complies with standards and the specific guidelines set by each trading partner.
For X12 format validation, the compliance check must adhere to X12 standards. Each trading partner may also have specific requirements for processing the EDI data rules. While creating or editing an EDI import or export in Flow builder, you can launch the File parser or generator helpers and check the EDI data with the file definition rules (FDRs v2) present in these helpers to ensure compliance.
A typical EDIFACT file consists of mandatory and optional segments based on standards and requirements of your trading partner, for example:
UNB+UNOA:2+123456TEST:01+102096559TEST:16+071121:1334+00000000000100+CONTRL
UNH+00000000000476+CONTRL:D:97A:UN
UCI+00000000000476+102096559TEST:16+123456TEST:01+7
UCM+1+INVOIC:D:97A:UN+7
UCM+2+INVOIC:D:97A:UN+7
UCM+3+INVOIC:D:97A:UN+7
UNT+15+00000000000476
UNZ+1+00000000000100
- UNB: Interchange Header
- UNH: Message Header
- UCI: Interchange Response
- UCM: Message Response
- UNT: Message Trailer
- UNZ: Interchange Trailer
For EDIFACT format validation, the compliance check must adhere to the UNECE standard. Each trading partner may also have specific requirements for processing the EDI data rules.
Important
For EDI document validation of 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 export or input EDI file triggers validation against the EDI standards configured in the file definition rules for the trading partner’s EDI documents. Also, the EDI parser helper automatically uses the separators found in your sample file, if they differ from the separator values in the FDRs, to parse the file. However, they are not automatically added to the FDRs.
Note
The supported data types are string and number.
EDI compliance validation includes the following file definition entities:
-
EDI Elements
Min/Max element lengths
Qualified elements (Codelist lookups)
Element type
Mandatory/Optional elements
Conditional elements (relationships)
-
EDI Loops or Segments
Mandatory/Optional segments
Max use segments
Looping groups
For the EDIFACT file type, it is recommended not to update the field names listed below in the File Definition Rules to avoid errors. These fields are synced to the EDI activity dashboard only if they exist in the EDIFACT file.
A file definition is designed to process EDIFACT files based on the following components:
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.
Purpose |
Default EDIFACT characters |
|---|---|
Segment Delimiter |
|
Element Delimiter |
|
Sub Element Delimiter / Composite Delimiter |
|
Release Character |
|
These are the standard EDIFACT default characters. When you parse an inbound file, B2B Manager reads the separators from the file itself and uses them instead. The delimiters saved in the file definition rule (FDR) are used only as a fallback.
Separators in inbound EDIFACT files
When you parse an inbound EDIFACT file, B2B Manager reads the composite separator, element separator, release character, and segment terminator from the interchange header, so you don’t need to edit the FDR for each trading partner. If the file has a UNA segment, B2B Manager uses it. Otherwise it automatically reads the separators from the UNB segment. UNA takes precedence over UNB.
| Separator | With a UNA segment | Without a UNA segment (read from UNB) |
| Component separator |
UNA1 (position 4) |
The separator inside UNB010, for example the colon in UNOA:2
|
| Element separator |
UNA2 (position 5) |
The character immediately after UNB |
| Release character |
UNA4 (position 7) |
Can’t be read from the file. B2B Manager uses ?
|
| Segment terminator |
UNA6 (position 9) |
The character that ends the UNB segment |
Example (with UNA): In UNA:+.? ' the composite separator is :, the element separator is +, the release character is ?, and the segment terminator is '.
Note
Fallback: If the file has no UNA segment and the UNB segment can’t be read, B2B Manager uses the delimiters saved in the FDR and returns an error if the file still can’t be parsed.
The automatically detected separators apply only to that parse, in both the EDI parser helper preview and at runtime. The saved FDR isn’t changed.
For outbound files, that is import files, generating an EDIFACT file still uses the delimiters in the FDR or EDI profile.
Limitation: For a file without a UNA segment, a non-default release character can’t be recovered, so ? is assumed.
Segments – EDIFACT
A segment is a group of related data elements and a structural component of any EDI FACT 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
requiredobject defines if the segment is mandatory. If the value istrue, the field is expected to be present. If the value isfalse, the field is optional. - At the element level, the value of the
requiredobject defines if the segment is mandatory. If the value istrue, the field is expected to be present. If the value isfalse, the field is optional. -
The
minLength,maxLength, andtype(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.
EDIFACT specification for a segment
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.
EDIFACT spec for Loop
Each Loop can contain one or more types of segments
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.
|
"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.
|
"Relationship": [ "C,030,040,050" ] |
|
Case 3 (One or none) |
Only one of the specified elements can be present.
|
"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.
|
"Relationship": [ "L,03,04,05" ] |
|
Case 5 (All or none) |
All of the specified elements must be present or absent.
|
"Relationship": [ "P,03,04,05" ] |
|
Case 6 (One and only one) |
Only one element must be present.
|
"Relationship": [ "O,030,040,050" ] |
|
Case 7 (If first, then none) |
If the first element is present, other elements are not applicable.
|
"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 / EDIFACT format elements, the length is two characters.