Because computers do not have the flexibility of
reading and translating documents like humans do, it is important to have a standard file format
in EDI so that computers can read and translate EDI documents correctly. It
is also just as important for users who are processing EDI files to adhere to the EDI standard. One method of enforcing
the EDI standard is to validate any incoming EDI documents before they get
translated. Validation not only ensures a more accurate EDI translation,
but also ensures a more robust automated process by detecting and rejecting EDI files
with anomalies that could break the translation program
and interrupt production.
The Framework EDI component is a powerful tool
that gives users almost unlimited ability to validate an EDI file. It uses
a Standard Exchange Format (SEF) file to obtain the EDI implementation
guideline, which it would use to match against the EDI file it is
validating. Discrepancies between the SEF file and EDI file would then be
reported as errors. The eFileManager Utility is an example of such
application that uses the same process for validation.
The eFileManager Utility - an EDI validation tool
This web page will briefly describe how-and-what
Framework EDI validates in an EDI file.
Framework EDI reads the position numbers of data segments and data elements in a SEF
file to determine the correct positions and ordering of data segments and data
element in an EDI file.
Requirement Framework EDI reads the Requirement of data segments and data
elements in a SEF to determine if a data segment, or data element is Mandatory
or Optional in an EDI file.
Framework EDI reads the User Requirement of data segments and data elements in a
SEF file to determine if a data segment, or data element is Must Use, Not
Used, or Used in an EDI file.
Minimum and Maximum Length
Framework EDI reads the Minimum and Maximum Length of data elements in a SEF file
to determine if the value length of a data element in an EDI file is within the
minimum and maximum length range.
Framework EDI reads the Maximum Usage of data segments in a SEF file to determine the
maximum number of times an instance of a data segment can be repeated in an EDI
Framework EDI reads the Loop Repeat count of loops in a SEF file to determine the
maximum number of times an instance of a loop can be repeated in an EDI file.
Framework EDI reads the Syntax Rules for each data segments in a SEF file to
determine the relationship of their data elements in an EDI file. An
example of a syntax rule is - if either data element(1) or data
element(2) is present, then the other data element must be present.
Framework EDI reads the Code List of data elements in a SEF file to determine if a code
used in a data element. in an EDI file is valid.
(available only in FREDI version 5.0.2005.403 and after ) Framework EDI reads the Value Reference of data elements in a SEF file to
make sure the values of associated data elements in an EDI file follow the
value expression defined, or is included in the list of values defined. For example, a data element in a SEF file can have a Value Reference
expression "[0-9][0-9][0-9][0-9][0-9]", which
means that the format of the value of the same data element in the EDI file can
only contain numeric characters and must be 5 characters long.
Another example of the use of Value List is to have a list of values that
are allowable for a
specific data element. This is similar to a code list, but a Value
List is more flexible
in that a conditional statement (semantic references) can call it.
Semantic References(available only in FREDI version 5.0.2005.403
and after )
Framework EDI reads the Semantic References of data segments and data elements in a SEF
File to determine if a conditional value, or existence of a data segment or data element
in an EDI file is valid. An example
of a semantic reference is - if data element(3) equals "FI" then
data element(4) use value reference TAXIDFORMAT.
Another example of a semantic reference is - if data element(3) value in
SVC segment is greater than 0, then data segment AMT must be used.
Framework EDI reads Triggers in SEF files (under PRIVATE EDIdEv) to identify and
hold separately the schema for each instance of data segments and loops, thus enabling
Framework EDI to validate instances (identified by their qualifier) of a data
segment or a loop in an EDI file. For example, an EDI file can have a loop
with two instances having different requirements: one loop instance having the Payer information and having data
segments N3 and N4 as mandatory; while the second loop instance having the Payee
information, but having data segments N3 and N4 as optional.
By using SEF files to obtain the EDI implementation
guideline, Framework EDI can almost have no limit to what it can validate in an EDI
file. Basically, if a rule can be specified in the SEF file, then
Framework EDI (using the same SEF file) will enforce the same rule in an EDI file. SEF files are text files, which can be edited with any text
editor, or with our SEF Manager utility. For more details about editing a
SEF file with the SEF Manager, please read Creating
an Implementation Guideline.
Below is a sample Visual Basic program
that demonstrates how the Framework EDI component uses a SEF file to validate an EDI