Electronic invoicing - Part 3-4: Syntax binding for UN/EDIFACT INVOIC D16B

This CEN Technical Specification (TS) contains the mapping between the semantic data model of an electronic invoice (EN 16931-1) and the following syntax: UN/EDIFACT INVOIC D16B. For each element in the semantic model (including sub-elements or supplementary componentts sucha as Code List identifiers) it is defined which element in the syntax is to be used to contain its information contents. Any mismatches between semantics, format, cardinality or structure are indicated. Any rules to be followed when using the specific syntax are stated informally in this TS. Together with this TS a set of validation artefacts is published, including formalisation of the rules.

Elektronische Rechnungsstellung - Teil 3-4: Umsetzung in die Syntax UN/EDIFACT INVOIC D16B

Facturation électronique - Partie 3-4 : Correspondance syntaxique pour les factures - Schéma D16B UN/EDIFACT

Elektronsko izdajanje računov - 3-4. del: Sintaksa povezav v skladu z UN/EDIFACT INVOIC D16B

Ta tehnična specifikacija CEN (TS) vsebuje preslikavo med semantičnim podatkovnim modelom elektronskega računa (EN 16931-1) in naslednjo sintakso: UN/EDIFACT INVOIC D16B. Za vsak element semantičnega modela (vključno s podelementi ali dodatnimi komponentami, kot so oznake elementov kodnega seznama) je opredeljen element sintakse, ki vsebuje informacije določenega elementa semantičnega modela. Kakršnakoli neskladja med semantiko, formatom, kardinalnostjo ali strukturo so navedena. Vsa pravila, ki jih je treba upoštevati pri uporabi posamezne sintakse, so neformalno navedena v tej tehnični specifikaciji. Skupaj s to tehnično specifikacijo je objavljen sklop artefaktov za potrjevanje, vključno s formalizacijo pravil.

General Information

Status
Withdrawn
Publication Date
17-Dec-2017
Withdrawal Date
14-May-2020
Technical Committee
Current Stage
9900 - Withdrawal (Adopted Project)
Start Date
14-May-2020
Due Date
06-Jun-2020
Completion Date
15-May-2020

RELATIONS

Buy Standard

Technical specification
SIST-TS CEN/TS 16931-3-4:2018
English language
221 pages
sale 10% off
Preview
sale 10% off
Preview

e-Library read for
1 day

Standards Content (sample)

SLOVENSKI STANDARD
SIST-TS CEN/TS 16931-3-4:2018
01-januar-2018

(OHNWURQVNRL]GDMDQMHUDþXQRYGHO6LQWDNVDSRYH]DYYVNODGX]81(',)$&7

,192,&'%
Electronic invoicing - Part 3-4: Syntax binding for UN/EDIFACT INVOIC D16B
Elektronische Rechnungsstellung - Teil 3-4: Umsetzung in die Syntax UN/EDIFACT
INVOIC D16B

Facturation électronique - Partie 3-4 : Correspondance syntaxique pour les factures -

Schéma D16B UN/EDIFACT
Ta slovenski standard je istoveten z: CEN/TS 16931-3-4:2017
ICS:
35.240.63 Uporabniške rešitve IT v IT applications in trade
trgovini
SIST-TS CEN/TS 16931-3-4:2018 en,fr,de

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
SIST-TS CEN/TS 16931-3-4:2018
---------------------- Page: 2 ----------------------
SIST-TS CEN/TS 16931-3-4:2018
CEN/TS 16931-3-4
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
October 2017
TECHNISCHE SPEZIFIKATION
ICS 35.240.20; 35.240.63
English Version
Electronic invoicing - Part 3-4: Syntax binding for
UN/EDIFACT INVOIC D16B

Facturation électronique - Partie 3-4 : Correspondance Elektronische Rechnungsstellung - Teil 3-4: Umsetzung

syntaxique pour les factures - Schéma D16B in die Syntax UN/EDIFACT INVOIC D16B
UN/EDIFACT

This Technical Specification (CEN/TS) was approved by CEN on 30 July 2017 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to

submit their comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS

available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in

parallel to the CEN/TS) until the final decision about the possible conversion of the CEN/TS into an EN is reached.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,

Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,

Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,

Turkey and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels

© 2017 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 16931-3-4:2017 E

worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
SIST-TS CEN/TS 16931-3-4:2018
CEN/TS 16931-3-4:2017 (E)
Contents
Page

European foreword ....................................................................................................................................................... 3

Introduction .................................................................................................................................................................... 4

1 Scope .................................................................................................................................................................... 5

2 Normative references .................................................................................................................................... 5

3 Terms and definitions ................................................................................................................................... 5

4 Syntax binding to UN/EDIFACT .................................................................................................................. 6

4.1 Introduction ...................................................................................................................................................... 6

4.2 Data types .......................................................................................................................................................... 6

4.3 Codes and identifiers .................................................................................................................................. 10

4.4 Mapping the Invoice model ...................................................................................................................... 10

4.5 Validation artefacts ................................................................................................................................... 140

5 Mismatches ................................................................................................................................................... 140

5.1 Semantic level .............................................................................................................................................. 140

5.2 Structural level ............................................................................................................................................ 140

5.3 Cardinality level .......................................................................................................................................... 140

Annex A (informative) Examples ....................................................................................................................... 141

A.1 Introduction ................................................................................................................................................. 141

A.2 Invoice with multiple line items ........................................................................................................... 141

A.3 IT equipment ............................................................................................................................................... 156

A.4 Subscription ................................................................................................................................................. 172

A.5 Domestic payment ..................................................................................................................................... 176

A.6 Maximum content ...................................................................................................................................... 181

A.7 Minimum content ....................................................................................................................................... 192

A.8 Taxes ............................................................................................................................................................... 197

A.9 Electricity ...................................................................................................................................................... 201

A.10 Licenses.......................................................................................................................................................... 216

Bibliography ............................................................................................................................................................... 221

---------------------- Page: 4 ----------------------
SIST-TS CEN/TS 16931-3-4:2018
CEN/TS 16931-3-4:2017 (E)
European foreword

This document (CEN/TS 16931-3-4:2017) has been prepared by Technical Committee CEN/TC 434

“Electronic invoicing”, the secretariat of which is held by NEN.

Attention is drawn to the possibility that some of the elements of this document may be the subject of

patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent

rights.

This document has been prepared under a mandate given to CEN by the European Commission and the

European Free Trade Association, and supports essential requirements of EU Directive 2014/55/EU.

This document is part of a set of documents, consisting of:

— EN 16931-1:2017 Electronic invoicing - Part 1: Semantic data model of the core elements of an

electronic invoice

— CEN/TS 16931-2:2017 Electronic invoicing - Part 2: List of syntaxes that comply with EN 16931-1

— CEN/TS 16931-3-1:2017 Electronic invoicing - Part 3 - 1: Methodology for syntax bindings of the

core elements of an electronic invoice

— CEN/TS 16931-3-2:2017 Electronic invoicing - Part 3 - 2: Syntax binding for ISO/IEC 19845

(UBL 2.1) invoice and credit note

— CEN/TS 16931-3-3:2017 Electronic invoicing - Part 3 - 3: Syntax binding for UN/CEFACT XML

Cross Industry Invoice D16B

— CEN/TS 16931-3-4:2017 Electronic invoicing - Part 3 - 4: Syntax binding for UN/EDIFACT

INVOIC D16B

— CEN/TR 16931-4:2017 Electronic invoicing - Part 4: Guidelines on interoperability of electronic

invoices at the transmission level

— CEN/TR 16931-5:2017 Electronic invoicing - Part 5: Guidelines on the use of sector or country

extensions in conjunction with EN 16931-1, including a methodology to be applied in the real

environment

— CEN/TR 16931-6:2017 Electronic invoicing - Part 6: Result of the test of the European standard

with respect to its practical application for an end user - Testing methodology

According to the CEN/CENELEC Internal Regulations, the national standards organisations of the

following countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria,

Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia,

France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,

Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,

Turkey and the United Kingdom.
---------------------- Page: 5 ----------------------
SIST-TS CEN/TS 16931-3-4:2018
CEN/TS 16931-3-4:2017 (E)
Introduction

The European Commission estimates that “The mass adoption of e-invoicing within the EU would lead

to significant economic benefits and it is estimated that moving from paper to e-invoices will generate

savings of around EUR 240 billion over a six-year period” . Based on this recognition “The Commission

wants to see e-invoicing become the predominant method of invoicing by 2020 in Europe.”

