EDI Rules

EdiFabric supports the following standards, versions and transactions:


In the EDI world each business transaction is defined with a standard EDI specification (also known as EDI spec, or EDI schema, or EDI rule). There is no common format for defining these rules, the closest to it would be the open SEF format, which is not actively supported anymore. Each EDI rule describes a particular business document, e.g. an invoice or a purchase order and is tied up to a version. The governing bodies of X12, EDIFACT and EANCOM are ASC, UNECE and GS1 respectively, and they release new versions of the rules once or twice per year.

Unfortunately the versions are not backward compatible, mainly due to the EDI codes which can change significantly in every subsequent version. An excerpt from a sample rule is shown below:

EDI rules rules

EdiFabric uses plain C# classes to represent EDI documents. Each of the main EDI elements, such as transaction set, segment, data element and composite element are simply classes annotated with our custom attributes. Every class hierarchy can be turned into EDI rule by applying the following attributes:

Transaction set classes are annotated with MessageAttribute and inherit from EdiMessage

[Message("X12", "002040", "810")]
public class TS810 : EdiMessage

EdiMessage is the base class for all transaction sets.

The first parameter is the format (X12 or EDIFACT).

The second parameter is the version (edition + release).

The last parameter is the transaction set identifier.

EdiFabric uses these attribute values to load the correct transaction set class. Classes with the same values for all three attributes are not allowed in the same assembly and are regarded as duplicates.

Classes can contain only ordered public properties

[Pos(1)]
public ST ST { get; set; }
[Pos(2)]
public BIG BIG { get; set; }
[Pos(3)]
public List<NTE> NTE { get; set; }

To order the properties they must be annotated with PosAttribute, which denotes the position of the property within the class.

Repetitions or multiple occurrences are represented as Lists

public List<NTE> NTE { get; set; }

Simple data elements are represented as strings

public string TransactionTypeCode_07 { get; set; }

Segment classes are annotated with SegmentAttribute

[Segment("BHT", typeof(X12_ID_1005), typeof(X12_ID_353))]
public class BHT

The first parameter is the EDI identifier of the segment.

(Optional) The second parameter is a reference to the class defining the allowed EDI codes for the first data element in the segment.

(Optional)The last parameter is a reference to the class defining the allowed EDI codes for the second data element in the segment.

The allowed EDI codes are represented as classes annotated with EdiCodesAttribute

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

The only parameter is a string containing all of the allowed EDI codes, delimited with a comma.

Loop (Group) classes are annotated with GroupAttribute

[Group(typeof(N1))]
public class TS810_N1Loop1

The only parameter is the type of the first (trigger) segment in the group.

HIPAA specific non-sequence groupings are annotated with AllAttribute

[All()]
public class All_NM1_2

Composite element classes are annotated with CompositeAttribute

[Composite("C108")]
public class C108

(Optional) The first parameter is the EDI identifier of the composite element.

Each namespace, class or property name can be renamed.

Conform to every naming convention by the ability to rename anything outside the custom attributes without affecting the framework.