EDI Tools for .NET validates EDI documents by annotating their respective EDI templates with validation attributes, and then invoking the validation by calling the IsValid() method of EdiMessage. For more information on how to validate EDI documents head on to the Validate EDI with templates article.

• ValidationSettings Reference
• EdiMessage Reference

To control how EDI transactions are being validated, a ValidationSettings object can be passed to the IsValid() method of EdiMessage.

Common EDI validation settings

• SkipTrailerValidation - whether to skip trailer validation in messages ('false' by default). This is useful when you are generating a POCO and haven't created any trailer segments, such as SE or UNZ, because they will be automatically appended by the EdiWriter. This flag tells the validator to skip over any validation that includes trailer segments.
• DecimalPoint - The decimal point for Edifact only ('.' by default).
• SyntaxSet - The syntax set used to validate alphanumeric data types (not set by default). Read about EDIFACT data element validation and X12 data element validation for additional information.
• DiscardValidationAttributes - turns off validation attributes. Only header/trailer control number match and segments count in trailer match are validated. This is used for HIPAA SNIP Type 1 validation.
• DataElementTypeMap - allows you to apply different sets of EDI Codes than the ones in the EDI Template.
• DataElementCodesMap - allows you to import external EDI codes at runtime.

Apply validation settings to IsValid

ValidationSettings settings = new ValidationSettings();
settings.SkipTrailerValidation= true;
settings.DecimalPoint = '.';
settings.SyntaxSet = new Basic();
settings.DataElementTypeMap = new Dictionary<Type, Type>();
settings.DataElementCodesMap = new public Dictionary<string, List<string>>();

ediMessage.IsValid(out errorContext, settings);

What is SyntaxSet?

EDI data element data types such as alpha and alphanumeric are not validated by default. You need to explicitly enable this type of validation that checks if the value of data elements matches the list of allowed characters.

• How to validate X12 data elements
• How to validate EDIFACT data elements

EDI code sets

[EdiCodes(",00,18,19,")]
 public class X12_ID_353

EDI code sets are represented as classes marked with the EdiCodesAttribute. The only parameter is a string containing all of the allowed EDI codes, delimited with a comma.

• How to represent EDI transactions with EDI templates
• EdiCodesAttribute Reference

What is DataElementCodesMap?

Let's illustrate this for Transaction Set Purpose Code, represented by the X12_ID_353 class in the X12 EDI template in version 4010, however, the principle is the same for any EDI code set.

The standard X12_ID_353 code set is defined as allowing the following values: 00, 18, and 19.

/// 
/// Transaction Set Purpose Code
/// 
[Serializable()]
[DataContract()]
[EdiCodes(",00,18,19,")]
 public class X12_ID_353

Let's assume that a fictional partner A requires a custom set of EDI codes for X12_ID_35, instead of the standard ones, which only allows the following values: 00, PA, and PB.

The templates using this class can be changed to use a new class, for partner A, however, the validation can be configured without any changes to the existing EDI template. The new values can be configured as a DataElementCodesMap in the ValidationSettings. This way IsValid() will match the new values instead of the standard values.

var codeSetMap = new Dictionary<string, List<string>>();
codeSetMap.Add("X12_ID_353", new List<string> { "00", "PA", "PB" });

ediMessage.IsValid(out errorContext, 
     new ValidationSettings { DataElementCodesMap = codeSetMap });

Use this method to dynamically load external code sets from a file, database, or another configuration source. No redeployment is required and the correct value resolution (by the code set class name) occurs at runtime.

Examples in GitHub:

• Validate X12 transactions with external EDI codes
• Validate EDIFACT transactions with external EDI codes
• Validate HL7 transactions with external EDI codes
• Validate NCPDP Telco transactions with external EDI codes
• Validate NCPDP SCRIPT transactions with external EDI codes

What is DataElementTypeMap?

Similar to the DatElementCodesMap, DataElementTypeMap allows you to validate EDI codes without having to change the whole EDI template, but only the code sets' portion of it. If we continue the example for partner A and X12_ID_353 from the previous sections, a new code set class will need to be created for the values expected by partner A, let's name it X12_ID_353_PartnerA:

/// 
/// Transaction Set Purpose Code
/// 
[Serializable()]
[DataContract()]
[EdiCodes(",00,PA,PB,")]
public class X12_ID_353_PartnerA
{
}

Then configure a DataElementTypeMap, which tells the validation to use the new code set class instead of the original one.

Dictionary<Type, Type> codeSetMap = new Dictionary<Type, Type>();
codeSetMap.Add(typeof(X12_ID_353), typeof(X12_ID_353_PartnerA));

ediMessage.IsValid(out errorContext, 
     new ValidationSettings { DataElementTypeMap = codeSetMap });

Use this method to statically load external code at design time. Redeployment is required and the correct code class resolution (by the code set type) occurs at runtime.