What are Transaction Models

The transaction models represent the variety of business message types, such as invoices or purchase orders. Each model matches the rules as specified by the standard. Transaction models are used as part of X12Group's Transactions object and EdifactGroup's Transactions object.



	"Model": "EdiNation.Edifact.UN.D96A",
	"UNH": {
		"MessageReferenceNumber_01": "000000101",
		"MessageIdentifier_02": {
			"MessageType_01": "ORDERS",
			"MessageVersionNumber_02": "D",
			"MessageReleaseNumber_03": "96A",
			"ControllingAgencyCoded_04": "UN"
	"BGM": {
			"Documentmessagenamecoded_01": "220"
		"Documentmessagenumber_02": "128576",
		"Messagefunctioncoded_03": "9"
	"DTM": [{
			"Datetimeperiodqualifier_01": "137",
			"Datetimeperiod_02": "20020830",
			"Datetimeperiodformatqualifier_03": "102"
	"PAI": {
			"Paymentmeanscoded_03": "42"
	"_comment": "... rest of the contents ...",


X12 Example

	"Model": "EdiNation.X12.HIPAA.005010",
	"ST": {
		"TransactionSetIdentifierCode_01": "837",
		"TransactionSetControlNumber_02": "0021",
		"ImplementationConventionPreference_03": "005010X222A1"
	"BHT_BeginningOfHierarchicalTransaction": {
		"HierarchicalStructureCode_01": "0019",
		"TransactionSetPurposeCode_02": "00",
		"SubmitterTransactionIdentifier_03": "244579",
		"TransactionSetCreationDate_04": "20061015",
		"TransactionSetCreationTime_05": "1023",
		"TransactionTypeCode_06": "CH"
	"AllNM1": {
		"Loop1000A": {
			"NM1_SubmitterName": {
				"EntityIdentifierCode_01": "41",
				"EntityTypeQualifier_02": "2",
				"ResponseContactLastorOrganizationName_03": "PREMIER BILLING SERVICE",
				"IdentificationCodeQualifier_08": "46",
				"ResponseContactIdentifier_09": "TGJ23"
			"PER_SubmitterEDIContactInformation": [{
				"ContactFunctionCode_01": "IC",
				"ResponseContactName_02": "JERRY",
				"CommunicationNumberQualifier_03": "TE",
				"ResponseContactCommunicationNumber_04": "3055552222",
				"CommunicationNumberQualifier_05": "EX",
				"ResponseContactCommunicationNumber_06": "231"
	"_comment": "... rest of the contents ...",


Available Models

EdiNation provides a vast and always-expanding library of EDI models. These are referred to as System models and are available to all API consumers.

System models are available for the following EDI standards:


Custom Models

On top of that, custom models (models not created by EdiNation) can be uploaded with a valid API subscription. Every API consumer can publish and maintain their own set of models, only visible and accessible as part of their subscription, and used in conjunction with the System models.

Internally, all our models adhere to the EdiFabric format, hence when you create a custom model, it needs to be compatible with EdiFabric's templates.

We will be supporting other, language-agnostic, formats in the near future, such as YAML, but for the moment only EdiFabric templates are supported.



Model string

Model identifier. This is the only constant attribute for each transaction. It specifies the model that was used to translate or validate it. This attribute is optional, however, when specified, it overrides any resolution logic.


Model Resolution

Internally, models are resolved at runtime, inferring the model from the payload content. The model can be explicitly set by populating the Model attribute to override any resolution logic.


The transaction type is the value in the ST.TransactionSetIdentifierCode_01 field and the transaction version is the value in either ST.ImplementationConventionPreference_03 or GS.VersionAndRelease_8 if the former is blank.


The transaction type is the value in the UNH.MessageIdentifier_02.MessageType_01 field and the transaction version is the value in both UNH.MessageIdentifier_02.MessageVersionNumber_02 and UNH.MessageIdentifier_02.MessageReleaseNumber_03.

The engine will try to load the corresponding model for that transaction type and version, and will then parse it accordingly, setting the Model attribute to the model identifier that was used.

In situations when no model can be found, the engine will try to parse the file using the closest model to the inferred version and given the translation was successful, a warning will be added to the X12Interchange stating that the transaction was parsed using a secondary model.


Model SDKs

All models are available for consumers as:

  • Swagger JSON Resolved
  • C# classes

You can use the Swagger file to generate YAML or a client SDK in any language by using SwaggerHub for example.

Alternatively, you can use the C# files, which although extensive, are POCOs and have a very simple structure of classes with string or list properties. 

Was this article helpful?
0 out of 0 found this helpful