Visits: 16
Feedback on JP PINT V1.0 Current State
- 1. What is XML Selector?
- 2. Enhancing Open Peppol Standards with the Adoption of XPath
- 3. Elements correctly defined in syntax binding through selector specification
- 4. Errors in Syntax Binding
- 4.1. Issue with Selector for Additional Document Reference (DocumentTypeCode != 130)
- 4.2. Issue with Selector for Party Identification (SEPA scheme)
- 4.3. Selector for Party Tax Scheme (TaxScheme = “VAT”)
- 4.4. Issue with Selector for Party Tax Scheme (Not Equal to “VAT”)
- 4.5. Issue with Selector for Allowance Charge (ChargeIndicator = false)
- 4.6. Issue with Selector for Allowance Charge (ChargeIndicator = true)
- 4.7. Issue with Selector for Tax Total (Currency Equals Document Currency Code)
- 4.8. Issue with Selector for Tax Total (Currency Equals Tax Currency Code)
- 4.9. Issue with Selector for Document Reference (DocumentTypeCode != 130)
- 4.10. Issue with Selector for Allowance Charge (ChargeIndicator = false)
- 4.11. Issue with Selector for Allowance Charge (ChargeIndicator = true):
- 4.12. Issue with no Selector for Allowance Charge (ChargeIndicator = false):
- 5. Inconsistency Between BIS and Syntax Binding
Nobuyuki SAMBUICHI
ISO/TC295 Audit data services/SG1 Semantic model Convener
The 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.
1. What is XML Selector?
1.1. XML Selector and XPath for UBL Invoice
XML 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.
Let’s 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 “Allowance” elements, but exclusively those found at the document level (as opposed to the line item level) where the “ChargeIndicator” attribute is set to “false.”
Here’s an example of how to employ XPath to achieve this task:
<?xml version=“1.0" encoding=“UTF-8”?>
<Invoice xmlns=“urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
xmlns:cac=“urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2”
xmlns:cbc=“urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
<!-- ... other invoice elements ... -->
<cac:AllowanceCharge>
<cbc:ChargeIndicator>false</cbc:ChargeIndicator>
<!-- ... other allowance charge details ... -->
</cac:AllowanceCharge>
<!-- ... other invoice elements ... -->
</Invoice>To isolate the “Allowance” elements where the “ChargeIndicator” is set to “false,” you can employ the following XPath expression:
//cac:AllowanceCharge[cbc:ChargeIndicator = ‘false’]Here’s a breakdown of this expression:
– // selects nodes from anywhere within the XML document.
– cac:AllowanceCharge targets the “AllowanceCharge” elements within the XML.
– [cbc:ChargeIndicator = ‘false’] serves as a predicate, filtering the “AllowanceCharge” elements based on the condition that the child element “ChargeIndicator” possesses a text value of “false.”
Nevertheless, it’s essential to note that this selector retrieves both document-level and line item-level allowances. Should you wish to exclusively choose document-level “AllowanceCharge” elements where the “ChargeIndicator” is set to “false,” you can refine your XPath expression to consider the specific context of these elements. Presuming that document-level “AllowanceCharge” elements are situated directly beneath the root “Invoice” element, the following XPath expression can be employed:
/Invoice/cac:AllowanceCharge[cbc:ChargeIndicator = ‘false’]This revised expression operates as follows:
– /Invoice pinpoints the root “Invoice” element.
– /cac:AllowanceCharge[cbc:ChargeIndicator = ‘false’] selectively picks the “AllowanceCharge” elements that are immediate children of the “Invoice” element and possess a “ChargeIndicator” child element with a value of “false.” This assures the exclusive selection of document-level “AllowanceCharge” elements.
1.2. Issue with Selector cac:PartyTaxScheme[cac:TaxScheme = "VAT"]
In the Syntax Binding definition table, there is a row defined as “PARTY TAX •• cac:PartyTaxScheme [cac:TaxScheme = “VAT”]” just above IBT-031 Seller TAX identifier. The selector mentioned here, [cac:TaxScheme = "VAT"], appears to be an attempt to identify elements where the TaxScheme 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 is not a simple text element but a complex type.
In XML, complex types typically contain child elements and attributes and do not have direct text content that can be compared using the = operator. Based on the description of the UBL XML structure, the relevant information seems to be within the cbc:ID child element inside the cac:TaxScheme complex type. Therefore, to accurately select elements based on the value of cbc:ID within cac:TaxScheme, you need to first navigate to that child element and then compare its value.
When 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:
/Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme[cac:TaxScheme = "VAT"]
The following is an example of how to adjust the XPath expression to select elements where the value of cbc:ID is “VAT”:
/Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme[cac:TaxScheme/cbc:ID = "VAT"]
Let’s explain this modified expression:
– /Invoice/cac:AccountingSupplierParty/cac:Party/ selects from the descendant elements of the root element within the XML document, which is cac:Party in this case.
– cac:PartyTaxScheme identifies the cac:PartyTaxScheme element.
– [cac:TaxScheme/cbc:ID = ‘VAT’] serves as a predicate that filters elements where the cbc:ID grandchild element within the cac:TaxScheme child element is equal to “VAT.”
2. Enhancing Open Peppol Standards with the Adoption of XPath
In 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.
Table3 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.
The following is omitted.
Table 3
The following is omitted.
Table 4
The 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.
2.1. The Benefits of Adopting XPath
However, there’s 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.
In 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.
If 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.
Implementing 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.
2.2. Recommendation to Open Peppol
Given 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.
As 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.
On the following websites, you will find tables that have replaced the path definitions with XPath:
3. Elements correctly defined in syntax binding through selector specification
3.1. Selector for Additional Document Reference (DocumentTypeCode = 130)
Additional document reference class:
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-AdditionalDocumentReference-1/
3.1.1. COMMENT
Status:
OK
Current Selector: [cbc:DocumentTypeCode = 130]
Implied XPath:
/Invoice/cac:AdditionalDocumentReference[cbc:DocumentTypeCode = 130]
3.2. Selector for LINE OBJECT IDENTIFIER
LINE OBJECT IDENTIFIER
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-InvoiceLine/cac-DocumentReference-2/
3.2.1. COMMENT
Status:
No problem detected; the selector correctly aims to select elements where the “DocumentTypeCode” is equal to 130.
Current Selector: [cbc:DocumentTypeCode = 130]
Implied XPath:
/Invoice/cac:InvoiceLine/cac:DocumentReference[cbc:DocumentTypeCode = 130]
4. Errors in Syntax Binding
4.1. Issue with Selector for Additional Document Reference (DocumentTypeCode != 130)
ADDITIONAL SUPPORTING DOCUMENTS
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-AdditionalDocumentReference-2/
4.1.1. COMMENT
Problem:
The definition of the cbc:DocumentTypeCode element is not listed in the syntax binding table, so the UBL 2.1 definition applies. The cbc:DocumentTypeCode element is not mandatory.
The original selector cbc:DocumentTypeCode != 130 suggests that it’s trying to select elements where the “DocumentTypeCode” is not equal to 130. However, there is a potential issue because it assumes that “cbc:DocumentTypeCode” may always be defined, which may not be the case in all instances.
This element is required(1..1) at the document level; however, it is optional(0..1) at the line item level.
If “cbc:DocumentTypeCode” is undefined, this selector could return no elements.
Current Selector: [cbc:DocumentTypeCode != 130]
Implied XPath:
/Invoice/cac:AdditionalDocumentReference[cbc:DocumentTypeCode != 130]
Revised XPath:
/Invoice/cac:AdditionalDocumentReference[not(cbc:DocumentTypeCode = 130)]
4.1.2. PROPOSED CHANGE
Revised selector: [not(cbc:DocumentTypeCode = 130)]
Elements not listed in the syntax binding table are generally interpreted as prohibited from use. The definition of the cbc:DocumentTypeCode element should be specified by including it in the syntax binding table, similar to line item details, to mandate the necessity of this element’s definition.
4.2. Issue with Selector for Party Identification (SEPA scheme)
Bank assigned creditor identifier
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-AccountingSupplierParty/cac-Party/cac-PartyIdentification-1/
4.2.1. COMMENT
Problem:
Incorrect usage of “cac:ID” without specifying the correct namespace “cbc:“.The “cbc:” prefix is required for “ID,” not “cac:“.
Current Selector: [cac:ID/@schemeID = “SEPA”]
Implied XPath:
/Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyIdentification[cac:ID/@schemeID = “SEPA”]
Revised XPath:
/Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyIdentification[cbc:ID/@schemeID = “SEPA”]
4.2.2. PROPOSED CHANGE
Revised selector: [cbc:ID/@schemeID = “SEPA”]
4.3. Selector for Party Tax Scheme (TaxScheme = “VAT”)
4.3.1. COMMENT
Problem:
Not specifying the child element for comparison within cac:TaxScheme.
Current Selector: [cac:TaxScheme = “VAT”]
Implied XPath:
/Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme[cac:TaxScheme = “VAT”]
Revised XPath:
/Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme[cac:TaxScheme/cbc:ID = “VAT”]
4.3.2. PROPOSED CHANGE
Revised selector: [cac:TaxScheme/cbc:ID = “VAT”]
4.4. Issue with Selector for Party Tax Scheme (Not Equal to “VAT”)
4.4.1. COMMENT
Problem:
Similar to the previous issue, not specifying the child element for comparison within cac:TaxScheme.
Current Selector: [cac:TaxScheme != “VAT”]
Implied XPath:
/invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme[cac:TaxScheme != “VAT”]
Revised XPath:
/Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme[cac:TaxScheme/cbc:ID != “VAT”]
4.4.2. PROPOSED CHANGE
Revised selector: [cac:TaxScheme/cbc:ID != “VAT”]
4.5. Issue with Selector for Allowance Charge (ChargeIndicator = false)
DOCUMENT LEVEL ALLOWANCES
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-AllowanceCharge-1/
4.5.1. COMMENT
Problem:
Missing double quotes around “false.” The original selector cbc:ChargeIndicator = false seems to be attempting to select elements where the “ChargeIndicator” is true.However, there’s a potential issue because it doesn’t compare with a string value “false.” If the “ChargeIndicator” is represented as a string, it’s important to use string comparison.
Current Selector: [cbc:ChargeIndicator = false]
Implied XPath:
/Invoice/cac:AllowanceCharge/[cbc:ChargeIndicator = false]
Revised XPath:
/Invoice/cac:AllowanceCharge[cbc:ChargeIndicator = “false”]
4.5.2. PROPOSED CHANGE
Revised selector: [cbc:ChargeIndicator = “false”]
4.6. Issue with Selector for Allowance Charge (ChargeIndicator = true)
DOCUMENT LEVEL CHARGES
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-AllowanceCharge-2/
4.6.1. COMMENT
Problem:
Missing double quotes around “true.” The original selector cbc:ChargeIndicator = true seems to be attempting to select elements where the “ChargeIndicator” is true.However, there’s a potential issue because it doesn’t compare with a string value “true.” If the “ChargeIndicator” is represented as a string, it’s important to use string comparison.
Current Selector: [cbc:ChargeIndicator = true]
Implied XPath:
/Invoice/cac:AllowanceCharge/[cbc:ChargeIndicator = true]
Revised XPath:
/Invoice/cac:AllowanceCharge[cbc:ChargeIndicator = “true”]
4.6.2. PROPOSED CHANGE
Revised selector: [cbc:ChargeIndicator = “true”]
4.7. Issue with Selector for Tax Total (Currency Equals Document Currency Code)
4.7.1. COMMENT
Problem:
The original selector cac:TaxTotal/TaxAmount/@currency = cbc:DocumentCurrencyCode attempts to compare the “currency” attribute within “TaxAmount” with the “DocumentCurrencyCode” from the root, which is not accessible in this manner. The correct context for comparison is not established, and it lacks proper namespaces (e.g., cac and cbc) in the selector.
a) TaxAmount/@currency suggests that you are attempting to access the “currency” attribute of the “TaxAmount” element.
b) cbc:DocumentCurrencyCode implies that you are trying to compare this attribute with the “cbc:DocumentCurrencyCode” at the root level.
However, the correct structure in the XML might be different, and this selector does not account for it. The actual structure could be:
<Invoice>
<cac:TaxTotal>
<cbc:TaxAmount currencyID=“DocumentCurrencyCode”>...</cbc:TaxAmount>
</cac:TaxTotal>
</Invoice>To correct this:
c) TaxAmount may have an attribute named currencyID, which stores the currency information.
d) TaxAmount requires namespace prefix cac:.
e) cbc:DocumentCurrencyCode should be accessed from the root of the document (i.e., /Invoice/cbc:DocumentCurrencyCode).
So, the revised selector becomes:
cac:TaxTotal[cbc:TaxAmount/@currencyID = /Invoice/cbc:DocumentCurrencyCode]
In this corrected selector:
– cac:TaxTotal[cbc:TaxAmount/@currencyID = /Invoice/cbc:DocumentCurrencyCode], you access the “cac:TaxAmount” element’s @currencyID attribute and compare it with the “cbc:DocumentCurrencyCode” at the root level, which is the intended behavior.
The change from @currency to @currencyID and the adjustment of the location ensure that you are correctly accessing and comparing the relevant values within the XML structure.
Current Selector: [cac:TaxTotal/TaxAmount/@currency = cbc:DocumentCurrencyCode]
Implied XPath:
/Invoice/cac:TaxTotal[cac:TaxTotal/TaxAmount/@currency = cbc:DocumentCurrencyCode]
Revised XPath:
/Invoice/cac:TaxTotal[cbc:TaxAmount/@currencyID=/Invoice/cbc:DocumentCurrencyCode]
4.7.2. PROPOSED CHANGE
Revised selector: [cbc:TaxAmount/@currencyID=/Invoice/cbc:DocumentCurrencyCode]
4.8. Issue with Selector for Tax Total (Currency Equals Tax Currency Code)
DOCUMENT TOTALS IN TAX ACCOUNTING CURRENCY
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-TaxTotal-2/
4.8.1. COMMENT
Problem:
a) The original selector cac:TaxTotal/TaxAmount/@currency = cbc:TaxCurrencyCode attempts to compare the “currency” attribute within “TaxAmount” with the “TaxCurrencyCode” from the root, which is not accessible in this manner. The correct context for comparison is not established, and it lacks proper namespaces (e.g., cac and cbc) in the selector.
a) TaxAmount/@currency suggests that you are attempting to access the “currency” attribute of the “TaxAmount” element.
b) cbc:DocumentCurrencyCode implies that you are trying to compare this attribute with the “cbc:TaxCurrencyCode” at the root level.
However, the correct structure in the XML might be different, and this selector does not account for it. The actual structure could be:
<Invoice>
<cac:TaxTotal>
<cbc:TaxAmount currencyID=“TaxCurrencyCode”>...</cbc:TaxAmount>
</cac:TaxTotal>
</Invoice>To correct this:
c) TaxAmount may have an attribute named currencyID, which stores the currency information.
d) TaxAmount requires namespace prefix cac:.
e) cbc:DocumentCurrencyCode should be accessed from the root of the document (i.e., /Invoice/cbc:DocumentCurrencyCode).
So, the revised selector becomes:
cac:TaxTotal[cbc:TaxAmount/@currencyID = /Invoice/cbc:DocumentCurrencyCode]
In this corrected selector:
– cac:TaxTotal[cbc:TaxAmount/@currencyID = /Invoice/cbc:DocumentCurrencyCode], you access the “cac:TaxAmount” element’s @currencyID attribute and compare it with the “cbc:TaxCurrencyCode” at the root level, which is the intended behavior.
The change from @currency to @currencyID, addition of cac: namspace prefix for ’TaxAmount`, and the adjustment of the location ensure that you are correctly accessing and comparing the relevant values within the XML structure.
Current Selector: [cac:TaxTotal/TaxAmount/@currency = cbc:TaxCurrencyCode]
Implied XPath:
/Invoice/cac:TaxTotal[cac:TaxTotal/TaxAmount/@currency = cbc:TaxCurrencyCode]
Revised XPath:
/Invoice/cac:TaxTotal[cbc:TaxAmount/@currencyID=/Invoice/cbc:TaxCurrencyCode]
4.8.2. PROPOSED CHANGE
Revised selector: [cbc:TaxAmount/@currencyID=/Invoice/cbc:TaxCurrencyCode]
4.9. Issue with Selector for Document Reference (DocumentTypeCode != 130)
LINE DOCUMENT REFERENCE
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-InvoiceLine/cac-DocumentReference-1/
4.9.1. COMMENT
Problem:
The original selector cbc:DocumentTypeCode != 130 suggests that it’s trying to select elements where the “DocumentTypeCode” is not equal to 130. However, there is a potential issue because it assumes that “cbc:DocumentTypeCode” may always be defined, which may not be the case in all instances.
This element is required(1..1) at the document level; however, it is optional(0..1) at the line item level.
If “cbc:DocumentTypeCode” is undefined, this selector could return no elements.
Current Selector: [cbc:DocumentTypeCode != 130]
Implied XPath:
/Invoice/cac:InvoiceLine/cac:DocumentReference[cbc:DocumentTypeCode != 130]
Revised XPath:
/Invoice/cac:InvoiceLine/cac:DocumentReference[not(cbc:DocumentTypeCode = 130)]
4.9.2. PROPOSED CHANGE
Revised selector: [not(cbc:DocumentTypeCode = 130)]
4.10. Issue with Selector for Allowance Charge (ChargeIndicator = false)
INVOICE LINE ALLOWANCES
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-InvoiceLine/cac-AllowanceCharge-1/
4.10.1. COMMENT
Problem:
The original selector cbc:ChargeIndicator = false appears to aim at selecting elements where the “ChargeIndicator” is false. However, there’s a potential issue because it doesn’t compare with a string value “false.” If the “ChargeIndicator” is represented as a string, it’s important to use string comparison.
Current Selector: [cbc:ChargeIndicator = false]
Implied XPath:
/Invoice/cac:InvoiceLine/cac:AllowanceCharge[cbc:ChargeIndicator = false]
Revised XPath:
/Invoice/cac:InvoiceLine/cac:AllowanceCharge[cbc:ChargeIndicator = “false”]
4.10.2. PROPOSED CHANGE
Reviced selector: [cbc:ChargeIndicator = “false”]
4.11. Issue with Selector for Allowance Charge (ChargeIndicator = true):
INVOICE LINE CHARGES
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-InvoiceLine/cac-AllowanceCharge-2/
4.11.1. COMMENT
Problem:
The original selector cbc:ChargeIndicator = true seems to be attempting to select elements where the “ChargeIndicator” is true. However, there’s a potential issue because it doesn’t compare with a string value “true.” If the “ChargeIndicator” is represented as a string, it’s important to use string comparison.
Current Selector: [cbc:ChargeIndicator = true]
Implied XPath:
/Invoice/cac:InvoiceLine/cac:AllowanceCharge[cbc:ChargeIndicator = true]
Revised XPath:
/Invoice/cac:InvoiceLine/cac:AllowanceCharge[cbc:ChargeIndicator = “true”]
4.11.2. PROPOSED CHANGE
Reviced selector: [cbc:ChargeIndicator = “true”]
4.12. Issue with no Selector for Allowance Charge (ChargeIndicator = false):
4.12.1. COMMENT
Problem:
No selector is defined for this context, but it’s necessary to specify a selector to accurately target elements within the “Price” element with ChargeIndicator=“false”.XPath is required for this purpose.
No selector is defined.
XPath Required:
/Invoice/cac:InvoiceLine/cac:Price/cac:AllowanceCharge[cbc:ChargeIndicator=“false”]
4.12.2. PROPOSED CHANGE
Selector Required: [cbc:ChargeIndicator=“false”]
5. Inconsistency Between BIS and Syntax Binding
5.1. PAYMENT CARD INFORMATION financial service network provider of the card
Page URLs:
– Syntax Binding:
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-PaymentMeans/cac-CardAccount/
– Business Information Specification (BIS):
https://docs.peppol.eu/poac/jp/pint-jp/bis/#_card_payment
==== COMMENT
There exists an inconsistency between the Business Information Specification (BIS) and the associated syntax binding regarding the usage of the cbc:networkID element within the context of PAYMENT CARD INFORMATION (IBG-18). The syntax binding mandates the presence of this element and specifies that it should be filled with the value “NA” when not mapped to a semantic business term. Conversely, in section 2.5.2 of the Card Payment explanation, it is indicated as “Mandatory” and used for identifying the financial service network provider of the card (e.g., VISA, MasterCard, American Express).
5.1.1. PROPOSED CHANGE
To address this inconsistency, we propose two potential solutions:
-
Define a New Business Term:
Introduce a new business term or semantic concept that explicitly signifies the intended purpose of the cbc:networkID element. This approach would allow applications to populate this element based on the context of their data, making its usage more meaningful. -
Value Modification:
Alternatively, consider modifying the value for the financial service network provider of the card from “VISA” to “NA” within the syntax binding. Simultaneously, the associated explanation in section 2.5.2 can be removed since the “NA” value would accurately represent cases where the element is not explicitly tied to a financial service network provider.
Implementing either of these changes would harmonize the interpretation and use of the cbc:networkID element between the BIS and the syntax binding.
5.2. Missing mandatory element cbc:LineID in DESPATCH REFERENCE
page URLs
– Syntax Binding DESPATCH REFERENCE
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-InvoiceLine/cac-DespatchLineReference/
– Business Information Specification (BIS) 2.3.5. Despatch and receipt advice references
https://docs.peppol.eu/poac/jp/pint-jp/bis/#_despatch_and_receipt_advice_references
5.2.1. COMMENT
Syntax inding requires cbc:LineID Despatch advice line. Syntax required item. Value shall be NA.
BIS example does not contain cbc:LineID.
5.2.2. PROPOSED CHANGE
Include cbc:LineID within an example with value NA and add explanation on this.
Here’s the refined text regarding the DESPATCH REFERENCE issue: **
==== Missing Mandatory Element cbc:LineID in DESPATCH REFERENCE
– Syntax Binding DESPATCH REFERENCE:
https://test-docs.peppol.eu/poacc/pint/2023-q4-dev/pint/trn-invoice/syntax/cac-InvoiceLine/cac-DespatchLineReference/
– Business Information Specification (BIS)
2.3.5. Despatch and Receipt Advice References:
https://test-docs.peppol.eu/poacc/pint/2023-q4-dev/pint/bis/#_despatch_and_receipt_advice_references
5.2.3. COMMENT
Within the context of DESPATCH REFERENCE, a notable inconsistency arises between the Syntax Binding and the associated Business Information Specification (BIS). The Syntax Binding mandates the inclusion of the cbc:LineID element, designating it as a required item with the value “NA” when not explicitly mapped to a semantic business term. However, upon reviewing the BIS example provided in section 2.3.5. Despatch and Receipt Advice References, it is evident that the cbc:LineID element is conspicuously absent
5.2.4. PROPOSED CHANGE
To rectify this discrepancy and ensure alignment between the Syntax Binding and the BIS, we propose the following actions:
-
Inclusion of cbc:LineID in Example
Incorporate the cbc:LineID element within the BIS example, demonstrating its usage with the value “NA.” This addition will serve to illustrate the required presence of cbc:LineID within the context of DESPATCH REFERENCE. -
Explanatory Context
Accompany the example with a concise explanation, clarifying the significance of cbc:LineID and its mandatory nature as per the Syntax Binding. This clarification will assist users in understanding the intended use of this element and its importance in compliant data exchange.
By implementing these proposed changes, the BIS and Syntax Binding will be harmonized, ensuring consistency in the representation and interpretation of the DESPATCH REFERENCE element across relevant documentation.
