BSI PD CEN/TR 16931-6:2017
$42.47
Electronic invoicing – Result of the test of EN 16931-1 with respect to its practical application for an end user
Published By | Publication Date | Number of Pages |
BSI | 2017 | 88 |
0.1 Introduction Directive 2014/55/EU states the following: “The standard shall be tested as to its practical application for an end user. The Commission shall retain overall responsibility for the testing and shall ensure that, during the performance of the test, special account be taken of the respect for the criteria of practicality, user-friendliness and possible implementation costs in accordance with the second subparagraph of paragraph 1. 0.2 In scope This CEN Technical Report describes the methodology used for testing at a semantic level and at the syntax level, as well as describing the semantic testing, the syntax testing and testing of the validation artefacts that represent EN 16931-1 and the test results. The testing of the validation artefacts will ensure they can be used to automatically check conformance with EN 16931-1. 0.3 Out of scope During meetings with the European Commission they agreed to supplement the testing activities as the need arises. This included the provision of a hosted GITB (Global eBusiness Interoperability Test Beds) environment for syntax testing and to run separate studies such as assessment of implementation costs. The results of these studies will be published separately by CEF. It was agreed at earlier meetings that piloting was out of scope i.e. perform live transactions, because resources were unavailable to undertake this in the time allowed. Instead we could simulate scenarios by leveraging on the experience of our experts. Working Group 3 (hereafter WG3) in CEN/TC 434 has produced the syntax bindings and validation artefacts, and the task of quality assurance of these deliverables has been the responsibility of WG3. VAT issues are complex and require juridical or legal expertise. VAT is also sometimes very sectoral or even country specific. Certain sections, in the VAT Directive, apply to all trades, others deal with special cases. The model should facilitate, but cannot be seen as an enforcement model. Therefore, VAT compliance would have to be checked on a case by case basis, and is deemed out of scope. The Commission had taken this up and given the draft to their VAT experts. The result was that no issues were discovered. Article 226(B) of the VAT Directive [2] describes the simplified invoice. There are significantly fewer requirements for this invoice. It can only be used when the value is below a specific total amount. The requirement is to provide a model for low value purchases such as train tickets, receipts etc. The key difference is that it doesn’t require the Buyer to be identified. Due to limited resources the simplified invoice requirements were not checked and so are being considered as an extension to be developed at a future stage. The changing between form and format was discussed. It was generally agreed, based on the VAT Directive, that an eInvoice cannot change form i.e. transformed to paper, however it can change format i.e. syntax. This is common in EDI systems and for legal reasons the original needs to be clarified. This means if it is in paper form it shall be archived in paper form and if it is electronic it shall stay in electronic form. An electronic invoice may change format, provided this is documented in an audit trail. However, in Norway and France the legislation states that the format received from the Supplier is the original and no other. Also, general practice in Germany requires that the invoice received from the Supplier be archived and considered as the original. There may be other exceptions in some Member States. This was also considered to be out of scope for this document and would be dealt with by the Member State involved. It was agreed at an initial Plenary session that we should test all four syntaxes as the decision to select syntaxes had not yet been made. However ultimately the group concluded, based on our research, that the ISO 20022 Financial Invoice was not in sufficient use to justify being included.
PDF Catalog
PDF Pages | PDF Title |
---|---|
2 | National foreword |
8 | 0 Introduction 0.1 Summary 0.2 Requirements for testing derived from European legislation |
9 | 1 Scope 1.1 Introduction 1.2 In scope 1.3 Out of scope |
10 | 2 Normative references 3 Terms and definitions 4 Testing 4.1 General |
11 | 4.2 Semantic testing 4.2.1 Introduction 4.2.2 The standardization request and specific requirements |
16 | 4.2.3 The Semantic testing of real instances 4.2.4 Findings and recommendations |
17 | 4.2.5 Conclusion of semantic testing 4.3 Syntax testing |
18 | 5 Generating invoice instances 5.1 Requirements 5.2 Generating Instances 5.2.1 Methodology |
19 | 5.2.2 Generating invoice instances 5.2.3 Error-free instance 5.2.4 Pushing errors in instance 5.2.4.1 Forcing syntax errors |
20 | 5.2.4.2 Forcing content errors 6 Validation of invoice instances 6.1 General 6.2 Validation of UBL instances 6.2.1 Test instances and preparation 6.2.2 Adjustments of provided “real-world” sample files 6.2.3 Creation of manipulated instances provoking errors |
21 | 6.2.4 Test tools used 6.2.5 Test procedure 6.2.6 Test results 6.3 Validation of CII instances 6.3.1 Test instances and preparation |
22 | 6.3.2 Instances as provided by CEN/TC 434 6.3.3 Creation of manipulated instances provoking single errors (BR and SR) 6.3.4 Adjustments of provided “real-world” sample files 6.3.5 Test tools used 6.3.6 Test procedure |
23 | 6.3.7 Test results 6.3.7.1 Overview 6.3.7.2 Finding on a semantic test 6.4 Validation of EDIFACT instances 6.4.1 Test instances and preparation 6.4.2 Adjustments of provided “real-world” sample files 6.4.3 Creation of manipulated instances provoking single errors (BR and SR) |
24 | 6.4.4 Test tools used 6.4.5 Test procedure 6.4.6 Test results 7 Transmission 7.1 Methodology |
25 | 7.2 Invoice Provider Basic Conformance Test for UBL syntax and PEPPOL AS2 protocol 7.2.1 Overview 7.2.2 Actors |
26 | 7.2.3 Test Scenario 7.2.3.1 Overview 7.2.3.2 End point Lookup |
27 | 7.2.3.3 Document Exchange |
28 | 7.3 Invoice Provider Basic Conformance Test for EDIFACT syntax and OFTP2 protocol 7.3.1 Overview 7.3.2 Actors 7.3.3 Standards and Specifications |
29 | 7.3.4 Test Scenario 7.3.4.1 General 7.3.4.2 Abstract Test Steps 7.3.5 An example execution of a test case |
32 | 7.4 Test results 8 Presentation and visualization of instances 8.1 General 8.2 Requirements |
33 | 8.3 Test methodology applied 8.3.1 Process 8.3.2 Overview of representation methods and tools 8.3.3 Examples for XML based instance representations |
35 | 8.3.4 Microsoft Excel interpretation of an XML instance 8.3.5 Visualizations in ERP systems |
36 | 8.3.6 XSL Transformation – Example Transformation XML to HTML 8.3.6.1 General |
37 | 8.3.6.2 Transformed XML in web browser |
39 | 9 Payment 9.1 Requirements |
40 | 9.2 Automatic processing for invoice to SEPA payment reconciliation |
41 | 9.3 Test Methodology Applied 9.3.1 Methodology |
42 | 9.3.2 Caveats 9.4 Test Execution 9.4.1 Semantic Model 9.4.1.1 Requirements |
44 | 9.4.1.2 Semantic Model / Payment Files / Account Statements 9.4.1.3 Invoice and SEPA Credit Transfer Instruction |
47 | 9.4.1.4 Invoice and SEPA Direct Debit Instruction |
48 | 9.5 Test Results 9.5.1 Semantic Model |
49 | 9.5.2 Traceability and Automated Reconciliation 9.5.2.1 General 9.5.2.2 Traceability for SEPA Direct Debits 10 Automatic processing 10.1 Requirements |
50 | 10.2 Testing 10.3 Test results |
51 | 11 Conclusions |
52 | Annex A (informative)WG6 Comment resolution on Semantic model |
60 | Annex B (informative)List of visualization systems |
61 | Annex C (informative)What is GITB? C.1 Introduction C.2 The GITB Testing Framework C.2.1 GITB Methodology |
62 | C.2.2 GITB Architecture C.3 Implementation Specifications and Proof-of-Concept C.3.1 Implementation Specifications |
63 | C.3.2 Prototype Test Registry and Repository C.4 Validation and transmission testing C.4.1 What to Test? C.4.2 How to Test? C.4.2.1 Introduction C.4.2.2 Testing Scenario 1: Standalone Document Validation |
64 | C.4.2.3 Testing Scenario 2: SUT-Interactive Conformance Testing C.4.2.4 Testing Scenario 3: Interoperability Testing |
65 | C.4.3 Test Suite, Test Case and Messaging Adapters |
67 | C.5 CEN/TC 434 usage of GITB and Test Cases C.5.1 Overview |
68 | C.5.2 Standalone Document Validation Test Cases for the Invoice Providers C.5.2.1 General |
69 | C.5.2.2 Invoice Provider Conformance Test Cases C.5.2.3 Invoice Receiver Conformance Test Cases |
70 | C.6 Test execution C.6.1 General C.6.2 Standalone Document Validation through the GITB website |
77 | C.6.3 Invoice Provider Basic Conformance Test for UBL syntax and PEPPOL AS2 protocol C.6.3.1 Underlying Standards and Related Existing Test Artefacts/Tools/Services to Reuse in the Domain |
78 | C.6.3.2 Test Suite Definition |
79 | C.6.3.3 Development of the Necessary Messaging Handlers |
80 | C.6.3.4 Definition of Test Artefacts |
83 | C.6.4 Invoice Provider Basic Conformance Test for EDIFACT syntax and OFTP2 protocol C.6.4.1 EDIFACT Document validation |
84 | C.6.5 OFTP2 Message Validation |