As a means to achieve this goal, Directive 2014/55/EU [5] on electronic invoicing in public

procurement aims at facilitating the use of electronic invoices by economic operators when supplying

goods, works and services to the public administration (B2G), as well as the support for trading

between economic operators themselves (B2B). In particular, it sets out the legal framework for the

establishment and adoption of a European standard (EN) for the semantic data model of the core

elements of an electronic invoice (EN 16931-1).

In line with Directive 2014/55/EU [5], and after publication of the reference to EN 16931-1 in the

Oficial Journal of the European Union, all contracting public authorities and contracting entities in the

EU will be obliged to receive and process an e-invoice as long as:
— it is in conformance with the semantic content as described in EN 16931:1;

— it is represented in any of the syntaxes identified in CEN/TS 16931-2, in accordance with the

request referred to in paragraph 1 of article 3 of the Directive 2014/55/EU;

— it is in conformance with the appropriate mapping defined in the applicable subpart of

CEN/TS 16931-3.

The semantic data model of the core elements of an electronic invoice – the core invoice model – as

described in EN 16931-1 is based on the proposition that a limited, but sufficient set of information

elements can be defined that supports generally applicable invoice-related functionalities.

This CEN Technical Specification CEN/TS 16931-3-4 defines the binding of the core elements of the

invoice to the ISO/IEC 9735 syntax (UN/EDIFACT). Other subparts of this CEN Technical Specifications

define the binding method (CEN/TS 16931-3-1) and map the core invoice model to other syntaxes such

as ISO/IEC 19845 (UBL 2.1) (CEN/TS 16931-3-2) and the Cross Industry Invoice of UN/CEFACT XML

(CEN/TS 16931-3-3).

By ensuring interoperability of electronic invoices, the European standard and its ancillary European

standardization deliverables will serve to remove market barriers and obstacles to trade deriving from

the existence of different national rules and standards – and thus contribute to the goals set by the

European Commission
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2010:0712:FIN:en:PDF.
---------------------- Page: 6 ----------------------
SIST-TS CEN/TS 16931-3-4:2018
CEN/TS 16931-3-4:2017 (E)
1 Scope

This CEN Technical Specification (TS) specifies the mapping between the semantic model of an

electronic invoice, included in EN 16931-1 and the ISO/IEC 9735 (UN/EDIFACT) syntax. For each

element in the semantic model (including sub-elements or supplementary components such as

Identification scheme identifiers) it is defined which element in the syntax is to be used to contain its

information contents. Any mismatches between semantics, format, cardinality or structure are

indicated.
2 Normative references

The following documents, in whole or in part, are normatively referenced in this document and are

indispensable for its application. For dated references, only the edition cited applies. For undated

references, the latest edition of the referenced document (including any amendments) applies.

ISO/IEC 9735, Electronic data interchange for administration, commerce and transport (EDIFACT) –

Application level syntax rules

EN 16931-1, Electronic invoicing - Semantic data model of the core elements of an electronic invoice

3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
electronic invoice

invoice that has been issued, transmitted and received in a structured electronic format which allows

for its automatic and electronic processing
[SOURCE: Directive 2014/55/EU [5]]
3.2
semantic data model
structured set of logically interrelated information elements
3.3
information element

semantic concept that can be defined independent of any particular representation in a syntax

3.4
syntax

the machine-readable language or dialect used to represent the information elements contained in an

electronic document (e.g. an electronic invoice)
3.5
business term

the label assigned to a given information element which is used as a primary reference

3.6
core invoice model
semantic data model of the Core elements of an electronic invoice
---------------------- Page: 7 ----------------------
SIST-TS CEN/TS 16931-3-4:2018
CEN/TS 16931-3-4:2017 (E)
3.7
core elements of an electronic invoice

set of essential information elements that an electronic invoice may contain in order to enable cross-

border interoperability, including the necessary information to ensure legal compliance

3.8
identifier

character string used to establish the identity of, and distinguish uniquely, one instance of an object

within an identification scheme from all other objects within the same scheme

Note 1 to entry: An identifier may be a word, number, letter, symbol, or any combination of those

3.9
identification scheme

collection of identifiers applicable for a given type of object governed under a common set of rules

4 Syntax binding to UN/EDIFACT
4.1 Introduction

UN/EDIFACT (ISO 9735) is a syntax for electronic data interchange for administration, commerce and

