EDIFACT Party Properties

Goal:

To provide in depth information about the EDIFACT Party properties in PAM used by the EDI run time components to process an EDIFACT encoded Interchange.

Overview:

Party properties are divided into a General section used by all EDI components, a contact information tab and a separate EDIFACT and X12 section. The EDIFACT and X12 section is sub divided under Party as Interchange Sender and Party as Interchange Receiver nodes.

Party as Interchange Sender:

The settings from Party as Interchange Sender node are applied during Receive Side processing. This node is subdivided as follows:

EDIFACT Interchange Processing Properties:

These settings are used by BizTalk R2 to process the envelope and transaction sets of an EDIFACT encoded interchange received from the party. The following table describes these settings in detail:

EDIFACT  Interchange Processing Properties
Field Name	Field Type	Default Value	Purpose
UNB2.1	Text field	Blank	Used for party resolution*
UNB2.2	Drop down	<Not valued>	Used for party resolution*
UNB3.1	Text field	Blank	Used for party resolution*
UNB3.2	Drop down	<Not valued>	Used for party resolution*
Check for duplicate UNB5	Check box	Checked	To check for duplicate interchange received within a period of time based on UNB5. If received while the box is checked, the entire interchange is suspended and stored in wire (EDI) format
UNB6.1	Text field	Blank	Used for authentication**
UNB6.2	Text field	Blank	Used for authentication**
Check for duplicate UNG5	Check box	Unchecked	To check for duplicate groups within an interchange based on UNG5. If received while the box is checked, all the transaction sets in that group are suspended in XML format
Check for duplicate UNH1	Check box	Unchecked	To check for duplicate transaction sets within a group based on UNH1. If received while the box is checked, the offending transaction set is suspended in XML format
Default Target NameSpace	Editable Drop down	See footnote***	Used during schema discovery
Enable custom transaction sets	Grid	Blank	Used for custom transaction sets****

*UNB2.1, UNB2.2, UNB3.1 and UNB3.2 are used during Party Resolution. It is described in great detail here

**UNB6.1 and UNB6.2 are used during authentication. If these 2 fields are present in the instance and do not match the fields in PAM, the whole interchange is suspended. UNB6 is an optional composite field with mandatory UNB6.1 and optional UNB6.2. This means UNB6.2 is only present if UNB6.1 is present but UNB6.1 can be present without UNB6.2.

***Default is http://schemas.microsoft.com/BizTalk/EDI/EDIFACT/2006

****Users can override the default target namespace with custom namespace for certain Doc types. If UNH2.1, UNH2.2, UNH2.3, UNH2.5, UNG2.1 and UNG2.2 in the instance match the fields specified here, the target namespace from this row will be used. UNH2.5, UNG2.1 and UNG2.2 are optional so they can be left blank. Schema discovery is described in great detail here

ACK Generation and Validation Settings:

These settings are used by BizTalk R2 to generate acknowledgments in response to an EDIFACT encoded interchange received from a party, validate those interchanges and acknowledgments and to specifying the mode of processing by EDI Receive. The following table describes these settings in detail:

ACK Generation and Validation Settings
Field Name	Field Type	Default Value	Purpose
Route ACK  on request-response	Check box	Checked	To return the ACK generated by the EDI system on a 2 way request-response receive port
Generate Technical ACK	Check box	Unchecked	To generate Technical ACK against the incoming document
Do not batch Technical ACK	Check box	Unchecked, grayed out, dependent on* “Generate Technical ACK”	To include/exclude the Technical ACK in the batching set up for this party
Generate Functional ACK	Check box	Unchecked	To generate Functional ACK against the incoming document
Do not batch Functional ACK	Check box	Unchecked, grayed out, dependent on “Generate Functional ACK”	To include/exclude the Functional ACK in the batching set up for this party
UNH1	3 Text fields made up of Prefix + Numeric + Suffix	Blank for Prefix and Suffix fields, 1 for numeric**	To use this control number for the Functional ACK generated
Generate SG1/SG4 loop	Check box	Unchecked, grayed out, dependent on “Generate Functional ACK”	To generate the SG1/SG4 loop for accepted transaction sets for Functional ACK. This loop is only generated if there are errors in the transaction sets
EDI Type	Check box	Checked	To perform EDI Validation
Extended Validation	Check box	Unchecked, dependent on “EDI Type”	To perform extended validation
Allow leading and trailing zeroes and spaces	Check box	Unchecked, dependent on “EDI Type”	The EDI validation does not allow leading and trailing spaces and zeroes unless they are required to fulfill minlength requirements for a data type. If this is checked, EDI validation skips this leading and trailing check. This does not include ID data types
Allow trailing separators	Check box	Unchecked	When set to true, trailing delimiters at the segment, field and component level are allowed. If set to false and trailing delimiters encountered in the payload, that document is suspended
Create empty XML tags for trailing separators	Check box	Unchecked, grayed out, dependent on “Allow trailing separators”	To generate empty XML tags for data fields when trailing delimiters encountered
Mask security information	Check box	Checked	When checked, the security information in the context is masked with a special character. These include UNB6.1, UNB6.2 and UNG8 (if present in the instance)
Inbound processing mode	Drop down	Split Interchange as Transaction Sets	To specify the mode of interchange processing***

