Documentation

How to validate EDIFACT data elements

Article author
Admin
  • Updated

EDIFACT data elements

All data elements in the EDI templates are represented as System.String. This allows the underlying type to be conveniently discarded during parsing or generation, and to practically read/write any text data, regardless.

Being type-agnostic, EDI Tools for .NET is able to easily recover corrupt files, broken data, or incorrectly set encoding. Data and type validation is pushed to a follow-up operation such as calling the IsValid() method on the POCO.

 

DataElement attribute and EdiCodes attribute

EDI Tools for .NET validate the type of data elements using the type configured on the DataElement attribute.

 [DataElement("96", typeof(EDIFACT_AN))]
 [Pos(1)]
 public string NumberofIncludedSegments_01 { get; set; }

The first parameter is the EDI identifier of the data element. The second parameter is the type of the data element. 

EDI Tools for .NET supports the following data element types for the EDIFACT standard:

  • EDIFACT_N - for numeric values
  • EDIFACT_A - for alphabetic values
  • EDIFACT_AN - for alphanumeric values
  • EDIFACT_DT - for date values (not used)
  • EDIFACT_TM - for time values (not used)
  • EDIFACT_ID - for code sets

If the data type is annotated with EdiCodesAttribute, the data element value will be validated against the list of specified EDI codes.

 [DataElement("96", typeof(EDIFACT_ID_1049))]
 [Pos(1)]
 public string NumberofIncludedSegments_01 { get; set; }

EDI code type EDIFACT_ID_1049 is defined as:

[EdiCodes(",1,10,11,2,5,6,7,8,9,")]
public class EDIFACT_ID_1049
{
}

EdiCodes supports partition codes, as defined by the SEF format. 

 

List of EDIFACT data types

Numeric - N

A data element can include digits and a decimal mark (either point or comma is acceptable for this).

EDIFACT notation combines the type and length as in the following examples:

n..9 up to nine digits

n9 exactly nine digits

If the element has a variable length, omit leading zeros and trailing spaces unless significant. A single zero before a decimal is significant, and a zero may be significant if the element’s specification states that it is.

Signs and decimals don’t count toward maximum field length. The sign must be omitted unless negative.

If the number is fractional, include the decimal mark. If a decimal mark is included in the EDI file, include at least one digit before and after it. Do not include decimals for integers unless needed to indicate precision.

The official representation for the decimal mark is the comma. If a UNA is included, its third character specifies the decimal mark.

The C# class representing numeric EDIFACT data type is:

 [Serializable()]
 public class EDIFACT_N
 {
 } 

 

Alphabetic - A

Data element can include any letters, special characters, and control characters but no digits.

EDIFACT notation combines the type and length as in the following examples:

a3 exactly 3 alphabetic characters.

a..3 up to three alphabetic characters.

The C# class representing alphabetic EDIFACT data type is:

 [Serializable()]
 public class EDIFACT_A
 {
 } 

 

Alphanumeric - AN

Data element can include any letters, digits, special characters, and control characters.

EDIFACT notation combines the type and length as in the following examples:

an5 exactly 5 alphanumeric characters

an..5 up to 5 alphanumeric characters.

The C# class representing alphanumeric EDIFACT data type is:

 [Serializable()]
 public class EDIFACT_AN
 {
 } 

 

How to validate EDIFACT data types

By default, calling IsValid() only validates numeric data types. Alphabetic and alphanumeric data types are not validated. Type validation is global, e.g. all data elements marked with the same type are validated in exactly the same way.

To validate alphabetic and alphanumeric EDIFACT data elements, a SyntaxSet must be configured in the ValidationSettings.

The following syntax set implementations are available:

 

UNOA

Valid characters are:

ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789.,–() /=

 MessageErrorContext result;
 var validationResult = msg.IsValid(out result, 
new ValidationSettings { SyntaxSet = new Unoa()});

 

UNOB

Valid characters are:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789.,–() /=‘+:?!”%&*;<>'""

 MessageErrorContext result;
 var validationResult = msg.IsValid(out result, 
new ValidationSettings { SyntaxSet = new Unob()});

 

Custom characters

Use CustomSyntax to specify a custom set of chars across all A or AN data types.

 MessageErrorContext result;
 var validationResult = msg.IsValid(out result, 
new ValidationSettings {
SyntaxSet = new CustomSyntax(new Unoa().GetValidChars() + "ß")});

 

Regex

Use RegexSyntax to specify a custom regex for all A or AN data types.

 MessageErrorContext result;
 var validationResult = msg.IsValid(out result, 
new ValidationSettings {
SyntaxSet = new RegexSyntax(new Regex("[a-zA-Z0-9 ]"))});

Examples in GitHub:

 

How to override syntax set validation

Sometimes a particular data element needs to be validated slightly differently than the syntax set specified in the ValidationSettings for its type. This can be achieved by overriding the syntax set with a regex expression directly in the DataElement attribute:

[DataElement("5286", typeof(EDIFACT_AN), @"^[A-Za-z0-9., %]*$")]
[Pos(4)]
public string Dutyortaxorfeeassessmentbasisvalue_04 { get; set; }

The overridden data element will always be validated against the regex specified in the DataElement attribute, ignoring the syntax set specified in the ValidationSettings.

 

How to validate UNB and UNG

To validate the control segments UNB and UNG call the Validate() method of the ContolSegment class. The EDIFACT control segments are defined in the  EdiFabric.Core.Model.Edi.Edifact namespace.

It is also possible to override the default validation for UNB and UNG by deriving from the UNB and UNG classes. The derived classes can define whatever data element attributes are needed and to return the derived control segments whilst reading from an EDIFACT file, the EdifactReaderBase constructor must be used, instead of EdifactReader.

Examples in GitHub:

 

How to validate EANCOM EDI codes

Validating EANCOM messages uses the same functionality as that for EDIFACT messages with several assumptions.

All validation attributes across the EANCOM EDI templates define loosely their respective EDI Codes. For example, the EDI Codes for ID 2005 are defined as:

The allowed values for ID 2005 differ across segments and levels, for example, the implementation guide for GS1 INVOIC Syntax 4 states that:

  • For DTM in RFF loop, the allowed codes are

    eancom edi

  • For DTM in LOC Loop, the allowed codes are

    eancom codes

In case a more detailed validation is required, the validation attributes need to be manually configured.

Share this:

Was this article helpful?

Comments

0 comments

Please sign in to leave a comment.