SIST-TS CEN/TS 16931-3-4:2020
(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
Dieses Dokument legt die Zuordnung (en.: mapping) zwischen dem semantischen Modell einer elektronischen Rechnung nach EN 16931 1 und der Syntax aus ISO 9735 (UN/EDIFACT) fest. Für jedes Element im semantischen Modell (einschließlich Unterelemente oder Ergänzungskomponenten wie Identifikationsschema-Kennungen [en: Identification scheme identifiers]) wird definiert, welches Syntax-Element für seine Informationsinhalte verwendet werden muss. Nichtübereinstimmungen zwischen Semantik, Format, Kardinalität oder Struktur werden angezeigt.
Facturation électronique - Partie 3-4 : Correspondance syntaxique pour les factures - Schéma D16B UN/EDIFACT
Elektronsko izdajanje računov - 3-4. del: Povezava sintakse za UN/EDIFACT INVOIC D16B
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
SIST-TS CEN/TS 16931-3-4:2020
01-julij-2020
Nadomešča:
SIST-TS CEN/TS 16931-3-4:2018
Elektronsko izdajanje računov - 3-4. del: Povezava sintakse za UN/EDIFACT
INVOIC D16B
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:2020
ICS:
03.100.20 Trgovina. Komercialna Trade. Commercial function.
dejavnost. Trženje Marketing
35.240.63 Uporabniške rešitve IT v IT applications in trade
trgovini
SIST-TS CEN/TS 16931-3-4:2020 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:2020
---------------------- Page: 2 ----------------------
SIST-TS CEN/TS 16931-3-4:2020
CEN/TS 16931-3-4
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
April 2020
TECHNISCHE SPEZIFIKATION
ICS 35.240.20; 35.240.60 Supersedes CEN/TS 16931-3-4:2017
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 22 December 2019 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, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, 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: Rue de la Science 23, B-1040 Brussels
© 2020 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 16931-3-4:2020 E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
SIST-TS CEN/TS 16931-3-4:2020
CEN/TS 16931-3-4:2020 (E)
Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Syntax binding to UN/EDIFACT . 7
4.1 Introduction . 7
4.2 Data types . 8
4.3 Codes and identifiers .11
4.4 Mapping the Invoice model .12
4.5 Validation artefacts . 129
5 Mismatches . 129
5.1 Semantic level . 129
5.2 Structural level . 129
5.3 Cardinality level . 129
Annex A (normative) Code lists . 130
A.1 Introduction . 130
A.2 Code lists . 130
A.2.1 ISO 3166-1 — Country Codes . 130
A.2.2 ISO 4217 — Currency codes . 130
A.2.3 ISO/IEC 6523 — Identifier scheme code . 131
A.2.4 UNTDID 1001 — Document type . 132
A.2.5 UNTDID 1153 — Reference code qualifier . 133
A.2.6 VAT Identifier . 134
A.2.7 VAT Category code . 134
A.2.8 UNTDID 2005/ UNTDID 2475 — Event time code . 135
A.2.9 UNTDID 4451 — Text subject qualifier . 135
A.2.10 UNTDID 4461 — Payment means . 136
A.2.11 UNTDID 5305 — Duty or tax or fee category . 136
A.2.12 UNTDID 5189 — Allowance codes . 137
A.2.13 UNTDID 7143 — Item type identification code . 138
A.2.14 UNTDID 7161 — Charge codes . 138
A.2.15 Mime type codes — Mime codes . 138
A.2.16 CEF EAS — Electronic address scheme identifier . 139
A.2.17 CEF VATEX — VAT exemption reason code . 139
2
---------------------- Page: 4 ----------------------
SIST-TS CEN/TS 16931-3-4:2020
CEN/TS 16931-3-4:2020 (E)
A.2.18 UN/ECE Recommendation N°20 and UN/ECE Recommendation N°21 — Unit
codes . 140
A.3 International registration authority for ISO/IEC 6523 . 140
A.4 UN/Cefact: new code request / code change request . 148
Annex B (informative) Examples . 152
B.1 Introduction . 152
B.2 Invoice with multiple line items . 152
B.3 IT equipment . 167
B.4 Subscription. 182
B.5 Domestic payment . 186
B.6 Maximum content . 191
B.7 Minimum content . 202
B.8 Taxes . 206
B.9 Electricity . 210
B.10 Licenses . 221
Bibliography . 225
3
---------------------- Page: 5 ----------------------
SIST-TS CEN/TS 16931-3-4:2020
CEN/TS 16931-3-4:2020 (E)
European foreword
This document (CEN/TS 16931-3-4:2020) 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 shall not be held responsible for identifying any or all such patent rights.
This document supersedes CEN/TS 16931-3-4:2017.
The only change compared to the previous edition is the addition of a new annex, Annex A. This Annex
defines the code lists to be used.
This document is part of a set of documents, consisting of:
— EN 16931-1:2017+A1:2019, 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:2020, Electronic invoicing - Part 3 - 2: Syntax binding for ISO/IEC 19845 (UBL 2.1)
invoice and credit note
— CEN/TS 16931-3-3:2020, Electronic invoicing - Part 3 - 3: Syntax binding for UN/CEFACT XML Cross
Industry Invoice D16B
— CEN/TS 16931-3-4:2020, 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, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United
Kingdom.
4
---------------------- Page: 6 ----------------------
SIST-TS CEN/TS 16931-3-4:2020
CEN/TS 16931-3-4:2020 (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 Official
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 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
See https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2010:0712:FIN:en:PDF.
5
---------------------- Page: 7 ----------------------
SIST-TS CEN/TS 16931-3-4:2020
CEN/TS 16931-3-4:2020 (E)
1 Scope
This documents specifies the mapping between the semantic model of an electronic invoice, included in
EN 16931-1 and the ISO 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 are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 9735 (all parts), Electronic data interchange for administration, commerce and transport (EDIFACT) –
Application level syntax rules
EN 16931-1, Electronic invoicing - Part 1: 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.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp/ui
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
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
label assigned to a given information element which is used as a primary reference
6
---------------------- Page: 8 ----------------------
SIST-TS CEN/TS 16931-3-4:2020
CEN/TS 16931-3-4:2020 (E)
3.6
core invoice model
semantic data model of the Core elements of an electronic invoice
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
2
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
2
http://www.unece.org/fileadmin/DAM/trade/untdid/texts/d423.htm
7
---------------------- Page: 9 ----------------------
SIST-TS CEN/TS 16931-3-4:2020
CEN/TS 16931-3-4:2020 (E)
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
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 an 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.
8
---------------------- Page: 10 ----------------------
SIST-TS CEN/TS 16931-3-4:2020
CEN/TS 16931-3-4:2020 (E)
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
+ 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
9
---------------------- Page: 11 ----------------------
SIST-TS CEN/TS 16931-3-4:2020
CEN/TS 16931-3-4:2020 (E)
Level Name Description Cardinality Example content
+ 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
++ 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
10
---------------------- Page: 12 ----------------------
SIST-TS CEN/TS 16931-3-4:2020
CEN/TS 16931-3-4:2020 (E)
Level Name Description Cardinality Example content
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
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
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.