*dependent on means the field can only be edited if the dependent field is checked. For example the field “Do not Batch Technical ACK” will be grayed out if the field it is dependent on (”Generate Technical ACK”) is unchecked

** UNH1 is divided into three parts: Prefix, Number and Suffix. The control number is generated by concatenating these three fields. The prefix and suffix are constant and the numeric part is incremented on every successive Functional ACK generated. PAM validation ensures the total length of these fields do not exceed the maximum length allowed by the EDIFACT standards

***Explained in great detail under Engine Receive post

Party as Interchange Receiver:

The settings from Party as Interchange Receiver node are applied during Send Side processing. This node is subdivided as follows:

EDIFACT Interchange Envelope Generation:

These fields are used by BizTalk R2 to generate envelopes for an outgoing EDIFACT encoded interchange. For EDIFACT there are 3 pages that allows the users to specify settings for UNA, UNB and UNB/UNH segments.

The UNA segment page lets the users choose the settings for all the separators used in serialization. Since UNA segment is optional, there is a checkbox “Generate UNA segment” checked by default to allow users to generate UNA. If this field is not checked, UNA segment is not created but the delimiters specified are still used during serialization.

The UNB segment page lets the users choose the settings for the UNB envelope. UNB5 (interchange control number) is divided into three parts: Prefix, Number and Suffix. The control number is generated by concatenating these three fields. The prefix and suffix are constant and the numeric part is incremented on every successive serialization. PAM validation ensures the total length of these fields do not exceed the maximum length allowed by the EDIFACT standards.

The UNG/UNH segment page lets the users choose the settings for the UNG/UNH envelope. Since UNG segment is optional, there is a checkbox “Create UNG segments” unchecked by default. R2 allows users to specify different UNG headers for different Doc Types. If the ”Create UNG segments” field is checked, the UNG segment is generated according to the following process

• If the UNH2.1, UNH2.2, UNH2.3, UNH2.5 and the TargetNameSpace specified in PAM match the values in the instance, the UNG segment is constructed from that row
  • UNH2.1, UNH2.2, UNH2.3, UNH2.5 and the TargetNameSpace are present in the first line of XML file
• If no match happens, the default row is selected.
• If the default row is not specified by the user, the message is suspended and an appropriate error logged to the event viewer  

UNG5 (group control number) and UNH1 (transaction set control number) follow the same logic as UNB5. The UNH1 field has a checkbox “Apply new ID” that is checked by default. If this is checked, the transaction set control number is updated in the instance otherwise it remains as is.

ACK Processing and Validation Settings:

These fields are used by BizTalk R2 to process acknowledgments received from a party in response to an EDIFACT encoded interchange and to validate those interchanges and acknowledgments. The following table describes these settings in detail:

ACK Processing and Validation Settings
Field Name	Field Type	Default Value	Purpose
Functional ACK	Check box	Unchecked	Used by status reporting
EDI Type	Check box	Checked	To perform EDI Validation
Extended Validation	Check box	Unchecked, dependent on “EDI Type”	To perform extended validation
Allow leading and trailing zeroes and spaces	Check box	Unchecked, dependent on “EDI Type”	The EDI validation does not allow leading and trailing spaces and zeroes unless they are required to fulfill minlength requirements for a data type. If this is checked, EDI validation skips this leading and trailing check. This does not include ID data types
Generate trailing separators	Check box	Unchecked	To generate trailing separators at the segment, field and component level if empty XML tags are encountered

Interchange Batch Creation Settings:

These fields are used by BizTalk R2 to generate and send an EDIFACT encoded batch. This will be explained in a separate post in detail.

End Note:

I hope this post has been useful in understanding the EDIFACT Party Properties. Your comments/questions are always welcome.

Thanks

Mohsin Kalam