ISO/TS 20625:2002

TECHNICAL ISO/TS
SPECIFICATION 20625
First edition
2002-05-01
Electronic data interchange for
administration, commerce and transport
(EDIFACT) — Rules for generation of XML
scheme files (XSD) on the basis of
EDI(FACT) implementation guidelines
Échange de données informatisé pour l'administration, le commerce et le
transport (EDIFACT) — Règles pour la génération de fichiers de schéma
XML (XSD) basés sur les guides de mise en œuvre d'EDI(FACT)

Reference number
©
ISO 2002
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2002
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO 2002 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO
member bodies). The work of preparing International Standards is normally carried out through ISO technical
committees. Each member body interested in a subject for which a technical committee has been established has
the right to be represented on that committee. International organizations, governmental and non-governmental, in
liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical
Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
The main task of technical committees is to prepare International Standards. Draft International Standards adopted
by the technical committees are circulated to the member bodies for voting. Publication as an International
Standard requires approval by at least 75 % of the member bodies casting a vote.
In other circumstances, particularly when there is an urgent market requirement for such documents, a technical
committee may decide to publish other types of normative document:
 an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in an
ISO working group and is accepted for publication if it is approved by more than 50 % of the members of the
parent committee casting a vote;
 an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting a
vote.
An ISO/PAS or ISO/TS is reviewed after three years with a view to deciding whether it should be confirmed for a
further three years, revised to become an International Standard, or withdrawn. In the case of a confirmed ISO/PAS
or ISO/TS, it is reviewed again after six years at which time it has to be either transposed into an International
Standard or withdrawn.
Attention is drawn to the possibility that some of the elements of this Technical Specification may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/TS 20625 was prepared by DIN (as DIN 16557-5) and was adopted, under a special “fast-track procedure”, by
Technical Committee ISO/TC 154, Processes, data elements and documents in commerce, industry and
administration, in parallel with its approval by the ISO member bodies.
Annex A of this Technical Specification is for information only.

Introduction
Traditional EDI standards provide a syntax for the implementation of data content in various business processes
through the use of data elements, segments and message types. Initially XML provides simply another syntax,
which, if used to re-invent EDI, leads to huge new costs thus preventing any achievement of the initial goal - to get
small and medium sized enterprises (SME) involved in electronic business processes.
This standard describes how existing EDI know-how can be applied to the XML syntax. XML users would therefore
be able to easily use EDI data from existing applications in a consistent manner.
EDIFACT Message Implementation Guidelines (MIGs) describe the implementation of standardised EDIFACT
message types within a business process. Therefore MIGs are the suitable source for the derivation of XML
schemas. This standard specifies the process of translation.

iv © ISO 2002 – All rights reserved

TECHNICAL SPECIFICATION ISO/TS 20625:2002(E)