transport. UN/EDIFACT constructs are character strings in which the content of data elements is

separated by tags and delimiters. UN/EDIFACT has a hierarchical structure where the top level is

referred to as an interchange, and lower levels contain multiple messages which consist of segments,

which in turn consist of composites. The final iteration is an element which is derived from the United

Nations Trade Data Element Directory (UNTDED); these are normalized throughout the UN/EDIFACT

standard .

The United Nations Economic Commission for Europe (UNECE), since the 1980s supported a number

projects to enable trade based on electronic messaging – UN/CEFACT and specific Recommendations

In UN/CEFACT, standard messages using the UN/EDIFACT syntax (ISO 9735) were developed by

various working groups across the globe to facilitate administration, commerce and transport. These

messages mimicked standard paper documents used in everyday business transactions and were called

United Nations Standard Message types (UNSMs). Today these UNSMs are the most widely used e-

messages across the globe. UNSMs are built using the United Nations Trade Data Elements Directory

(UNTDED) with reusable elements, code sets, standard composites and segments which can be

configured to meet the function of a particular message such as an Invoice.

In the IT UNECE Trade Facilitation process, formal guidance is provided by publishing

Recommendations. These Recommendations cover a wide variety of topics but some are specific to

electronic messaging.

For more information please refer to http://www.unece.org/cefact/EDIFACT/welcome.html

4.2 Data types

XML based syntaxes have explicit semantic meanings included in the naming of the element (e.g.

DueDate) and associate a specific data type to it (e.g. xs:DateTime). UN/EDIFACT does it the other way

around. Having a set of clearly defined data types (e.g DTM for any kind of date or time information) the

semantic meaning is added through a qualifier. The information is then given in so called data elements.

This allows implementers to easily implement type checks and then map the information to the

See http://www.unece.org/fileadmin/DAM/trade/untdid/texts/d423.htm
---------------------- Page: 8 ----------------------
SIST-TS CEN/TS 16931-3-4:2018
CEN/TS 16931-3-4:2017 (E)

corresponding semantic context: First it is checked, if in this case the given date string forms a valid

date and secondly the date gets a context for instance to be the actual delivery date. Data elements can

be logically grouped into so called composites. This allows to create a logic bracket for instance to

define the type of date or time information.

To allow efficient automatic processing the semantic meaning is added by using standardized code lists.

The following example illustrates this with the invoice issue date.
DTM+2:20161214:102’
Table 1 — The DTM segment for the invoice issue date
Type Name Description Example Meaning
Segment DTM To specify date, and/or time, or period. DTM
Composite C507 DATE/TIME/PERIOD
Data 2005 Date or time or period function code 137 Issue date/time
element qualifier
Data 2380 Date or time or period text 20161013 13th October 2016
element
Data 2379 Date or time or period format code 102 Format = CCYYMMDD
element

The combination of a qualifier for the date or time type (DTM) together with the corresponding data

elements is called segment. Segments can be grouped in order to form a semantic container for instance

to define a party (e.g. buyer).

A group or segment can be mandatory (M) or conditional (C) and can be specified to repeat

(cardinality). Like a text document an UN/EDIFACT message is structures into header, details and

summary section.

In order to allow a computer to recognize the difference between an XML instance and another text file

XML defines so called processing instructions. In addition the XML based standards being relevant for

the EN 16931 add groups of elements that define the type of message and the context where it is used

in. In order to be processed and XML file needs to be well-formed.

In order to have a consistend UN/EDIFACT file the same concept is applied to the UN/EDIFACT

instance. So called service segments form the outer brackets of the information being present in an

UN/EDIFACT instance. They define for instance the used version, character sets and ensure the

consistency of the message itself.

The following table shows the basic segment structure of an UN/EDIFACT invoice message. Only those

