ANNEX D

(Informative)

Paper rendition from an EDIFACT coded message

D.1 Why performing paper renditions from EDIFACT coded messages?

During trade procedures it is necessary in many cases to perform paper renditions from EDIFACT coded messages; today any rendition is carried out in a non-standardized mode based on the application format of the company.

In EDI schemes many users do not have EDI software; the paper rendition is the solution for them to be included in these EDI global schemes.

The definition of a standardized paper rendition method is the way to integrate easily EDI with paper formats.

The main objective is the facilitation of trade procedures : paper rendition for applications of the end users and for the VANs; to reach trade partners who have no EDI software; integration of EDIFACT format to paper formats and office document environment (FAX, Physical Delivery Service, ODA, SGML,....); (Standardized) labels on packages.

The second objective is the consistency with recommendations.

The UN/WP4 defined the UNLK (ISO 6422). But the UNLK has never been integrated in the UNTDID.

In the definition of the Standard Message INVOIC of the UNTDID, an example shows the rendition on the UN Layout Key. However, EDIFACT recommendations do not define any rule for the paper rendition.

In the UNTDED the definition of the Data Element contains the positioning values on the paper sheet.

Other objectives deal with security and legal aspects : when the network is not available, the paper rendition is a possible solution; paper is used as a proof (E.g. demand from the DGI in France).

The following document, named "Paper rendition from an EDIFACT coded message", shows a basic method to perform the paper rendition. This method fits in with the EDIFACT rules (the defined logical structure of the paper document is the same as the logical structure of the EDIFACT message).

This document can be integrated in the MIG as a recommended method.

D.2 Paper rendition from an EDIFACT coded message

D.2.1 Working documents

D.2.2 Introduction

The subject of this document is the study of the paper rendition from a message coded with the EDIFACT standard.

The EDIFACT data will be restored such that the data are filled in a pre-printed form.

The key ideas of this study are as follows :

The logical structure of the paper document will be the same as the logical structure of the EDIFACT message. It means that, considering the paper rendition, the notions of interdependent data, segments and nesting segments are the same as in the description of the EDIFACT message. With this approach, we avoid defining a specific paper rendition application, for which the rules would be different than the EDIFACT rules.

D.2.3 Definitions

D.2.3.1 Page background

A page background contains areas, frames, labels.

A page background is made with equal sized elementary rectangles. The dimensions of an elementary rectangle are : Height = 1 line; Length = 1 column. See for instance the form design sheet defined in ISO 3535.

On a page background a Point is positioned using the pair (L, C) (line number, column number).

An Area is a rectangle defined using a Point (named Origin) and a size (H, Lg) in which H is the number of lines and Lg is the number of columns. An Area is typically represented as follows: A Frame may delimit one or several Areas.

D.2.3.2 EDIFACT data

With all EDIFACT data (simple data element, composite data element, segment, group of segments) we introduce the notion of Data Field. A Data Field is a rectangle defined with a size (H, Lg) (H = number of lines; Lg = number of columns), which corresponds to the maximum dimensions of the data.

In the case of repeated data, the Data Field defines the dimensions of one occurrence of the data.

The Data Field is related with EDIFACT data, the Area is related to the paper sheet.

D.2.4 Rendition rules of the EDIFACT data

Note : In this paragraph, the word "data" can mean indistinctly "an elementary data element", "a composite data element", "a segment" or "a group of segments".

Each EDIFACT data is written on the paper sheet in the Area reserved for it. It is now necessary to define the rendition rules.

D.2.4.1 Basic rules

Rule 1
A data is to be restored or not.

D.2.4.2 Rules for positioning

Rule 2
The data is positioned relatively to the paper sheet (absolute positioning) or relatively to another data (relative positioning).

Rule 3
In the case of an absolute positioned data, the Origin of the data is defined by the pair (Line, Column (L,C)) relatively to the top left corner of the paper sheet.

Rule 4
In the case of a relative positioned data, the Origin of the data is defined by the pair (Line, Column (L,C)) relatively to the Origin of another data.

Rule 5
In the case of a repeated data, from the second occurrence the positioning of the data is relative to the previous occurrence.

Rule 6
In the case of a relative positioned data, the reference data is either explicitly provided or is a default data.

Rule 7
When the reference data is not provided, the positioning of the data is relative to the previous data written on the paper sheet.

Rule 8
In the case of a relative positioning and of a default reference data (case of "repeated data" and case of "positioned data relatively to previous data"), the rendition direction must be explicitly given : either Downwards or to the Right.

D.2.4.3 Rules for dimensioning

Rule 9
A data has a Data Field, which is a rectangle (defined using H,Lg) with maximum dimensions. H is the maximum number of lines of the data and Lg is the maximum number of columns of the data.

Rule 10
The size (defined using H,Lg) of the Area corresponds to the maximum size of the paper space allocated to the data. This size takes into account the possible repetitions of the data.

Rule 11
In order to avoid the overlapping of data, no data will overflow the Area allocated to it.

D.2.4.4 Rules for Code Lists and Qualifiers

Rule 12
In the case of a coded data of a Code List, the actual meaning of the value may be restored.

Rule 13
In the case of a qualifier, for each value of the qualifier we have specific rendition values (e.g. : the segment [NAD qualified by BY] and the segment [NAD qualified by SU] have different absolute positioning).

D.2.4.5 Rules for multiple page documents

Rule 14
For some data it is possible to require a new page when the Area defined on the page is to small. For instance such is the case for the following data : LINE ITEM, Conditional, Number of repetitions = 999.

Rule 15
In the case of a message restored on multiple pages, the Heading Section is restored on each page.

Rule 16
In the case of a message restored on multiple pages, the Summary Section is restored only on the last page.

Rule 17
In the case of a message restored on multiple pages, the paper document will necessarily be paginated.

D.2.5 Setting of parameter attributes

Some of the rules are very general and are used without parameters.

For instance. : "In the case of a repeated data, from the second occurrence the positioning of the data is relative to the previous occurrence".

For other data a list of parameters must be used.

For instance. : in the case of a relative positioned data, the following parameters must be used : "reference data", "positioning value for the line", "positioning value for the column".

In order to store these parameter values, we define a list of attributes attached to each data type.

The attribute values are stored in the message directories (Simple data element directory, Composite data element directory, Segment directory, Message structure).

List of attributes :

D.2.6 Information on how to use the attributes

At each node of the structure message, depending on the data type and the context of the data use in the message structure, we use either the entire set of the attributes listed previously or a subset of these.

The lists of the attributes are correctly defined for the Simple data elements, the Composite data elements and the Segments (the corresponding lists are given below).

On the contrary, in order to set parameters to a a message it is impossible to give a standard attribute list at each node of the message structure. For example, each of the following cases could be set parameter in different ways depending on the context :

D.2.6.1 Simple Data Element

Attributes :

D.2.6.2 Composite Data Element

Note : The attributes H and Lg of the attribute "Data Field size" may be defined by syntactic rules.

Attributes :

Each simple Constitutive Data Element has the following attributes :