Electronic data interchange for administration, commerce and
transport (EDIFACT) — Rules for generation of XML scheme
files (XSD) on the basis of EDI(FACT) implementation
guidelines
1 Scope
This standard describes the rules for the derivation of XML schemas from EDI MIGs providing a sound
method of representing semantic facts.
This standard describes how to derive XML from UN/EDIFACT MIGs. In principle, the rules are equally
applicable to other EDI standards.
This standard does not apply to DTDs.
2 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions of this
Technical Specification. At the time of publication, the editions indicated were valid. All standards are subject
to revision, and parties to agreements based on this Technical Specification are encouraged to investigate
the possibility of applying the most recent editions of the standards indicated below. Members of IEC and
ISO maintain registers of currently valid International Standards.
ISO 8601:2000-12, Data elements and interchange formats — Information interchange — Representation of
dates and times.
ISO 9735-1:1998-10, Electronic data interchange for administration, commerce and transport (EDIFACT) –
Application level syntax rules (Syntax version number 4, Syntax release number: 1) – Part 1: Syntax rules
common to all parts.
3 Terms, symbols and abbreviations
For the purpose of this standard the following terms, symbols and abbreviations apply.
3.1
BSR
Basic Semantics Register
3.2
BSU
Basic Semantic Unit
3.3
DTD
Document Type Definition
3.4
EDI
Electronic Data Interchange
3.5
EDIFACT
Electronic Data Interchange for Administration, Commerce and Transport
3.6
ELEMENT
Syntactic building block containing data and/or attributes.
3.7
HTML
Hyper Text Mark-up Language
3.8
MIG
Message Implementation Guideline
3.9
NAME
A name in the context of XML starts with a letter or a permitted special character followed by letters,
numbers, hyphens, underlines, colons or points. All those are known as name tag. Names starting with "xml"
or with a character string which fits to (('X'|'x') ('M'|'m') ('L'|'l') are reserved for XML standardisation.
3.10
SGML
Standard Generalised Mark-up Language
3.11
Tag
Formatting instruction or semantic markup
3.12
Template
Predefined reference pattern compared with the complete entity to be recognised, or one of its parts.
3.13
XLL
Extensible Link Language
2 © ISO 2002 – All rights reserved

3.14
XML
Extensible Mark-up Language
3.15
XSD
Extensible Schema Definition
3.16
XSL
Extensible Stylesheet Language
3.17
W3C
World Wide Web Consortium
4 Typical contents of Message Implementation Guidelines
4.1 Level: MIG
a) Identification of MIG
b) Identification of the supporting EDIFACT directory
c) Identification of the message type and, if necessary, the industry subsets
d) Additional text
4.2 Level: Message Type
a) Structure of the message type (segments and segment groups) and indication of their portions used
b) Status (standard versus application) of the segments and segment groups in use
c) Context related names and descriptions of the segments and segment groups
d) Examples
e) Dependencies between segments and segment groups
f) Additional text, comments on message type level
4.3 Level: Segments and Composite Data Elements
a) Structure of the segments and composite data elements and indication of their portions used
b) Status (standard versus application) of the data elements and composite data elements
c) Dependencies between data elements and composite data elements within a segment and within the
message type
d) Context related names and descriptions
e) Examples
f) Additional text, comments
4.4 Level: Data element
a) Characteristics of EDI data elements (type, length) and their usage restrictions based upon MIG and
context related implementation
b) Context related names and descriptions of data elements and, if necessary, unique tags and
descriptions, e. g. derived from data repositories such as ISO-BSR (see ISO/TS 16668).
c) Examples
d) Additional text, comments
e) Allowed values
f) Constants
g) Explicitly given EDIFACT codes or ISO/UN code lists
h) Explicitly given user defined codes
i) Implicitly given EDIFACT codes or ISO/UN code lists
j) Implicitly given user defined or other codes not listed within the EDIFACT code directory
k) Rules to which data element values shall fit
l) Mapping to fields within applications and flat files, respectively
5 Requirements of derivation rules for schemas
a) The MIG technical information as listed in section 4 shall be incorporated into schemas as necessary.
b) The structure of the underlying MIG must be comprehensible (both the XML and traditional EDI guides
shall be compatible in structure).
c) The resulting XML messages should be as lean as possible.
d) One of the different variants by which semantic facts can be represented in XML is specified by this
standard as being mandatory.
e) The developer of a MIG decides which data is important and which structures are meaningful for his
application. By this, he decides which structure elements shall be incorporated into the schema.
6 Rules for the generation of XML schemas derived from EDI MIGs
NOTE The namespace ‘din’ in the examples of this section is for example purposes only and can either be omitted
or any other suitable namespace can be used.
6.1 Rule 1: Tag naming
6.1.1 Variant 1
The names of the XML structure will be derived from the EDI tags. They will be given a prefix depending on
the structure level (segment group, segment, composite data element or data element):
„M_“+ message type + [suffix]  Example: M_ORDERS
„G_“+ segment group + [suffix]  Example: G_SG36 or G_LIN_ALC
„S_“+ segment + [suffix]   Example: S_LIN
„C_“+ composite data element + [suffix] Example: C_C082_2
„D_“+ data element + [suffix]    Example: D_3035 or D_3035_10
The suffix is optional and can be generated based upon various semantic understanding of EDI elements.
4 © ISO 2002 – All rights reserved

