Modify EDI Templates

Sometimes you need to modify your existing EDI template(s) for reasons such as:

  1. A trading partner uses custom EDI codes
  2. A trading partner uses an extra field for segment ABC
  3. A trading partner requires an optional data element to be mandatory
  4. A trading partner uses loop ABC before loop DEF
  5. My DBA wants to add some extra properties to the template, not relevant to EDI

It is perfectly fine to go ahead and do any of these changes. The rule of thumb is to maintain the baseline version in one project and to move all partner-specific customization into separate projects. This way the baseline version is shielded from any changes and all new modifications are safely isolated into their own containers.

 

 

 


 

 

 

Partner-specific customization (with inherited EDI template)

For example - let's assume that a trading partner sends you 835 transactions where the first data element in the SVC segment contains a non-standard EDI code. The code is "MY_CUSTOM_CODE". Because this code is not part of the standard X12 specification and EDI template, reading this transaction will result in a parsing error. The reason for this is that for all HIPAA templates, the first (and the second if the first is EDI code) data element is used to determine the level/depth of the containing segment.

Download the example projects:

Generally, all EDI codes that are used for validation only (not at position 1 or 2 in any segment), can be modified dynamically by using DataElementCodesMap or DataElementTypeMap. In order to support such a modification, you can either make a copy of the template, add the extra code in the codes file, and reference it from another project (see the next paragraph), or use inheritance, and add the modification without changing the baseline template.

Standard X12 codes for X12_ID_235 in SVC

AD,ER,HC,HP,IV,N4,N6,NU,UI,WK

The partner uses a custom EDI code in this data element - "MY_CUSTOM_CODE".

Partner-specific codes for X12_ID_235 in SVC

AD,ER,HC,HP,IV,N4,N6,NU,UI,WK,MY_CUSTOM_CODE

We'll create a new class that derives from TS835, and apply all the changes to it.

///
/// Create a custom version of the EDI template
/// 
public class TS835_Custom : TS835
{
	[DataMember]
	[Pos(8)]
	public new List<Loop_2000_835_Custom> Loop2000 { get; set; }
}

[Serializable()]
[DataContract()]
[Group(typeof(LX_HeaderNumber))]
public class Loop_2000_835_Custom : Loop_2000_835
{
	[DataMember]
	[Required]
	[Pos(4)]
	public new List<Loop_2100_835_Custom> Loop2100 { get; set; }
}

[Serializable()]
[DataContract()]
[Group(typeof(CLP_ClaimPaymentInformation))]
public class Loop_2100_835_Custom : Loop_2100_835
{
	[DataMember]
	[ListCount(999)]
	[Pos(11)]
	public new List<Loop_2110_835_Custom> Loop2110 { get; set; }
}

[Serializable()]
[DataContract()]
[Group(typeof(SVC_ServicePaymentInformation_Custom))]
public class Loop_2110_835_Custom : Loop_2110_835
{
	[DataMember]
	[Required]
	[Pos(1)]
	public new SVC_ServicePaymentInformation_Custom SVC_ServicePaymentInformation { get; set; }
}

[Serializable()]
[DataContract()]
[Segment("SVC", typeof(X12_ID_235_15_Custom))]
public class SVC_ServicePaymentInformation_Custom : SVC_ServicePaymentInformation
{

}

Finally the actual change to the EDI code in a new EDI code class:

///
/// Specify a custom code for the first data element in SVC
/// 
[Serializable()]
[DataContract()]
[EdiCodes(",AD,ER,HC,HP,IV,N4,N6,NU,UI,WK,MY_CUSTOM_CODE,")]
public class X12_ID_235_15_Custom
{
}

That's it. We created a custom, partner-specific template, which we can use when that partner sends us 835 transactions:

Stream ediStream = File.OpenRead(@"C:\\Custom835.txt");
List<IEdiItem> ediItems;
using (var ediReader = new X12Reader(ediStream, (ISA isa, GS gs, ST st) 
    => typeof(TS835_Custom).GetTypeInfo()))
	ediItems = ediReader.ReadToEnd().ToList();

var custom835 = ediItems.OfType<TS835_Custom>();

 

 

 


 

 

 

Partner-specific customization (with new EDI template)

