SIST-TS CEN/TS 16931-3-4:2018
(Main)Electronic invoicing - Part 3-4: Syntax binding for UN/EDIFACT INVOIC D16B
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
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
SIST-TS CEN/TS 16931-3-4:2018
01-januar-2018
(OHNWURQVNRL]GDMDQMHUDþXQRYGHO 6LQWDNVDSRYH]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
2
---------------------- 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.
3
---------------------- 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
1
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
1
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2010:0712:FIN:en:PDF.
4
---------------------- 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
5
---------------------- 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
2
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
2
See http://www.unece.org/fileadmin/DAM/trade/untdid/texts/d423.htm
6
---------------------- 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
7
---------------------- 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
8
---------------------- 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
9
---------------------- 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
10
---------------------- 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.