segments are shown, that are relevant for the mapping of the EN 16931.
Table 2 — UN/EDIFACT Invoice structure
Level Name Description Cardinality Example content
Service segments for the start of the instance file
+ UNA Service string adice 1..1 Basic information on the syntax like
separators
+ UNB Interchange header 1..1 Character encoding used
Header section
+ UNH Message header 1..1 Type of message, version
---------------------- Page: 9 ----------------------
SIST-TS CEN/TS 16931-3-4:2018
CEN/TS 16931-3-4:2017 (E)
Level Name Description Cardinality Example content
+ BGM Beginning of message 1..1 Type of invoice, language
+ DTM Date/time/period 1..35 Invoice issue date
+ FTX Free text 0..99 Free text applicable to the whole
message in general like Invoice note
+ SG1 Segment group 1 0..99999 References
++ RFF Reference 1..1 Previous invoice
++ DTM Date/time/period 0..5 Date of precious invoice
+ SG2 Segment group 2 0..99 Parties
++ NAD Name and address 1..1 Buyer name and address
++ FII Financial institution information 0..5 Account number
++ SG3 Segment group 3 0..9999 Party specific references
+++ RFF Reference 1..1 Buyer reference
++ SG5 Segment group 5 0..5 Contact information
+++ CTA Contact information 0..1 Contact point
+++ COM Communication contact 0..5 Telephone number
+ SG 7 Segment group 7 0..99 Currency information
++ CUX Currencies 1..1 Invoice currency
+ SG8 Segment group 8 0..10 Payment terms and conditions
++ PYT Payment terms 1..1 Payment means
++ DTM Date/time/period 0..5 Payment due date
++ PAI Payment instructions 0..1 Payment means code
+ SG16 Segment group 16 0..9999 Document allowance or charges
++ ALC Allowance or charge 1..1 Allowance
++ SG19 Segment group 19 0..1 Percentage
+++ PCD Percentage details 1..1 Allowance percentage
++ SG20 Segment group 20 0..2 Monatary amounts
+++ MOA Monetary amount 1..1 Allowance amount
++ SG22 Segment group 22 0..5 Tax information
+++ TAX Duty/tax/fee details 1..1 VAT rate
+ SG26 Segment group 26 0..99 External files
++ EFI External file link identification 1..1 File name
++ COM Communication contact 0..9 External document location
++ RFF Reference 0..9 Supporting document reference
Detail section
+ SG27 Segment group 27 0..9999999 Line item information
---------------------- Page: 10 ----------------------
SIST-TS CEN/TS 16931-3-4:2018
CEN/TS 16931-3-4:2017 (E)
Level Name Description Cardinality Example content
++ LIN Line item 1..1 Invoice line identifier
++ PIA Additional product id 0..25 Item Seller’s identifier
++ IMD Item description 0..99 Item name
++ QTY Quantity 0..5 Invoiced quantity
++ ALI Additional information 0..5 Item country of origin
++ DTM Date/time/period 0..35 Invoice line period start date
++ FTX Free text 0..99 Invoice line note
++ SG28 Segment group 28 0..99 Product related monetary amounts
+++ MOA Monetary amount 1..1 Invoice line net amount
++ SG30 Segment group 30 0..25 Price information
+++ PRI Price details 1..1 Item net price
++ SG31 Segment group 31 0..10 Line item references
+++ RFF Reference 1..1 Buyer accounting reference
++ SG35 Segment group 35 0..99 Tax information
+++ TAX Duty/tax/fee details 1..1 VAT information
++ SG40 Segment group 40 0..30 Allowances and charges on line level
+++ ALC Allowance or charge 1..1 Charge indicator
+++ SG42 Segment group 42 0..1 Percentage information
++++ PCD Percentage details 1..1 Item charge percentage
+++ SG43 Segment group 43 0..2 Amount information
++++ MOA Monetary amount 1..1 Charge amount
Summary section
+ UNS Section control 1..1 Separator for summary section
+ SG52 Segment group 52 1..100 Document totals
++ MOA Monetary amount 1..1 Paid amount
+ SG54 Segment group 54 0..10 VAT breakdown
++ TAX Duty/tax/fee details 1..1 VAT rate
++ MOA Monetary amount 0..9 Tax amount
+ UNT Message trailer 1..1 End of business document
Service segments for the end of the instance file
+ SG56 Segment group 56 0..99 Attached binary information
++ UNO Object header 1..1 Start of included object
++ UNP Object trailer 1..1 End of included object
+ UNZ Interchange trailer 1..1 End of instance file
---------------------- Page: 11 ----------------------
SIST-TS CEN/TS 16931-3-4:2018
CEN/TS 16931-3-4:2017 (E)

This clear hierarchical structure of an UN/EDIFACT message allows to create a path expression, that