For example - let's assume that you exchange X12 4010 EDI messages with multiple trading partners. A new trading partner comes along, however, they use a custom representation of BEG segments, which introduces a new property and marks the release number at position 4 as mandatory for validation.

Download the example projects:

Keep the standard X12 templates in a separate project. A good design is to also move the segment and complex interfaces files into a separate project and add a reference to it:

mceclip0.png

Create a separate project, for this particular trading partner only, let's call it PartnerB. Then copy the file for message 850, the segments file, the EDI codes file, and the complex elements file, to which we are going to apply all the partner-specific modifications.

mceclip1.png

Ensure to add a reference to the common interfaces project, given that you created one.

Open EF_X12_004010_Segments.cs and apply the following modifications to the BEG segment:

mceclip5.png

mceclip4.png

The changes are:

  • The property at position 4 is marked as [Required]
  • A new property is added at position 13 - NewField_13

The modification will let the new template to support the following BEG segment:

BEG*00*SA*XX-1234*MANDATORY*20170301**NA******NEWVALUE~

where NEWVALUE is at position 13.

We now have two projects defining a template for purchase order (TS 850), so how to tell the parser when to use which one? In the event of knowing the origin of the EDI file you can simply change the template assembly in the X12Reader constructor like this:

// partnerSource can be folder name, file name, etc.
string templateAssembly = "EdiFabric.Examples.X12.Templates.V4010";
if(partnerSource == "ParnerB")
    templateAssembly = "EdiFabric.Examples.X12.Templates.V4010.PartnerB";
    
using (var ediReader = new X12Reader(ediStream, templateAssembly))

 

 

 


 

 

 

How to use the custom templates - Load Factory

All modifications can be dynamically loaded by using a load factory. Every EDI document identifies the sender by the Sender ID in the ISA\UNB segment. This identifier is unique across the trading partners you'll be exchanging messages with.

For our scenario above, we need to identify the trading partner that uses the modified BEG segment and load the TS850 template from the customized project. For all other trading partners, we will be loading the baseline version of the TS850 template.

Let's assume that this trading partner ID is CUSTOM1 and when we receive EDI document from this partner:

ISA*00* *00* *16*CUSTOM1 *1B*RECEIVER1 *071216*1406*U*00204*000000263*1*T*>~

we will load the modified template:

abmceclip1.png

and tell the reader to use this logic when reading EDI documents:

var ediReader = new X12Reader(ediStream, FullTemplateFactory)

  

 

 


 

 

 

 

How to add custom properties to my EDI Templates?

Sometimes you might need to modify your existing EDI template(s) and add your own custom properties that are irrelevant to both the parser and EDI in general. This is known as "mixed-mode" when the template is used not only for EDI but for other purposes as well.

All you need to do is to simply add the property. The parser only uses properties annotated with PosAttribute and discards all others. You can take a look at the Id property we added to every class in order to be used by Entity Framework as a POCO:

 

mceclip6.png

You still have to add all the properties needed for serialization to XML\JSON.

 

 

 

 


 

 

 

EDI Templates and Inheritance

All templates support inheritance. This allows you to define a custom template that reuses, extends, or modifies the behavior of an original template.

When EdiFabric Framework is incorporated into any existing applications, the common architecture is to introduce a mapping layer to convert the instances of EDI templates into instances of other classes, usually database or the existing domain.

EDI template inheritance minimizes the impact to that mapping layer when template modifications are required. Any new template that inherits from another template, retains the existing mapping functionality applicable to the original template. The mapping logic for the modification can be implemented in a separate component thus having no impact whatsoever on the existing maps.

EDI template inheritance can be applied to any EDI DOM class by following these rules:

  • Inherited classes must still define all DOM and validation attributes. For example, if you want to inherit from

The new class must still define the original DOM attributes:

  • Hidden or overridden properties must still define all DOM and validation attributes. For example, if want to add an extra validation attribute to ReleaseNumber_04 property and make it mandatory

 

The new class must still define the original DOM attributes:

  • To ensure that properties in a base and any inherited classes do not duplicate positions. The parser will throw an exception if there are any properties marked with the PosAttribute for the same position.
Was this article helpful?
0 out of 0 found this helpful