Directory   Messages   Segments   Composites   Data elements   Codes Meaning of the change indicators
  UN/EDIFACT  D.03A (Batch) Syntax version 3 Issue date 2003-06-23  
  Message type specification IMPDEF
 
 
IMPDEF 2 EDI implementation guide definition message  
  Date:
2003-06-10

Source:
TBG16 Entry Point

0. INTRODUCTION
This specification provides the definition of the EDI implementation guide definition message (IMPDEF) to be used in Electronic Data Interchange (EDI) between trading partners involved in administration, commerce and transport.

1. SCOPE

1.1 Functional definition
The EDI implementation guideline definition message (IMPDEF) permits the exchange of implementation details of an EDI message, including its usage and its presentation.

1.2 Field of application
The EDI implementation guide definition message may be used for both national and international applications. It is based on universal practice related to administration, commerce and transport, and is not dependent on the type of business or industry.

1.3 Principles
The IMPDEF message provides an EDI mechanism for describing the contents of a specific Message Implementation Guideline (MIG) or Implementation Convention (IC) for an EDI message that is capable of being specified in the Directory Definition message (DIRDEF). One occurrence of the message shall contain only one MIG. An IMPDEF message for the message being implemented may contain:

a. the specification of the implementation usage
b. additional implementation guidance
c. presentation and processing guidance

The IMPDEF message shall describe usage of all necessary components (segment groups, segments, composite data elements, simple data elements and code values) from an identified source message, together with additional components (non-coded data values or ranges), to effect an implementation of the target message.

The IMPDEF message may describe those components which are not used. By default, those components of the source message which are not referenced, are not used in the implementation.

The IMPDEF message shall identify the source message upon which it is based. This identification may reference the source message contained either in a standard directory or in a separate DIRDEF message.

The IMPDEF message shall contain a complete MIG or IC and it shall not be used for update or maintenance purposes.

The hierarchical nature of both the source and target message structure must be preserved in the IMPDEF message. For example, this means that segment group information must be located immediately after the segment context of the trigger segment is established. Similarly, constituent element information must immediately follow the establishment of a segment or composite context, as must coded or non-coded values their element context.

The main body of the MIG is carried by repeated instances of the DFN loop. This loop can be used to encapsulate blocks of components and place them in any given prevailing context. It can also be used to define aliases or constraint blocks. In ordinary use, the DFN segment acts as a device to allow the logic flow to cycle through the optional segment groups inside the DFN-triggered segment group in the correct order to follow the hierarchical message structure. The segment groups within the DFN-triggered segment group are ordered so as to minimise the number of repeats within ordinary use.

The IMPDEF message maintains a context through the use of the segment groups within the DFN-triggered segment group. The DFN segment provides a means to redefine or re-establish the current context. The segment group that follows the DFN segment (and its associated FTX segment[s]) determines which context is being changed. For example, in normal message hierarchy sequence, codes are defined for elements within segments. To revert back to the segment context, a DFN segment would be followed by an ELU segment; similarly, to change the segment context, a DFN segment would be followed by an SGU segment.
However, components such as repeats, references or relationships are considered to be applied in the context at which they are defined. Thus repeats, references, relationships or data representations may be applied to the whole message, individual segments, elements or composites.

When the DFN is used to perform encapsulation, the current context is considered to be stacked upon entry, inherited within, and restored upon exit. However, any encapsulated block may establish its own context at any time, either retaining or discarding any or all of the inherited context. Upon exit, the previous context is re-established, but may be immediately modified, in whole or part, by the components that follow the closing DFN segment.

The ordering of the components is governed by the source message hierarchy. Whilst the components at any particular level may be carried in any order, the message hierarchy must be maintained. This means that usage requirements of data elements within a segment must follow the usage requirements of that segment, but may themselves be presented in any order.
Similarly, usage requirements of individual segments within a segment group must follow the trigger segment and the group definition and be presented together, but in any order.

Where constraints are used, and a constraint is active either because the constraint expression at the start of the constraint is true or because the implicit context of the constraint definition is active, then the usage specifications inside the constraint block shall prevail against those which would apply were the constraint not active. For example, if a segment is implicitly 'Not Used' by not being mentioned in the main body of the MIG or IC, but is explicitly tagged as 'Required' within an active constraint, then the prevailing usage shall be 'Required'. Conversely, if a segment is explicitly used in the main body of the MIG or IC, and also explicitly tagged as 'Not Used' within an active constraint then the prevailing usage shall be 'Not Used'.

The Interchange header shall specify character set level C.

2. REFERENCES
See UNTDID, Part 4, Chapter 2.3 UN/ECE UNSM - General Introduction, Section 1.

3. TERMS AND DEFINITIONS

3.1 Standard terms and definitions
See UNTDID, Part 4, Chapter 2.3 UN/ECE UNSM - General Introduction, Section 2.

3.2 Message terms and definitions
The following additional definitions are for constituent parts of a message whose implementation is being described within an IMPDEF message:

Alias: this is used to describe a group of components collected together and named for frequent or repetitive use.

Component: this is used in a generic sense to apply to any item which may be a part of, or referenced by a part of a MIG. Thus it may refer to a segment, a segment group, a simple or composite element, a code list or individual code or non-coded value. It may also refer to structures such as an alias or a constraint within a MIG.

Constraint: this is used to describe a group of components with either an explicit or implicit constraint expression, which may be named for error reporting and context determination.

Source Message: this is used to refer to the original message specification as published in the relevant standard by the responsible authority.

Target Message: this is used to refer to the resultant message specification produced by applying the restrictions, clarifications and constraints contained within the MIG to the Source Message.

4. MESSAGE DEFINITION

4.1 Data segment clarification
This section should be read in conjunction with the segment table which indicates mandatory, conditional and repeating requirements.
 
  Generated by GEFEG.FX  
  http://www.gefeg.com