looks similar to a XPath of XML based messages. It allows to clearly identify each individual data

element with its semantic meaning in the corresponding segment or segment group. For example the

path for the invoice issue date can be given as:
INVOIC.DTM[D_2005 = ”137”].C507.2380

The path always starts with the root message type (in this case INVOIC). Then all segments, composits

and data elements, traversed through in the hierarchy are given and separated by a point. As with XPath

filter values can be given in square brackets. The example above can be read as “Give me the Date or

time or period text defined in Data Element 2380 that is part of composite C507 in segment DTM of the

INVOIC message, where the Date or time or period function code qualifier defined in Data Element 2005

is equal to the code 137 that defines the issue date or time.“
4.3 Codes and identifiers

In order to keep UN/EDIFACT up to date to new user semantic requirements as well as impacts by

legislation UN/CEFACT publishes new libraries containing updated code lists normally twice a year. The

important point is that the underlaying syntax itself (Syntax Version 3 or Syntax Version 4) is kept

stable for many years to reduce system modifications to a minimum. Due to the underlaying

methodology to have fixed data types (segments and data elements) that are combined with codes to

define the semantic meaning structural changes are reduced to a minimum. Thus an instance file is

normally backwards-compatible. In practice many systems are implemented based on a directory

version, for example D01B (second publication of the year 2001), while they use the newest code lists

are used if needed (for instance for currencies, countries or languages.)

UN/EDIFACT uses mostly codelists maintained by UN/ECE. Every code is mapped in a specific data

element. Although for some of the code lists (e.g. Currency) the code list number is defined by UN/ECE,

the codes as well as their semantic meaning is identical to the corresponding ISO code list. Due to this

situation all codes from the model can be used as defined. The codes that have the described special

situation are listed below:
Table 3 — UN/EDIFACT codes
Semantic model UN/EDIFACT UNTDID
BT-5 UNTDID 6345
BT-6 UNTDID 6345
BT-18–1 UNTDID 1153
BT-21 UNTDID 4451

In BT-157-1 the EN 16931 references the semantic values of ISO 6523. All values that correspond to the

identification of an item are used in EDIFACT with UNTDID 7143. If the semantic codes of ISO 6523

should be used that are not intended to identify an item, it should be requested to add to UNTDID 7143.

4.4 Mapping the Invoice model

In the following table the semantic data model of the EN16931 is mapped to the corresponding paths of

the UN/EDIFACT INVOIC message structure, as explained above. The cardinality column for the

UN/EDIFACT syntax represents the cardinality as it is defined by UN/CEFACT to illustrate differences

between the semantic data model and the respective syntax. The cardinality of the data model is taken

into account by the corresponding validation artefacts.

The model is mapped to UN/CEFACT INVOIC D14B S4. Although most existing implementations of

UN/EDIFACT are made using Syntax 3 (S3), some specific requirements of the semantic data model

necessitate using Syntax 4 (S4) for easier and more effective implementation. As no special features of

---------------------- Page: 12 ----------------------
SIST-TS CEN/TS 16931-3-4:2018
CEN/TS 16931-3-4:2017 (E)

S4, for example interactive EDI, are needed for implementing the semantic data model, the instances

created using S4 will be compatible to S3 with the following differences:

— With the S4 version the service segments UNA, UNB and UNH have minor structural differences

that specifically allow the use of UTF-8 for encoding. The usage of UTF-8 encoding brings the most

possible interoperability in systems that need to implement all syntaxes from the short list. On the

other hand S3 allows the usage of many different character sets based on ISO 8859 which is a

subset of UTF-8 character set. If in cross border invoices local European languages are used the

conversion from S3 to the receiving system needs some additional effort, although this is very

common practice.

— S4 also allows the direct embedding of binary data (e.g. image files or PDF-files) with the usage of

the UNO and UNP segments. With S3 it is common practice to put the UN/EDIFACT instance in an

XML based Standard Business Document Header (SBDH), which is another standard from UN/ECE.

This is for example done in the automotive industry3. S4 allows a One-Syntax-Only approach for

this.

The implication of choosing S4 instead of S3 on existing implementations of UN/EDIFACT in respect to

cost and effort are seen as minimal for the following reasons:

— The differences in the instance files of S3 and S4 for the data model are minor.

— As many organizations use service providers that generate or process the instance files and

especially the service se
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.