SIST-TS CEN/TS 16931-7:2020
(Main)Electronic invoicing - Part 7: Methodology for the development and use of EN 16931-1 compliant structured Core Invoice Usage Specifications
Electronic invoicing - Part 7: Methodology for the development and use of EN 16931-1 compliant structured Core Invoice Usage Specifications
This document applies in case a CIUS is produced as a specification with the objective of registering it in the appropriate registry. This document also establishes requirements for the steps to be taken in the process of creating Core Invoice Usage Specifications (CIUS) as defined in EN 16931-1. Furthermore this document provides guidance for the creation and implementation of a CIUS.
The following points are the focus:
- steps that need to be taken in consideration to avoid unnecessary proliferation and fragmentation in the use of CIUSs;
- guidance on the creation and implementation of CIUSs, with a quality control objective.
It should be noted that it is planned to apply the same principles and processes to extensions that are documented in a separate document.
Elektronische Rechnungsstellung - Teil 7: Methode zur Entwicklung und Anwendung einer Anwendungsspezifikation der Kernrechnung nach EN 16931-1
Dieses Dokument gilt für den Fall, dass eine CIUS als Spezifikation erstellt wird mit dem Ziel, sie in dem entsprechenden Register zu registrieren. Dieses Dokument legt auch Anforderungen für die Schritte fest, die in dem Prozess zur Erstellung von Anwendungsspezifikation der Kernrechnung (en: Core Invoice Usage Specification, CIUS) nach EN 16931 1 zu veranlassen sind. Darüber hinaus gibt dieses Dokument Leitlinien zur Erstellung und Implementierung einer CIUS vor.
Folgende Schwerpunkte werden behandelt:
- Schritte, die berücksichtigt werden müssen, um eine unnötige Verbreitung und Fragmentierung in der Verwendung von CIUS zu vermeiden;
- Leitlinien zur Erstellung und Implementierung von CIUS mit dem Ziel der Qualitätskontrolle.
Es sollte beachtet werden, dass die Anwendung derselben Grundsätze und Prozesse auf Erweiterungen, die in einem gesonderten Dokument dokumentiert werden, vorgesehen ist.
Facturation électronique - Partie 7 : Méthodologie pour l’élaboration et l’utilisation de spécifications d’usage de la facture de base structurées et conformes à l’EN 16931-1
Elektronsko izdajanje računov - 7. del: Metodologija za razvoj in uporabo strukturirane specifikacije uporabe osrednjega računa (CIUS), skladne s standardom EN 16931-1
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
SIST-TS CEN/TS 16931-7:2020
01-julij-2020
Elektronsko izdajanje računov - 7. del: Metodologija za razvoj in uporabo
strukturirane specifikacije uporabe osrednjega računa (CIUS), skladne s
standardom EN 16931-1
Electronic invoicing - Part 7: Methodology for the development and use of EN 16931-1
compliant structured Core Invoice Usage Specifications
Elektronische Rechnungsstellung - Teil 7: Methode zur Entwicklung und Anwendung
einer Anwendungsspezifikation der Kernrechnung nach EN 16931-1
Ta slovenski standard je istoveten z: CEN/TS 16931-7: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-7: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-7:2020
---------------------- Page: 2 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
April 2020
TECHNISCHE SPEZIFIKATION
ICS 35.240.63; 35.240.20
English Version
Electronic invoicing - Part 7: Methodology for the
development and use of EN 16931-1 compliant structured
Core Invoice Usage Specifications
Elektronische Rechnungsstellung - Teil 7: Methode zur
Entwicklung und Anwendung einer
Anwendungsspezifikation der Kernrechnung nach EN
16931-1
This Technical Specification (CEN/TS) was approved by CEN on 15 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-7:2020 E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)
Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 5
4 Compliance (Source: EN 16931-1:2017) . 6
5 Premises . 9
6 Issues that should be considered to avoid unnecessary proliferation . 9
7 Steps for the issuer of the CIUS . 11
8 Guidance on the creation and implementation of CIUS, with a quality control objective
. 12
9 Machine readable format . 14
Annex A (normative) W3C XML Schema for CIUS configuration . 18
Annex B (informative) Example of CIUS configuration . 28
Bibliography . 32
2
---------------------- Page: 4 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)
European foreword
This document (CEN/TS 16931-7: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.
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.
3
---------------------- Page: 5 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7: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
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.”
To achieve this goal, Directive 2014/55/EU 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. The Directive sets out the legal framework for the establishment
and use of a European Standard (EN) for the semantic data model of the core elements of an electronic
invoice.
The semantic data model of the core elements of an electronic invoice, the core invoice model, is based
on the proposition that a quite limited, but sufficient set of information elements can be defined that
supports generally applicable invoice-related functionalities. The core invoice model contains
information elements that are commonly used and accepted including those that are legally required.
A “Core Invoice Usage Specification” (CIUS) is a specification that provides a seller with detailed guidance,
explanations and examples, as well as rules (business rules) related to the actual implementation and use
of structured information elements present in the core invoice model in a specific trading situation. An
instance document created following a given CIUS will always be compliant with the European Standard.
A receiving party may only claim compliance to the core invoice model if he accepts invoices that comply
with the core invoice model in general, or with a CIUS, that is itself compliant with the core invoice model.
A sending party may claim compliance if he sends invoices that comply with the core invoice model,
including those issued in accordance with a compliant CIUS.
This specification aims to give guidance on the creation and implementation of a CIUS with a quality
control objective. Therefore it is necessary to define a clear set of criteria which a CIUS will comply with
before the CIUS can be registered in the appropriate registry. Some of these criteria will be validated
automatically while others are not.
To hinder excessive proliferation and to guide implementation, publication of CIUSs in a registry is
mandatory and the use of a machine processable format is recommended.
4
---------------------- Page: 6 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)
1 Scope
This document applies in case a CIUS is produced as a specification with the objective of registering it in
the appropriate registry. This document also establishes requirements for the steps to be taken in the
process of creating Core Invoice Usage Specifications (CIUS) as defined in EN 16931-1. Furthermore, this
document provides guidance for the creation and implementation of a CIUS.
The following points are the focus:
— steps that need to be taken in consideration to avoid unnecessary proliferation and fragmentation in
the use of CIUSs;
— guidance on the creation and implementation of CIUSs, with a quality control objective.
It should be noted that it is planned to apply the same principles and processes to extensions that are
documented in a separate document.
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.
EN 16931-1:2017, Electronic invoicing — Part 1: Semantic data model of the core elements of an electronic
invoice
CEN/TS 16931-3-1:2017, Electronic invoicing — Part 3-1: Methodology for syntax bindings of the core
elements of an electronic invoice
CEN/TR 16931-5:2017, Electronic invoicing — Part 5: Guidelines on the use of sector or country extensions
in conjunction with EN 16931-1, methodology to be applied in the real environment
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
Core Invoice Usage Specification
CIUS
specification that provides a seller with detailed guidance, explanations and examples, as well as rules
(business rules) related to the actual implementation and use of structured information elements present
in the core invoice model in a specific trading situation
[SOURCE: EN 16931-1:2017]
5
---------------------- Page: 7 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)
3.2
extension specification
specification that describes the use of additional information elements, i.e. information elements not
defined in the core invoice model, or alterations that add functionality
[SOURCE: EN 16931-1:2017 and CEN/TR 16931-5:2017]
3.3
compliant invoice instance
invoice instance that respects all rules defined for the core invoice model, which could include the
specification contained in a compliant CIUS
[SOURCE: EN 16931-1:2017]
3.4
structured CIUS
CIUS that can be registered in the appropriate registry and therefore complies with the specifications in
this document
3.5
appropriate registry
registry defined by the CEN Technical Board with the task of implementing the requirements of a
European Standard when the said requirements involve the assignment and registration of unique,
unambiguous names according to the procedures described in the European Standard
4 Compliance (Source: EN 16931-1:2017)
4.1 General
Compliance to the core invoice model, can be measured at three levels:
— at the level of specifications;
— the actual implementation of a given sender or receiver;
— the individual invoice instance documents.
Each of these levels is discussed in 4.2 to 4.4.
4.2 Compliance of the core invoice usage specifications
The core invoice usage specifications that are used in conjunction with the core invoice model shall
themselves comply to the methodology and rules described in this guideline and expressed in the
following criteria:
— the specification shall clearly state what business functions and/or legal requirements it is intended
to support;
— the specification shall clearly state its issuer and responsible 'governor';
— the specification shall clearly state in what way the requirements of the CIUS differ from the core
invoice model, either by documenting the difference only or by specifically pointing out what the
differences are;
— the resulting invoice document instance shall be fully compliant to the core invoice model.
6
---------------------- Page: 8 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)
— the specification and, when relevant, its version shall be uniquely identifiable both for referencing
and for identification in processing;
— the specification shall state its underlying specifications (the core invoice model as well as other
specifications that it may build upon);
— the syntax binding of a specification shall follow the syntax binding methodology defined in
CEN/TS 16931-3-1. See Table 1.
Table 1 — Allowed specifications in a CIUS as defined in CEN/TS 16931-3-1:2017, 7.3.2
Type of change Example/remark
Business Terms
Mark conditional Information element not to be used Can be achieved by changing cardinality 0.x to 0.0. This
essentially means that an element which use is
conditional is not to be used. This will not affect the
receivers processing. Care need to be taken to ensure
that the business rules defined for the core invoice
model are not broken.
Make semantic definition narrower A narrower semantic definition of a business term
means that the meaning conveyed is still within the
meaning defined in the core invoice model and is already
recognized by the receiver.
Add synonyms As synonyms will only supplement the original business
terms but do not replace it - the original term is still
normative. A receiver who has designed his processing
based on the core invoice model can continue to do so.
Examples of synonyms are mapping of national or sector
terminology to the terminology used in the core invoice.
Add explanatory text Adding explanatory text that, for example, explains how
a business term is used in a specific use case. There is a
risk is that such text may also affect the semantic
definition and this shall be avoided. Explanatory
information does not require any further action from the
receiver and the automatic processing of the assigned
invoice is still possible.
Cardinality
Make a conditional element mandatory (0.x – > 1.x) If a conditional element is made mandatory it simply
means that the option of using it is applied. The receiver
shall be prepared for the situation that a conditional
element is used, so he does not need to modify his
processing.
Decrease number of repetitions (x.n – > x.1) If the number of repetitions is decreased they will
remain within the limit that the receiver has catered for.
Semantic data type
Change semantic data type from string to . If the semantic data type of a business term is changed
from string to some other type the receiver can still
process the value as a string.
7
---------------------- Page: 9 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)
Type of change Example/remark
Codes and identifiers
Remove one of multiple defined lists Where the core invoice semantic model defines
more than one allowed list and the core invoice
usage specification reduces the number of allowed
lists then the invoice instance document is still
conformant. However such a change shall leave at
least one of the defined lists in place.
Mark defined values as not allowed If the allowed code values are restricted within an
existing list it simply means that certain values of
the full list are being used and the receiver should
have designed for processing them.
Business Rules
Add new non-conflicting business rule for existing Represents an additional restriction on the allowed
element(s) content within what is defined for the core invoice
model. The receiver should therefore have designed
for that content.
Make an existing business rule more restrictive The exchanged content of the business term
remains within what was defined for the core
invoice model and the receiver should have
designed for it.
Value domain for an element
Restrict text or byte array length If a maximum is set on the length where there was
no limit the content remains within what was
defined for the core invoice model.
Require defined structured values When the core invoice model does not set a
structure on a value the receiver would not have
designed for processing in any particular form.
Rules to enforce a given pattern should therefore
not affect his processing.
Restrict allowed fraction digits Fewer fraction digits result in a value that is within
the accuracy that the receiver would have designed
for when implementing the core invoice model.
4.3 Compliance of sending or receiving party
A receiving party may only claim compliance to the core invoice model if he accepts invoices that comply
with the core invoice model in general, or with a CIUS, that is itself compliant with the core invoice model.
A sending party may claim compliance if he sends invoices that comply to the core invoice model,
including those issued in accordance with a compliant CIUS.
4.4 Compliance of an invoice document instance
An invoice document instance is compliant to the core invoice model if it respects all rules defined for the
core invoice model, which may include the specification contained in a compliant CIUS.
If an invoice instance document supports requirements that can be considered as a use of a CIUS, the
invoice instance document is still compliant to the core invoice model. These invoice instance documents
8
---------------------- Page: 10 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)
can still be received and processed by a party who is not supporting the CIUS because it still complies to
the rules of the core invoice model.
5 Premises
The CIUS has already been subject to extensive discussions, comments, decisions and actual
implementations, all of which shall be taken into consideration and contribute to the premises for this
work:
— CIUS as a concept is described in the EN 16931-1, together with the types of specifications and/or
restrictions that are allowed in a CIUS in order to ensure its compliance with the EN 16931-1;
— other reports generated within CEN/TC 434 and in the European Multi-Stakeholder Forum on e-
Invoicing have already made important recommendations on implementing CIUSs e.g. EMSFEI’s
“Recommendation on the use of ‘Core Invoice Usage Specifications’ (CIUS)”;
— the relationship with ongoing CEN/TC 434 standardization activities.
6 Issues that should be considered to avoid unnecessary proliferation
6.1 General
Various factors will influence the quantity and quality of CIUSs, and each of these should be discussed.
6.2 When should a CIUS be created?
Aside from considerations as to who can issue a CIUS, there is a need to consider when its issuance can
be justified.
The concept of CIUS is mainly to enable buyers to establish restriction specifications needed for correctly
processing the invoice and progressing towards payment. The buyers communicate to invoice issuers
which information they need and it is in the interest of suppliers to provide the information as required
by their customers.
In discussions on CIUSs the question has been raised as to whether simple specifications and/or
restrictions on the use of information elements composing the EN should be treated as a CIUS or whether
these are simply part of the contract between trading parties. The discussions indicate that there are
different views on when it is necessary to create a CIUS, but there seems to be a general consensus to
minimize the number of CIUSs and to recommend that a CIUS should only be considered if:
a) there is a strong business or legal requirement to further restrict or clarify the specifications in the
EN;
b) there is no existing CIUS that covers the requirement (e.g. a sector CIUS or a CIUS made available
through an infrastructure such as PEPPOL or a national platform);
c) the CIUS is likely to apply to a large number of trading parties within a grouping such as a public
sector, sub-sector of the public sector or a private sector community with common requirements;
d) the CIUS doesn’t create cross border trade barriers.
9
---------------------- Page: 11 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)
6.3 Who can issue a CIUS?
The following parties, among others, may issue a CIUS:
a) CEN/TC 434 itself;
b) CEN National Standards Bodies (NSBs);
c) CEN/TC 434 Liaison Organizations;
d) member states;
e) bodies representing a public sector or business community;
f) national or European stakeholder fora;
g) national or European e-invoicing fora;
h) others (e.g. single buyer and single supplier).
Before mandating a CIUS, single buyers or suppliers should carefully consider whether there is a
sufficient business case and whether they can exercise sufficient impact or influence on their trading
partners to make the CIUS operative. This aspect is discussed below in the section ‘Steps for the issuer of
the CIUS’.
6.4 How to create a CIUS?
The tools and other help like templates and support that are made available to the issuer of the CIUS will
have impact on both the quantity and quality of the CIUSs.
An example of such a capability is an appropriate registry as specified by CEN/TC 434 where search
facilities will provide extensive information on individual CIUSs, their associated rules, practices and
minimum requirements.
6.5 Formalization
The degree of formalization will also strongly influence the degree of proliferation and render more
uniform the specification and the publication of a structured CIUS. This will make it easier for both issuers
and implementers of a CIUS to search, identify, compare, create and implement a CIUS. The list below
specifies the minimum degree of formalization:
a) as a minimum, a machine processable representation according to this specification with the
necessary information to identify and describe the CIUS shall be completed;
b) the CIUS shall be published in the appropriate registry;
c) any specific business rules shall be defined and listed with a unique identifier and, when appropriate,
validation artefacts shall be created;
d) simple instructions how to apply the CIUS shall be provided to facilitate the invoice preparation and
to avoid errors;
e) sample files shall be provided;
f) the specification and, when relevant, its version shall be uniquely identifiable both for referencing
and for identification in processing.
10
---------------------- Page: 12 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)
6.6 Machine processable representation
The issuer of a CIUS shall create the machine processable representation as specified in the Annex. This
includes the creation and publication of related business rules to ensure that all information required for
processing the CIUS is available. The completion of the machine processable representation may also help
the issuer to reflect on the need for a CIUS.
6.7 Registry
A main benefit of an appropriate registry will be to make it easier for a user to search and sort the stored
artefacts, gain an understanding of the content, and then compare the component elements e.g. to see the
difference between existing CIUSs and/or a planned CIUS and establish whether an existing CIUS could
be completely or partially re-used. The more transparent the information the easier it will be to avoid
duplicates.
7 Steps for the issuer of the CIUS
In order to avoid proliferation a number of specific steps shall be considered by the prospective issuer of
the CIUS prior to creating a new CIUS. The following elements shall be considered.
a. Before creating a CIUS one shall:
— keep in mind that not registering a CIUS increases confusion and complexity in the marketplace
and potentially additional cost for all parties involved;
— consider the economic and other types of influence to mandate suppliers, such as responsibility
for a sector, sub-sector or trading community;
— check if the publication of the CIUS is in line with competition or other laws and regulations;
— keep in mind that mandating a CIUS requires extra effort to create, maintain and publish it;
— consider whether the added value in processing invoice instances is sufficient to justify the
effort;
— keep in mind that the rules applied could potentially create confusion instead of solving issues;
— keep in mind that mandating a CIUS in order to comply with (local) legislation or policy is like
creating rules that one has to comply with. Such a CIUS runs the risk appearing to create new or
different rules and even create confusion.
b. Consider if the intended CIUS is a threat for interoperability.
c. Check if a CIUS covering the needs already exists:
— check the available resources to see if an existing CIUS may cover your needs;
— contact the responsible persons or entity for an existing CIUS that actually or substantially covers
the needs to check if collaboration can be achieved.
d. Before creating a new CIUS consider what is the maximum reach of the CIUS
— consider what the largest reach and number of users is for the CIUS;
11
---------------------- Page: 13 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)
— contact the authority responsible for the sector, country or other group of users of this largest
reach;
— check if collaboration or support is available at the largest reach possible;
— if a large reach is not feasible, only then consider your own CIUS.
e. The necessary resources (human, technical, budget) shall be available to support the creation and
maintenance
— bear in mind the effort to create, maintain and publish the CIUS;
— bear in mind to clearly inform customers and/or suppliers;
— check if the back-office systems or processes require enhancement or adaption;
— consider a backup plan in case customers and/or suppliers do not respect the CIUS request;
— bear in mind the various types of requests from different types of user;
— define what type of support to give free of charge to the market as a CIUS publisher (e.g. FAQ)
and the type of support belonging to the competitive space (e.g. consultancy).
f. Make sure to publish the CIUS
— publish it on the appropriate registry;
— publish it on the national authority website if available;
— inform customers and/or suppliers so they have access;
— publishing it will allow reuse of your CIUS.
8 Guidance on the creation and implementation of CIUS, with a quality control
objective
The purpose of a CIUS in a broad sense is to clarify how certain information elements in an invoice
instance shall be used, for example by further restricting, mandating or specifying how elements shall be
used. It is obvious that the documentation describing the CIUS shall contain all information for the
stakeholders involved. The nature of the stakeholders may require various levels and types of
information. Some information will be more explanatory while other may be more technical.
At the same time avoiding proliferation, ease of use and reuse of the CIUS is as important as the specific
quality of a CIUS itself.
To achieve the various goals described above, it is necessary that:
— the documentation is presented in a structured and easy to use way;
— the documentation is partly human and partly machine readable, as appropriate;
— the documentation meets quality criteria, for example specified in the appropriate registry;
— the CIUSs are listed in the appropriate registry.
12
---------------------- Page: 14 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)
The necessary tools and procedures available facilitate the creation/maintenance of a CIUS. These tools
and procedures will evolve over time to address the necessary requirements at the given time. Below you
find an overview of tools and procedures.
a) Make sure you use the correct notation for the CIUS specification identifier.
A CIUS specification identifier shall be structured as follows:
SourceSpec#compliant#TargetSpec
— SourceSpec shall be the core invoice model.
— Conformance states how the changes relate to the SourceSpec, using TOGAF terminology.
— TargetSpec are the identifiers for the extension specification itself and the extension specification
or core invoice usage specification that it builds on.
The TargetSpec and the SourceSpec shall be identified by giving a uniform resource name (urn). The
identifier for the European Norm is to include its EN number (EN 16931-X:2017)
For clarity, the main part
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.