If the XML schema file is being generated from an EDIFACT MIG only prefix "D_" would be necessary.
However, as the other prefixes have to be used by those EDI standards which identify composite data
elements and data elements by using numeric tags, they are mandatory.
The second notation of segment group tags can be used when the based EDI standard that is being
converted from provides no explicite segment groups or whenever the notation of the relevant trigger
segments is prefered. In this case the nesting of the segment groups has to be given as sequence of their
trigger segments.
The W3C XML recommendation requires ”self-explanatory tags“. EDI[FACT] tags fulfil this condition better
than tags in natural language, because they represent an established Lingua Franca for EDI specialists.
Example:














6.1.2 Variant 2
From suitable comments ”speaking" tags can be generated if desired. If using "speaking" tags the EDI origin
of the corresponding element shall be documented by an appropriate attribute value (see also section 6.9) or
with other means of documentation.
Example:









maxOccurs="10"/>




...




fixed="ORDERS.SG2.NAD.C080.3036(0120:040:01)"/>





6.2 Rule 2: Structure
6.2.1 The same EDI tags or names will produce aggregate elements (see also rule 6.10).
6.2.2 If a differenciation between different semantic occurencies of the same data container is desired,
different tags or names have to be assigned either by adding a suffix to the EDI tag or by using different
names.
6.2.3 The schema may contain further ‘stapling’ elements for groups of messages or the interchange itself
(comparable with UN/EDIFACT UNG-UNE and UNB-UNZ).
6.2.4 Any use of an EDI data container (message type, segment group, segment etc.) can be shown as an
independent XML element. The existing EDI structure is the source of the XML structure. Hence the XML
schema must have a structure compatible to the EDI MIG. The set of the generated XML elements is less
than or equal to the set of EDI elements.
NOTE The manner in which the author has written a MIG must have satisfied the needs of the respective business
process. Thus the schema must be structured accordingly. If for example the MIG contains "document date“ and
"requested delivery date“ in two separate occurrences of the DTM segment separate XML elements will be generated
accordingly. If those two have been documented within the same occurrence of the DTM segment, only one XML
element will be generated.
Examples for 6.2.1 and 6.2.2:
Variant 1:
The guide contains two DTM segments (see figure 1).

