Feedback on JP PINT V1.0 Current State<\/h1>\n\nTable of Contents<\/div>\n\n- 1. What is XML Selector?<\/a>\n
\n- 1.1. XML Selector and XPath for UBL Invoice<\/a><\/li>\n
- 1.2. Issue with Selector
cac:PartyTaxScheme[cac:TaxScheme = \"VAT\"]<\/code><\/a><\/li>\n<\/ul>\n<\/li>\n- 2. Enhancing Open Peppol Standards with the Adoption of XPath<\/a>\n
\n- 2.1. The Benefits of Adopting XPath<\/a><\/li>\n
- 2.2. Recommendation to Open Peppol<\/a><\/li>\n<\/ul>\n<\/li>\n
- 3. Elements correctly defined in syntax binding through selector specification<\/a>\n
\n- 3.1. Selector for Additional Document Reference (DocumentTypeCode = 130)<\/a><\/li>\n
- 3.2. Selector for LINE OBJECT IDENTIFIER<\/a><\/li>\n<\/ul>\n<\/li>\n
- 4. Errors in Syntax Binding<\/a>\n
\n- 4.1. Issue with Selector for Additional Document Reference (DocumentTypeCode != 130)<\/a><\/li>\n
- 4.2. Issue with Selector for Party Identification (SEPA scheme)<\/a><\/li>\n
- 4.3. Selector for Party Tax Scheme (TaxScheme = \u201cVAT\u201d)<\/a><\/li>\n
- 4.4. Issue with Selector for Party Tax Scheme (Not Equal to \u201cVAT\u201d)<\/a><\/li>\n
- 4.5. Issue with Selector for Allowance Charge (ChargeIndicator = false)<\/a><\/li>\n
- 4.6. Issue with Selector for Allowance Charge (ChargeIndicator = true)<\/a><\/li>\n
- 4.7. Issue with Selector for Tax Total (Currency Equals Document Currency Code)<\/a><\/li>\n
- 4.8. Issue with Selector for Tax Total (Currency Equals Tax Currency Code)<\/a><\/li>\n
- 4.9. Issue with Selector for Document Reference (DocumentTypeCode != 130)<\/a><\/li>\n
- 4.10. Issue with Selector for Allowance Charge (ChargeIndicator = false)<\/a><\/li>\n
- 4.11. Issue with Selector for Allowance Charge (ChargeIndicator = true):<\/a><\/li>\n
- 4.12. Issue with no Selector for Allowance Charge (ChargeIndicator = false):<\/a><\/li>\n<\/ul>\n<\/li>\n
- 5. Inconsistency Between BIS and Syntax Binding<\/a>\n
\n- 5.1. PAYMENT CARD INFORMATION financial service network provider of the card<\/a><\/li>\n
- 5.2. Missing mandatory element cbc:LineID in DESPATCH REFERENCE<\/a><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/div>\n<\/div>\n\n\n\n\n
Nobuyuki SAMBUICHI
\nISO\/TC295 Audit data services<\/a>\/SG1 Semantic model Convener<\/p>\n<\/div>\n\nThe comments provided address various issues related to the PEPPOL Business Interoperability Specifications (BIS) and syntax bindings in the context of invoice processing. These comments highlight inconsistencies, missing elements, and potential improvements. The suggestions range from defining new business terms to aligning values for specific elements. Additionally, there are proposals to include missing elements in examples and provide clarifications within the documentation. Overall, the comments aim to enhance the clarity and consistency of the specifications, ensuring smoother implementation and interoperability in invoice processing within the PEPPOL framework.<\/p>\n<\/div>\n<\/div>\n<\/div>\n
\n1. What is XML Selector?<\/h2>\n\n\n1.1. XML Selector and XPath for UBL Invoice<\/h3>\n\nXML selectors play a vital role in locating specific elements or nodes within an XML document. XPath, short for XML Path Language, serves as a powerful tool for navigating and querying XML documents, allowing for precise element pinpointing.
\nLet\u2019s consider a scenario where you have an XML representation of a UBL (Universal Business Language) invoice. In this case, your objective is to selectively identify \u201cAllowance\u201d elements, but exclusively those found at the document level (as opposed to the line item level) where the \u201cChargeIndicator\u201d attribute is set to \u201cfalse.\u201d
\nHere\u2019s an example of how to employ XPath to achieve this task:<\/p>\n<\/div>\n
\n\n<?xml version=\u201c1.0\" encoding=\u201cUTF-8\u201d?>\r\n<Invoice xmlns=\u201curn:oasis:names:specification:ubl:schema:xsd:Invoice-2\"\r\n xmlns:cac=\u201curn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2\u201d\r\n xmlns:cbc=\u201curn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2\">\r\n <!-- ... other invoice elements ... -->\r\n <cac:AllowanceCharge>\r\n <cbc:ChargeIndicator>false<\/cbc:ChargeIndicator>\r\n <!-- ... other allowance charge details ... -->\r\n <\/cac:AllowanceCharge>\r\n <!-- ... other invoice elements ... -->\r\n<\/Invoice><\/code><\/pre>\n<\/div>\n<\/div>\n\nTo isolate the \u201cAllowance\u201d elements where the \u201cChargeIndicator\u201d is set to \u201cfalse,\u201d you can employ the following XPath expression:<\/p>\n<\/div>\n
\n\n\/\/cac:AllowanceCharge[cbc:ChargeIndicator = \u2018false\u2019]<\/code><\/pre>\n<\/div>\n<\/div>\n\nHere\u2019s a breakdown of this expression:
\n– \/\/<\/code> selects nodes from anywhere within the XML document.
\n– cac:AllowanceCharge<\/code> targets the \u201cAllowanceCharge\u201d elements within the XML.
\n– [cbc:ChargeIndicator = \u2018false\u2019]<\/code> serves as a predicate, filtering the \u201cAllowanceCharge\u201d elements based on the condition that the child element \u201cChargeIndicator\u201d possesses a text value of \u201cfalse.\u201d
\nNevertheless, it\u2019s essential to note that this selector retrieves both document-level and line item-level allowances. Should you wish to exclusively choose document-level \u201cAllowanceCharge\u201d elements where the \u201cChargeIndicator\u201d is set to \u201cfalse,\u201d you can refine your XPath expression to consider the specific context of these elements. Presuming that document-level \u201cAllowanceCharge\u201d elements are situated directly beneath the root \u201cInvoice\u201d element, the following XPath expression can be employed:<\/p>\n<\/div>\n\n\n\/Invoice\/cac:AllowanceCharge[cbc:ChargeIndicator = \u2018false\u2019]<\/code><\/pre>\n<\/div>\n<\/div>\n\nThis revised expression operates as follows:
\n– \/Invoice<\/code> pinpoints the root \u201cInvoice\u201d element.
\n– \/cac:AllowanceCharge[cbc:ChargeIndicator = \u2018false\u2019]<\/code> selectively picks the \u201cAllowanceCharge\u201d elements that are immediate children of the \u201cInvoice\u201d element and possess a \u201cChargeIndicator\u201d child element with a value of \u201cfalse.\u201d This assures the exclusive selection of document-level \u201cAllowanceCharge\u201d elements.<\/p>\n<\/div>\n<\/div>\n\n1.2. Issue with Selector cac:PartyTaxScheme[cac:TaxScheme = \"VAT\"]<\/code><\/h3>\n\nIn the Syntax Binding definition table, there is a row defined as “PARTY TAX \u2022\u2022 cac:PartyTaxScheme [cac:TaxScheme = “VAT”]” just above IBT-031 Seller TAX identifier. The selector mentioned here, [cac:TaxScheme = \"VAT\"]<\/code>, appears to be an attempt to identify elements where the TaxScheme<\/code> element, which is a complex type, is an element with the string value “VAT.” However, there is a fundamental issue with this selector. It arises from the fact that TaxScheme<\/code> is not a simple text element but a complex type.<\/p>\n<\/div>\n\nIn XML, complex types typically contain child elements and attributes and do not have direct text content that can be compared using the =<\/code> operator. Based on the description of the UBL XML structure, the relevant information seems to be within the cbc:ID<\/code> child element inside the cac:TaxScheme<\/code> complex type. Therefore, to accurately select elements based on the value of cbc:ID<\/code> within cac:TaxScheme<\/code>, you need to first navigate to that child element and then compare its value.<\/p>\n<\/div>\n\nWhen specifying XPath in XML editing software like XML Spy, the elements specified by that XPath are displayed. However, with the following XPath defined based on the Syntax Binding table, the corresponding elements cannot be found:<\/p>\n<\/div>\n
\n\n\/Invoice\/cac:AccountingSupplierParty\/cac:Party\/cac:PartyTaxScheme[cac:TaxScheme = \"VAT\"]<\/code><\/pre>\n<\/div>\n<\/div>\n\n\n![\"IBT](\"https:\/\/www.sambuichi.jp\/wp-content\/uploads\/2023\/10\/IBT-031NG.png\")
\n<\/div>\n<\/div>\n\nThe following is an example of how to adjust the XPath expression to select elements where the value of cbc:ID<\/code> is “VAT”:<\/p>\n<\/div>\n\n\n\/Invoice\/cac:AccountingSupplierParty\/cac:Party\/cac:PartyTaxScheme[cac:TaxScheme\/cbc:ID = \"VAT\"]<\/code><\/pre>\n<\/div>\n<\/div>\n\n\n![\"IBT](\"https:\/\/www.sambuichi.jp\/wp-content\/uploads\/2023\/10\/IBT-031OK.png\")
\n<\/div>\n<\/div>\n\nLet’s explain this modified expression:
\n– \/Invoice\/cac:AccountingSupplierParty\/cac:Party\/<\/code> selects from the descendant elements of the root element within the XML document, which is cac:Party<\/code> in this case.
\n– cac:PartyTaxScheme<\/code> identifies the cac:PartyTaxScheme<\/code> element.
\n– [cac:TaxScheme\/cbc:ID = \u2018VAT\u2019]<\/code> serves as a predicate that filters elements where the cbc:ID<\/code> grandchild element within the cac:TaxScheme<\/code> child element is equal to “VAT.”<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n2. Enhancing Open Peppol Standards with the Adoption of XPath<\/h2>\n\n\nIn the context of CEN\/TC 16931-3-2, electronic invoices defined in EN-16,931-1 are mapped to UBL2.1. The correspondence is indicated in two tables, Table3 and Table4, delineating the relationship between the semantic model and XML path elements. Each table, normative and informative respectively, plays a distinct role in facilitating understanding and implementation.
\nTable3 and Table4 serve different yet complementary purposes in mapping the relationships between the electronic invoice specified in EN-16,931-1 and UBL2.1. Table3 helps in understanding which XML path elements correspond to the semantic model, providing a clear translation from the electronic invoice elements to their UBL2.1 counterparts. On the other hand, Table4 offers the reverse mapping, indicating how elements on the XML paths correspond to items in the semantic model. Having both tables ensures that users can easily cross-reference and validate the mappings in both directions.<\/p>\n<\/div>\n
\n\n\n\n![\"16931](\"https:\/\/www.sambuichi.jp\/wp-content\/uploads\/2023\/10\/16931-3-2Table3-1.png\")
\n<\/div>\n<\/div>\n\n\n![\"16931](\"https:\/\/www.sambuichi.jp\/wp-content\/uploads\/2023\/10\/16931-3-2Table3-2.png\")
\n<\/div>\n<\/div>\n\n\n![\"16931](\"https:\/\/www.sambuichi.jp\/wp-content\/uploads\/2023\/10\/16931-3-2Table3-3.png\")
\n<\/div>\n<\/div>\nThe following is omitted.\n<\/p><\/blockquote>\n
\n— CEN\/TS 16931-3-2
\nTable 3<\/cite>\n<\/div>\n<\/div>\n\n\n\n\n![\"16931](\"https:\/\/www.sambuichi.jp\/wp-content\/uploads\/2023\/10\/16931-3-2Table4-1.png\")
\n<\/div>\n<\/div>\n\n\n![\"16931](\"https:\/\/www.sambuichi.jp\/wp-content\/uploads\/2023\/10\/16931-3-2Table4-2.png\")
\n<\/div>\n<\/div>\n\n\n![\"16931](\"https:\/\/www.sambuichi.jp\/wp-content\/uploads\/2023\/10\/16931-3-2Table4-3.png\")
\n<\/div>\n<\/div>\nThe following is omitted.\n<\/p><\/blockquote>\n
\n— CEN\/TS 16931-3-2
\nTable 4<\/cite>\n<\/div>\n<\/div>\n\nThe distinction between normative and informative in the context of Table3 and Table4 is essential. Table3 is normative, meaning it’s a fundamental part of the standard, essential for ensuring consistent and correct implementations of the electronic invoice mappings to UBL2.1. Table4, being informative, serves as a reference and aids in understanding the mappings but isn’t mandatory for implementation. It’s a guide to assist users in interpreting and applying the mappings, enhancing their comprehension of the relationships between the electronic invoice and UBL2.1 elements.<\/p>\n<\/div>\n
\n2.1. The Benefits of Adopting XPath<\/h3>\n\nHowever, there\u2019s room for refinement in this approach to standardization. Specifically, adopting XPath in defining XML elements, as opposed to paths, could enable more efficient and accurate mapping.<\/p>\n<\/div>\n
\nIn Table3, the BT-18 Invoiced object identifier has a specified rule noted as “with cbc:DocumentTypeCode = 130” in the text field. This implies that the path includes a descriptive rule that requires human interpretation to be converted into a program. This process can be time-consuming and introduces the risk of varied interpretations and errors.
\nIf the definition were provided in XPath, it would significantly reduce the need for manual interpretation and enable more efficient data processing. XPath is a query language for selecting elements and attributes in an XML document, allowing for precise data extraction and manipulation. Utilizing XPath would enable computer programs to directly, accurately, and swiftly interpret and execute the data conversion process, bypassing the need for human interpretation. This enhancement ensures data consistency and minimizes issues arising from errors or varied interpretations.<\/p>\n<\/div>\n
\nImplementing XPath offers manifold advantages. It simplifies the navigation of complex XML documents and efficiently locates and selects specific elements and attributes. This capability can render the mapping between electronic invoices and UBL2.1 more flexible and precise.<\/p>\n<\/div>\n<\/div>\n
\n2.2. Recommendation to Open Peppol<\/h3>\n\nGiven the widespread adoption of Open Peppol standards across various industries globally, enhancing the accuracy and efficiency of these standards is paramount. Embracing XPath could elevate these standards, paving the way for broader and smoother adoption by organizations.<\/p>\n<\/div>\n
\nAs a first step, we strongly recommended the adoption of XPath to Open Peppol, and descriptions of the Selector have been added to the traditional path definitions. However, there is still room for improvement in terms of precision.<\/p>\n<\/div>\n
\nOn the following websites, you will find tables that have replaced the path definitions with XPath:<\/p>\n<\/div>\n
\n\n- \n
Business Terms \u2192 UBL Elements<\/a><\/p>\n<\/li>\n- \n
- \n
- 1. What is XML Selector?<\/a>\n
- \n
- 1.1. XML Selector and XPath for UBL Invoice<\/a><\/li>\n
- 1.2. Issue with Selector
cac:PartyTaxScheme[cac:TaxScheme = \"VAT\"]<\/code><\/a><\/li>\n<\/ul>\n<\/li>\n- 2. Enhancing Open Peppol Standards with the Adoption of XPath<\/a>\n
- \n
- 2.1. The Benefits of Adopting XPath<\/a><\/li>\n
- 2.2. Recommendation to Open Peppol<\/a><\/li>\n<\/ul>\n<\/li>\n
- 3. Elements correctly defined in syntax binding through selector specification<\/a>\n
- \n
- 3.1. Selector for Additional Document Reference (DocumentTypeCode = 130)<\/a><\/li>\n
- 3.2. Selector for LINE OBJECT IDENTIFIER<\/a><\/li>\n<\/ul>\n<\/li>\n
- 4. Errors in Syntax Binding<\/a>\n
- \n
- 4.1. Issue with Selector for Additional Document Reference (DocumentTypeCode != 130)<\/a><\/li>\n
- 4.2. Issue with Selector for Party Identification (SEPA scheme)<\/a><\/li>\n
- 4.3. Selector for Party Tax Scheme (TaxScheme = \u201cVAT\u201d)<\/a><\/li>\n
- 4.4. Issue with Selector for Party Tax Scheme (Not Equal to \u201cVAT\u201d)<\/a><\/li>\n
- 4.5. Issue with Selector for Allowance Charge (ChargeIndicator = false)<\/a><\/li>\n
- 4.6. Issue with Selector for Allowance Charge (ChargeIndicator = true)<\/a><\/li>\n
- 4.7. Issue with Selector for Tax Total (Currency Equals Document Currency Code)<\/a><\/li>\n
- 4.8. Issue with Selector for Tax Total (Currency Equals Tax Currency Code)<\/a><\/li>\n
- 4.9. Issue with Selector for Document Reference (DocumentTypeCode != 130)<\/a><\/li>\n
- 4.10. Issue with Selector for Allowance Charge (ChargeIndicator = false)<\/a><\/li>\n
- 4.11. Issue with Selector for Allowance Charge (ChargeIndicator = true):<\/a><\/li>\n
- 4.12. Issue with no Selector for Allowance Charge (ChargeIndicator = false):<\/a><\/li>\n<\/ul>\n<\/li>\n
- 5. Inconsistency Between BIS and Syntax Binding<\/a>\n
- \n
- 5.1. PAYMENT CARD INFORMATION financial service network provider of the card<\/a><\/li>\n
- 5.2. Missing mandatory element cbc:LineID in DESPATCH REFERENCE<\/a><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/div>\n<\/div>\n
\n\n\n\nNobuyuki SAMBUICHI
\nISO\/TC295 Audit data services<\/a>\/SG1 Semantic model Convener<\/p>\n<\/div>\n\nThe comments provided address various issues related to the PEPPOL Business Interoperability Specifications (BIS) and syntax bindings in the context of invoice processing. These comments highlight inconsistencies, missing elements, and potential improvements. The suggestions range from defining new business terms to aligning values for specific elements. Additionally, there are proposals to include missing elements in examples and provide clarifications within the documentation. Overall, the comments aim to enhance the clarity and consistency of the specifications, ensuring smoother implementation and interoperability in invoice processing within the PEPPOL framework.<\/p>\n<\/div>\n<\/div>\n<\/div>\n
\n1. What is XML Selector?<\/h2>\n
\n\n1.1. XML Selector and XPath for UBL Invoice<\/h3>\n
\nXML selectors play a vital role in locating specific elements or nodes within an XML document. XPath, short for XML Path Language, serves as a powerful tool for navigating and querying XML documents, allowing for precise element pinpointing.
\nLet\u2019s consider a scenario where you have an XML representation of a UBL (Universal Business Language) invoice. In this case, your objective is to selectively identify \u201cAllowance\u201d elements, but exclusively those found at the document level (as opposed to the line item level) where the \u201cChargeIndicator\u201d attribute is set to \u201cfalse.\u201d
\nHere\u2019s an example of how to employ XPath to achieve this task:<\/p>\n<\/div>\n\n\n<?xml version=\u201c1.0\" encoding=\u201cUTF-8\u201d?>\r\n<Invoice xmlns=\u201curn:oasis:names:specification:ubl:schema:xsd:Invoice-2\"\r\n xmlns:cac=\u201curn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2\u201d\r\n xmlns:cbc=\u201curn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2\">\r\n <!-- ... other invoice elements ... -->\r\n <cac:AllowanceCharge>\r\n <cbc:ChargeIndicator>false<\/cbc:ChargeIndicator>\r\n <!-- ... other allowance charge details ... -->\r\n <\/cac:AllowanceCharge>\r\n <!-- ... other invoice elements ... -->\r\n<\/Invoice><\/code><\/pre>\n<\/div>\n<\/div>\n\nTo isolate the \u201cAllowance\u201d elements where the \u201cChargeIndicator\u201d is set to \u201cfalse,\u201d you can employ the following XPath expression:<\/p>\n<\/div>\n
\n\n\/\/cac:AllowanceCharge[cbc:ChargeIndicator = \u2018false\u2019]<\/code><\/pre>\n<\/div>\n<\/div>\n\nHere\u2019s a breakdown of this expression:
\n–\/\/<\/code> selects nodes from anywhere within the XML document.
\n–cac:AllowanceCharge<\/code> targets the \u201cAllowanceCharge\u201d elements within the XML.
\n–[cbc:ChargeIndicator = \u2018false\u2019]<\/code> serves as a predicate, filtering the \u201cAllowanceCharge\u201d elements based on the condition that the child element \u201cChargeIndicator\u201d possesses a text value of \u201cfalse.\u201d
\nNevertheless, it\u2019s essential to note that this selector retrieves both document-level and line item-level allowances. Should you wish to exclusively choose document-level \u201cAllowanceCharge\u201d elements where the \u201cChargeIndicator\u201d is set to \u201cfalse,\u201d you can refine your XPath expression to consider the specific context of these elements. Presuming that document-level \u201cAllowanceCharge\u201d elements are situated directly beneath the root \u201cInvoice\u201d element, the following XPath expression can be employed:<\/p>\n<\/div>\n\n\n\/Invoice\/cac:AllowanceCharge[cbc:ChargeIndicator = \u2018false\u2019]<\/code><\/pre>\n<\/div>\n<\/div>\n\nThis revised expression operates as follows:
\n–\/Invoice<\/code> pinpoints the root \u201cInvoice\u201d element.
\n–\/cac:AllowanceCharge[cbc:ChargeIndicator = \u2018false\u2019]<\/code> selectively picks the \u201cAllowanceCharge\u201d elements that are immediate children of the \u201cInvoice\u201d element and possess a \u201cChargeIndicator\u201d child element with a value of \u201cfalse.\u201d This assures the exclusive selection of document-level \u201cAllowanceCharge\u201d elements.<\/p>\n<\/div>\n<\/div>\n\n1.2. Issue with Selector
cac:PartyTaxScheme[cac:TaxScheme = \"VAT\"]<\/code><\/h3>\n\nIn the Syntax Binding definition table, there is a row defined as “PARTY TAX \u2022\u2022 cac:PartyTaxScheme [cac:TaxScheme = “VAT”]” just above IBT-031 Seller TAX identifier. The selector mentioned here,
[cac:TaxScheme = \"VAT\"]<\/code>, appears to be an attempt to identify elements where theTaxScheme<\/code> element, which is a complex type, is an element with the string value “VAT.” However, there is a fundamental issue with this selector. It arises from the fact thatTaxScheme<\/code> is not a simple text element but a complex type.<\/p>\n<\/div>\n\nIn XML, complex types typically contain child elements and attributes and do not have direct text content that can be compared using the
=<\/code> operator. Based on the description of the UBL XML structure, the relevant information seems to be within thecbc:ID<\/code> child element inside thecac:TaxScheme<\/code> complex type. Therefore, to accurately select elements based on the value ofcbc:ID<\/code> withincac:TaxScheme<\/code>, you need to first navigate to that child element and then compare its value.<\/p>\n<\/div>\n\nWhen specifying XPath in XML editing software like XML Spy, the elements specified by that XPath are displayed. However, with the following XPath defined based on the Syntax Binding table, the corresponding elements cannot be found:<\/p>\n<\/div>\n
\n\n\/Invoice\/cac:AccountingSupplierParty\/cac:Party\/cac:PartyTaxScheme[cac:TaxScheme = \"VAT\"]<\/code><\/pre>\n<\/div>\n<\/div>\n\n\n\n<\/div>\n<\/div>\n\nThe following is an example of how to adjust the XPath expression to select elements where the value of
cbc:ID<\/code> is “VAT”:<\/p>\n<\/div>\n\n\n\/Invoice\/cac:AccountingSupplierParty\/cac:Party\/cac:PartyTaxScheme[cac:TaxScheme\/cbc:ID = \"VAT\"]<\/code><\/pre>\n<\/div>\n<\/div>\n\n\n\n<\/div>\n<\/div>\n\nLet’s explain this modified expression:
\n–\/Invoice\/cac:AccountingSupplierParty\/cac:Party\/<\/code> selects from the descendant elements of the root element within the XML document, which iscac:Party<\/code> in this case.
\n–cac:PartyTaxScheme<\/code> identifies thecac:PartyTaxScheme<\/code> element.
\n–[cac:TaxScheme\/cbc:ID = \u2018VAT\u2019]<\/code> serves as a predicate that filters elements where thecbc:ID<\/code> grandchild element within thecac:TaxScheme<\/code> child element is equal to “VAT.”<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n2. Enhancing Open Peppol Standards with the Adoption of XPath<\/h2>\n
\n\nIn the context of CEN\/TC 16931-3-2, electronic invoices defined in EN-16,931-1 are mapped to UBL2.1. The correspondence is indicated in two tables, Table3 and Table4, delineating the relationship between the semantic model and XML path elements. Each table, normative and informative respectively, plays a distinct role in facilitating understanding and implementation.
\nTable3 and Table4 serve different yet complementary purposes in mapping the relationships between the electronic invoice specified in EN-16,931-1 and UBL2.1. Table3 helps in understanding which XML path elements correspond to the semantic model, providing a clear translation from the electronic invoice elements to their UBL2.1 counterparts. On the other hand, Table4 offers the reverse mapping, indicating how elements on the XML paths correspond to items in the semantic model. Having both tables ensures that users can easily cross-reference and validate the mappings in both directions.<\/p>\n<\/div>\n\n\n
\n\n\n<\/div>\n<\/div>\n\n\n\n<\/div>\n<\/div>\n\n\n\n<\/div>\n<\/div>\nThe following is omitted.\n<\/p><\/blockquote>\n
\n— CEN\/TS 16931-3-2
\nTable 3<\/cite>\n<\/div>\n<\/div>\n\n\n
\n\n\n<\/div>\n<\/div>\n\n\n\n<\/div>\n<\/div>\n\n\n\n<\/div>\n<\/div>\nThe following is omitted.\n<\/p><\/blockquote>\n
\n— CEN\/TS 16931-3-2
\nTable 4<\/cite>\n<\/div>\n<\/div>\n\nThe distinction between normative and informative in the context of Table3 and Table4 is essential. Table3 is normative, meaning it’s a fundamental part of the standard, essential for ensuring consistent and correct implementations of the electronic invoice mappings to UBL2.1. Table4, being informative, serves as a reference and aids in understanding the mappings but isn’t mandatory for implementation. It’s a guide to assist users in interpreting and applying the mappings, enhancing their comprehension of the relationships between the electronic invoice and UBL2.1 elements.<\/p>\n<\/div>\n
\n2.1. The Benefits of Adopting XPath<\/h3>\n
\nHowever, there\u2019s room for refinement in this approach to standardization. Specifically, adopting XPath in defining XML elements, as opposed to paths, could enable more efficient and accurate mapping.<\/p>\n<\/div>\n
\nIn Table3, the BT-18 Invoiced object identifier has a specified rule noted as “with cbc:DocumentTypeCode = 130” in the text field. This implies that the path includes a descriptive rule that requires human interpretation to be converted into a program. This process can be time-consuming and introduces the risk of varied interpretations and errors.
\nIf the definition were provided in XPath, it would significantly reduce the need for manual interpretation and enable more efficient data processing. XPath is a query language for selecting elements and attributes in an XML document, allowing for precise data extraction and manipulation. Utilizing XPath would enable computer programs to directly, accurately, and swiftly interpret and execute the data conversion process, bypassing the need for human interpretation. This enhancement ensures data consistency and minimizes issues arising from errors or varied interpretations.<\/p>\n<\/div>\n\nImplementing XPath offers manifold advantages. It simplifies the navigation of complex XML documents and efficiently locates and selects specific elements and attributes. This capability can render the mapping between electronic invoices and UBL2.1 more flexible and precise.<\/p>\n<\/div>\n<\/div>\n
\n2.2. Recommendation to Open Peppol<\/h3>\n
\nGiven the widespread adoption of Open Peppol standards across various industries globally, enhancing the accuracy and efficiency of these standards is paramount. Embracing XPath could elevate these standards, paving the way for broader and smoother adoption by organizations.<\/p>\n<\/div>\n
\nAs a first step, we strongly recommended the adoption of XPath to Open Peppol, and descriptions of the Selector have been added to the traditional path definitions. However, there is still room for improvement in terms of precision.<\/p>\n<\/div>\n
\nOn the following websites, you will find tables that have replaced the path definitions with XPath:<\/p>\n<\/div>\n
\n- \n
- \n
Business Terms \u2192 UBL Elements<\/a><\/p>\n<\/li>\n
- \n
- 5.2. Missing mandatory element cbc:LineID in DESPATCH REFERENCE<\/a><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/div>\n<\/div>\n
- 4.2. Issue with Selector for Party Identification (SEPA scheme)<\/a><\/li>\n
- 3.2. Selector for LINE OBJECT IDENTIFIER<\/a><\/li>\n<\/ul>\n<\/li>\n
- 2.2. Recommendation to Open Peppol<\/a><\/li>\n<\/ul>\n<\/li>\n
- 1.2. Issue with Selector
- 1.1. XML Selector and XPath for UBL Invoice<\/a><\/li>\n
![\"LineObjectIdentifier\"](\"https:\/\/www.sambuichi.jp\/wp-content\/uploads\/2023\/10\/LineObjectIdentifier.png\")
\n<\/div>\n<\/div>\n![\"AdditionalSupportingDocument\"](\"https:\/\/www.sambuichi.jp\/wp-content\/uploads\/2023\/10\/AdditionalSupportingDocument.png\")
\n<\/div>\n<\/div>\n