DTM (#1), Status M, Occurrence 1, Qualifier in DE 2005: 4, Name: Order date
DTM (#2), Status M, Occurrence 1, Qualifier in DE 2005: 2, Name: Requested
delivery date
Figure 1 — Message diagram of a guide containing two DTM segments

The default translation into an XML schema according 6.2.1 is as follows:



6 © ISO 2002 – All rights reserved








Type of date




Date/Time/Period


NOTE Element D_2005 is an enumeration type and contains the two possible values '2' and '4'.
Alternatively, application of rule 6.2.2 would result



Order date




Delivery date


or



Variant 2:
Guide implicitly documenting dates using only one DTM segment (see figure 2).

DTM, Status M, Occurrence 2, Qualifier in DE 2005: 2 and 4
Figure 2 — Message diagram of a guide containing only one DTM segment

The translation into an XML schema is analogue to the default example according to rule 6.2.1 as follows:










Type of date




Order date


Example for 6.2.3:










…
6.3 Rule 3: Structure optimisation
If flat XML structures are of primary interest, the application of the following rules will give an optimised
result. However, for integration in existing systems, one should bear in mind the minimum data structure
requirements established by the EDI system in use rather than the pure syntax requirements.
6.3.1 An EDIFACT segment that contains more than one data element with business data has actually a
summarising function. If the segment only contains one data element with business data there is no
summarising function on the segment level. Therefore in transformation towards XSD schema this segment
level can disappear.
6.3.2 Elements of the primary standard not being used in the MIG will be omitted.
6.3.3 Constant qualifiers or constant codes are not transferred into the XML structure (for a definite data
element only one code had been documented in the MIG). The corresponding data elements should not be
transferred into XML.
Example:
Derived from:







8 © ISO 2002 – All rights reserved














Order date


This rule generates:


Order date


The levels of segments and composite data elements are not required as they contain constant qualifiers
only. Therefore they are omitted.

6.4 Rule 4: Status
EDI status and application status within the MIG will be summarised in the XML status. The more restrictive
status will be kept.
The status “mandatory“ will be represented by a minimum repeating factor of "1", the status ”conditional“ by a
minimum repeating factor of "0". The status is given by the attribute minOccurs.

Examples:
Conditional:
Segment group 
Segment  
Composite data element
Data element  

Mandatory:
Segment group 
Segment  
Composite data element  
Data element  

6.5 Rule 5: Maximum occurrences
The number of occurrences of the MIG generates the XML occurrence. The value will be provided using the
XSD attribute maxOccurs.
Example:
Segment group 
Segment  
From EDIFACT syntax version 4 (ISO 9735-1) and the implementation of appropriate directories the
occurrence rule is applicable with composite data elements and data elements.

6.6 Rule 6: Data element formats
6.6.1 The representation ”an“ and ”a“ become „string“, ”n“ becomes „decimal“. For the lengths of
alphanumeric and numeric data elements as defined within the MIG appropriate simpleTypes will be
generated.
6.6.2 Date formats may be translated into XML data types "date", "timeInstant" and "time". In this case a
format conversion is required. The representation of these formats within XML is:
date :  1999-05-31 (according to ISO 8601)
time :  13:20:00
timeInstant: 1999-05-31T13:20:00

Example:






6.7 Rule 7: Code lists and user defined codes
6.7.1 Coded data elements will be defined as complexType. If for a data element only specific codes are
documented within the MIG, only these codes are allowed for the application. Thus only these codes are
transferred into the XML structure.
6.7.2 If the MIG does not provide codes for a data element, the whole available code list is allowed. This
whole code list will be transferred into the XML structure.
6.7.3 Repeatedly used code lists may be provided by using external files.
6.7.4 The code names will optionally be stored as annotation with the code.
6.7.5 According to rule 3 (see section 6.3) constant qualifiers or constant codes will not be transferred into
the XML structure (for a specific data element only one code had been documented within the MIG). The
respective data elements need not be provided within the XML structure. However, if the usage of a data
element is explicitly required, it has to be included within the XML structure (e. g. a currency using data
element 6345 in segment MOA).
10 © ISO 2002 – All rights reserved

Examples:
(1)





Deutsche Mark




Euro




Pfund Sterling




(2)









... etc. listing of the complete code list

(3)

xmlns:din="http://www.din.de/example/orders"
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">



Measure unit


...
External file with codes:

xmlns:din="http://www.din.de/ example/orders"
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">




……
(4)




Tonne (1000 kg) *




Kilogram *




Gram *




Dozen




(5)





Deutsche Mark




6.8 Rule 8: Names of EDI objects
6.8.1 Standardised or user defined names of segment groups, segments, composite date elements and
data elements may be provided as attribute "annotation" within the schema. Only one EDI name is permitted
as an attribute for any one XML element .
6.8.2 If there are both standard and user defined names for an EDI object only the user defined name
shall be kept.
NOTE The last sentence refers to the name of an object which may be found as user defined name, BSU or the like
within MIGs. In this way, the XML file remains lean and logical mapping is easily possible using a parser.
Examples:
(1)


Date/Time/Period


12 © ISO 2002 – All rights reserved


…

(2)


Order or delivery date



…

6.9 Rule 9: Mapping details
6.9.1 As far as the MIG contains mapping details, "anchor points" may be created as attributes. They shall
allow easy implementation of an XML exchange format within EDI sub-systems.
6.9.2 The EDI[FACT] source will be provided using the attribute "EDISource". This notation combines the
functionality of implementation documentation with the basic information of a directory release – for example
the EDIFACT directory.
The following rules apply:
 The path is indicated in the form of "segmentgroup.segment.compositedataelement.dataelement" or
"segmentgroup.segment.dataelement".
 The segment group may occur multiple to show the levels of the EDI[FACT] structure.
 In the case of multiple semantic variants of segment groups the qualifying segment, its qualifier and the
respective value of the qualifier should be given in square brackets.
At the end the sequence number of the segment as given in the original EDIFACT message type will be
added as well as the sequence number of the data element (composite data element or simple data element)
within the respective segment after a colon, and, if appropriate, also the sequence number of the component
data element within a composite data element.
For example, the notation (0120:020:02) shall be read as follows: "Sequence number of the segment in the
standard" : "sequence number of the composite data element or data element" : "if appropriate sequence
number of the component data element within the composite data element".
Examples:
(1)


BIC of buyer’s bank




value="BIC-BB"/>




(2)


BIC of buyer’s bank




value="SG2[NAD.3035=BY].FII.C088.3433(0140:030:01)"/>




6.10 Rule 10: Aggregation of equally named data container
If there are implementation scenarios with different message types and the user wants to aggregate equally
named data container and describe them unique within the scenario the following rules apply:
6.10.1 Structure
Aggregated data containers contain at least all those sub-elements which are used and documented within
the Message Implementation Guideline(s). The sequence of those elements must be compliant with the
sequence given in the EDI-Standard.
6.10.2 Status
In an aggregated data container the sub-element status shall be set to optional if this sub-element is used
once optionally within the data container in question in the whole message scenario.
Example: ORDERS DTM 2379 status: R, IFTMIN DTM 2379 status: O
ÆÆÆÆ XML status: O
6.10.3 Format
The format is being defined according to the widest used format specified in the Message Implementation
Guideline(s).
Example: ORDERS DTM 2380 format: n8, IFTMIN DTM 2380 format: an.35
ÆÆÆÆ XML format: string1.35
6.10.4 Code list
For each coded data element an aggregated code list shall be created that contains all codes applicable
according to the Message Implementation Guideline(s).
Example: ORDERS DTM 2380 code list: 102;103, IFTMIN DTM 2380 code list: 103;203
ÆÆÆÆ XML code list: 102;103;203

14 © ISO 2002 – All rights reserved

Annex A
(informative)
Example for mapping from EDIFACT to XML
NOTE For practical reasons the example given in this annex is based on German language speaking tags.
However, the use of other languages is not excluded. Status R means "required" and status O means "optional". Both
are application status information and have the same meaning as M(andatory) and C(onditional). Status N means "not
used".
A.1 EDIFACT based structure for the mapping
A.1.1 General
The basis for the XML structure to be generated is an implementation of the EDIFACT message type
ORDERS (Purchase order) with following details.
A.1.2 Message structure
A.1.2.1 Segment table
Table A.1 — Segment table of the based EDIFACT ORDERS
No. Tag St Rep Contents
01 UNH M 1 Message header
02 BGM M 1 Document type and number

03 DTM M 1 Order date
04 DTM M 1 Delivery date
SG2 R 1 Buyer
05 NAD M 1 Identification of the Buyer

06 FII O 1 Buyers bank account information

SG3 O 1 VAT-number of buyer
07 RFF M 1 VAT-number
SG5 O 1 Buyer's contact information

08 CTA M 1 Buyer's responsible employee

09 COM O 1 Phone number
10 COM O 1 Communication contact

SG2 R 1 Seller
11 NAD M 1 Identification of seller

SG7 O 1 Currency
12 CUX M 1 Order currency
SG25 R 10 Line Items
13 LIN M 1 Suppliers article number

14 IMD O 1 Short description of the product

15 QTY O 1 Ordered quantity
16 MOA O 1 Line item amount
SG27 O 1 Item price
17 PRI M 1 Price per item / unit

18 UNS M 1 Section control
19 MOA R 1 Total amount
20 UNT M 1 Message trailer
A.1.2.2 Message structure diagram
Figure A.1 — Message structure diagram (Branching Diagram) of the based EDIFACT ORDERS
16 © ISO 2002 – All rights reserved

A.1.3 Segment description
Segment: Seq. No.: 1 Level: 0 Message header
UNH
Status: M Max. Occ.: 1
Name: Message header
Description of segment:
EDIFACT Application
Tag Name St Format St Example Use / Comments
0062 Message reference number M an.14 M +1 Unique numberof the message assigned by sender.

S009 MESSAGE IDENTIFIER M M
0065 Message type identifier M an.6 M +ORDERS ORDERS = Orders message
0052 Message type version number M an.3 M :D D = Draft directory
0054 Message type release number M an.3 M :93A 93A = EDIFACT Directory Version 93A
0051 Controlling agency M an.2 M :UN' UN = UN/ECE/TRADE/WP.4, United Nations
Standard Messages (UNSM)
Comment:
This is the header segment of the message.
Example:
UNH+1+ORDERS:D:93A:UN'
Segment: Seq. No.: 2 Level: 0 Beginning of message
BGM
Status: M Max. Occ.: 1
Name: Document type and number
Description of segment:
EDIFACT Application
Tag Name St Format St Example Use / Comments

C002 DOCUMENT/MESSAGE NAME C R
1001 Document/message name, C an.3 R +220 220 = Order
coded
1004 Document/message number C an.35 R +1-96' Format an.8
Document number, assigned by sender
Order number
Comment:
Example:
BGM+220+1-96'
18 © ISO 2002 – All rights reserved

Segment: Seq. No.: 3 Level: 1 Date/time/period
DTM
Status: M Max. Occ.: 1
Name: Order date
Description of segment:
EDIFACT Application
Tag Name St Format St Example Use / Comments

C507 DATE/TIME/PERIOD M M
2005 Date/time/period qualifier M an.3 M +4 4 = Order date/time
2380 Date/time/period C an.35 R :19960101 Format n8
Order date
2379 Date/time/period format C an.3 R :102' 102 = JJJJMMTT
qualifier
Comment:
Example:
DTM+4:19960101:102'
Segment: Seq. No.: 4 Level: 1 Date/time/period
DTM
Status: M Max. Occ.: 1
Name: Delivery date
Description of segment:
EDIFACT Application
Tag Name St Format St Example Use / Comments

C507 DATE/TIME/PERIOD M M
2005 Date/time/period qualifier M an.3 M +2 2 = Delivery date/time, requested
2380 Date/time/period C an.35 R :19960110 Format n8
Delivery date
2379 Date/time/period format C an.3 R :102' 102 = CCYYMMDD
qualifier
Comment:
This segment is being used for the trasmission of delivery date requested.
Example:
DTM+2:19960110:102'
20 © ISO 2002 – All rights reserved

Group: SG2 Status: R Max. Occ.: 1 Buyer
In this instance of SG 2 information concerning the buyer will be transmitted.

Segment: Seq. No.: 5 Level: 1 Name and address
NAD
Status: M Max. Occ.: 1
Name: Identification of the Buyer
Description of segment:
EDIFACT Application
Tag Name St Format St Example Use / Comments
3035 Party qualifier M an.3 BY = Buyer
M +BY
C082 PARTY IDENTIFICATION C N
DETAILS
3039 Party id identification M an.17 N

C058 NAME AND ADDRESS C N
3124 Name and address line M an.35 N

C080 PARTY NAME C R
3036 Party name M an.35 +BONBON Format an.10
Buyer name
AG
C059 STREET C O
Buyer street
3042 Street and number/P.O. Box M an.35 M +SIRUPST
RASSE 15
3164 City name C an.35 Buyer city
O +ZUCKER
STADT
3229 Country sub-entity identification C an.9 N
3251 Postcode identification C an.9 O +55555' Format n5
Buyer postcode
Comment:
Example:
NAD+BY+++BONBON AG+SIRUPSTRASSE 15+ZUCKERSTADT++55555'

Group: SG2 Status: R Max. Occ.: 1 Buyer
In this instance of SG 2 information concerning the buyer will be transmitted.

Segment: Seq. No.: 6 Level: 2 Financial institution information
FII
Status: O Max. Occ.: 1
Name: Buyers bank account information
Description of segment:
EDIFACT Application
Tag Name St Format St Example Use / Comments
3035 Party qualifier M an.3 BB = Buyer's bank
M +BB
C078 ACCOUNT IDENTIFICATION C R
Account holder number
3194 C an.17 R +12365478 Format n10
90 Buyer account number
Account number of buyer. According to German law
anonymous accounts are forbidden.
Account holder name
3192 C an.35 R :BONBON Format an.10
AG Account holder. To prevent any legal problems the name of
account holder has to be transmitted.

C088 INSTITUTION IDENTIFICATION C R
3433 Institution name identification C an.11 R +10090045 Format n8
Buyer BIC
Code list qualifier 25 = Bank identification
1131 C an.3 R :25
3055 Code list responsible agency, C an.3 R :131 131 = German bankers association
coded
3434 Institution branch number C an.17 O :262 This element can be used for specification of the financial
institutions branch number.
1131 Code list qualifier C an.3 N

3055 Code list responsible agency, C an.3 N
coded
Institution name Buyer bank name
3432 C an.70 O :SBANK'
Contains the name of buyer's bank.
Comment:
This segment is being used for transmission of buyer's bank and account number.
Example:
FII+BB+1236547890:BONBON AG+10090045:25:131:262:::SBANK'

22 © ISO 2002 – All rights reserved

Group: SG2 Status: R Max. Occ.: 1 Buyer
In this instance of SG 2 information concerning the buyer will be transmitted.

Group: SG3 Status: O Max. Occ.: 1 VAT-number of buyer

Segment: Seq. No.: 7 Level: 2 Reference
RFF
Status: M Max. Occ.: 1
Name: VAT-number
Description of segment:
EDIFACT Application
Tag Name St Format St Example Use / Comments

C506 REFERENCE M M
1153 Reference qualifier M an.3 M +VA VA = VAT registration number
Reference number Buyer VAT ID number
1154 C an.35 R :
DE998887
7'
Comment:
Example:
RFF+VA:DE9988877'
Group: SG2 Status: R Max. Occ.: 1 Buyer
In this instance of SG 2 information concerning the buyer will be transmitted.

Group: SG5 Status: O Max. Occ.: 1 Buyer's contact information

Segment: Seq. No.: 8 Level: 2 Contact information
CTA
Status: M Max. Occ.: 1
Name: Buyer's responsible employee
Description of segment:
EDIFACT Application
Tag Name St Format St Example Use / Comments
3139 Contact function, coded C an.3 IC = Information contact
R +IC
C056 DEPARTMENT OR EMPLOYEE C O
DETAILS
3413 Department or employee C an.17 O +Bart Format an.15
identification Buyer contact
Simpson'
Comment:
Example:
CTA+IC+Bart Simpson'
24 © ISO 2002 – All rights reserved

Group: SG2 Status: R Max. Occ.: 1 Buyer
In this instance of SG 2 information concerning the buyer will be transmitted.

Group: SG5 Status: O Max. Occ.: 1 Buyer's contact information

Segment: Seq. No.: 9 Level: 3 Communication contact
COM
Status: O Max. Occ.: 1
Name: Phone number
Description of segment:
EDIFACT Application
Tag Name St Format St Example Use / Comments

C076 COMMUNICATION CONTACT M M
3148 Communication number M an.25 M +05368- Format an.12
22347 Buyer phone number
3155 Communication channel M an.3 M :TE' TE = Telephone
qualifier
Comment:
Example:
COM+05368-22347:TE'
Group: SG2 Status: R Max. Occ.: 1 Buyer
In this instance of SG 2 information concerning the buyer will be transmitted.

Group: SG5 Status: O Max. Occ.: 1 Buyer's contact information

Segment: Seq. No.: 10 Level: 3 Communication contact
COM
Status: O Max. Occ.: 1
Name: Communication contact
Description of segment:
EDIFACT Application
Tag Name St Format St Example Use / Comments

C076 COMMUNICATION CONTACT M M
3148 Communication number M an.25 M +05368- Format an.12
22555 Buyer fax number
3155 Communication channel M an.3 M :FX' FX = Telefax
qualifier
Comment:
Example:
COM+05368-22555:FX'
26 © ISO 2002 – All rights reserved

Group: SG2 Status: R Max. Occ.: 1 Seller
In this instance of SG 2 information concerning the seller will be transmitted.

Segment: Seq. No.: 11 Level: 1 Name and address
NAD
Status: M Max. Occ.: 1
Name: Identification of seller
Description of segment:
EDIFACT Application
Tag Name St Format St Example Use / Comments
3035 Party qualifier M an.3 SE = Seller
M +SE
...