peppolautoriteit-nl / validation Goto Github PK

View Code? Open in Web Editor NEW

23.0 23.0 12.0 9.83 MB

Contains all files related to validation of the simplerinvoicing xml files

License: MIT License

XSLT 96.06% Batchfile 0.03% Shell 0.05% HTML 3.86%

si-ubl xslt

validation's People

Contributors

Stargazers

Watchers

Forkers

noopi patrickvanamstel chai284477 dutchcoin juskoljo storecove moneybird tjeb jurgenrense nibsname wimkok juancho0056

validation's Issues

Problem with SI-UBL 1.2 validation rules - attribute context

Hi all,
@ThijsFTW identified a gap in validation of the SI 1.2 rules, depending on the validation engine used.
All of this is reported at phax/phive-rules#9
The main explanation is in this sub-post: phax/phive-rules#9 (comment)

It would be great, if you could fix this in the old SI rules, and check that the SI-2.0 rules don't have similar issues.

Thanks :)

NLCIUS validations are not done when whitespaces are used in CustomizationID

With:
cbc:CustomizationID
urn:cen.eu:en16931:2017#compliant#urn:fdc:nen.nl:nlcius:v1.0
</cbc:CustomizationID>
The -NL- validations are not done.
normalize-space is needed in
<xsl:variable name="is_SI-UBL-2.0"
select="$customizationID = 'urn:cen.eu:en16931:2017#compliant#urn:fdc:nen.nl:nlcius:v1.0'"/>

SI 2.0 RC1 test files

Hi guys,
some test files (Invoice and Credit note) for the 2.0 RC1 Schematrons would be super.
Thanks

1.2 Namespace prefix missing

Both SI-UBL-INV.sch and SI-UBL-PO.sch are missing the namespace declaration for XSD. Just add
<ns prefix="xs" uri="http://www.w3.org/2001/XMLSchema"/> into both.
They are required for calls like xs:decimal(...) and are added in upcoming OpenPEPPOL 3.4.0 artefacts as well.

Error in rule BR-S-08 for SI UBL 2.0 RC1 XSL

I just came across a small bug in the XSL file for SI UBL 2.0 RC1.

Rule BR-S-08 runs the following XPath query as test:

every $rate in round(cbc:Percent) satisfies (
  (
    exists(//cac:InvoiceLine) and (
      ../cbc:TaxableAmount = (
        sum(../../../cac:InvoiceLine[normalize-space(cac:Item/cac:ClassifiedTaxCategory/cbc:ID)='S'][cac:Item/cac:ClassifiedTaxCategory/round(cbc:Percent) =$rate]/xs:decimal(cbc:LineExtensionAmount)) +
        sum(../../../cac:AllowanceCharge[cbc:ChargeIndicator='true'][normalize-space(cac:TaxCategory/cbc:ID)='S'][cac:TaxCategory/round(cbc:Percent) = $rate]/xs:decimal(cbc:Amount)) -
        sum(../../../cac:AllowanceCharge[cbc:ChargeIndicator='false'][normalize-space(cac:TaxCategory/cbc:ID)='S'][cac:TaxCategory/round(cbc:Percent) = $rate]/xs:decimal(cbc:Amount))
      )
    )
  ) or (
    exists(//cac:CreditNoteLine) and (
      ../cbc:TaxableAmount = (
        sum(../../../cac:CreditNoteLine[normalize-space(cac:Item/cac:ClassifiedTaxCategory/cbc:ID)='S'][cac:Item/cac:ClassifiedTaxCategory/round(cbc:Percent) =$rate]/xs:decimal(cbc:LineExtensionAmount)) +
        sum(../../../cac:AllowanceCharge[cbc:ChargeIndicator='true'][normalize-space(cac:TaxCategory/cbc:ID)='S'][cac:TaxCategory/round(cbc:Percent) = $rate]/xs:decimal(cbc:Amount)) -
        sum(../../../cac:AllowanceCharge[cbc:ChargeIndicator='false'][normalize-space(cac:TaxCategory/cbc:ID)='S'][cac:TaxCategory/round(cbc:Percent) = $rate]/xs:decimal(cbc:Amount))
      )
    )
  )
)

in the context of /xmlns:Invoice/cac:InvoiceLine/cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory.

The path traversal in the sum parts does not go high enough. For example the line sum(../../../cac:InvoiceLine[ ... is translated to sum(/xmlns:Invoice/cac:InvoiceLine/cac:InvoiceLine[ ... which ofcourse does not give the expected results, causing the rule to always fail.

Errors in good validation arteftacs

Hi!
I'm testing all good 1.2 files from https://github.com/SimplerInvoicing/testset, after fixing #4 and #5 locally and getting the following errors:

Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-BII2-T10-R034.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
  FATAL_ERROR [BIIRULE-T10-R022]-Prices of items MUST NOT be negative.
  FATAL_ERROR [BIIRULE-T10-R022]-Prices of items MUST NOT be negative.
  FATAL_ERROR [BIIRULE-T10-R022]-Prices of items MUST NOT be negative.
  FATAL_ERROR [BIIRULE-T10-R018]-Invoice line amount MUST be equal to the price amount multiplied by the quantity plus charges minus allowances at line level
  FATAL_ERROR [BIIRULE-T10-R018]-Invoice line amount MUST be equal to the price amount multiplied by the quantity plus charges minus allowances at line level
  FATAL_ERROR [BIIRULE-T10-R018]-Invoice line amount MUST be equal to the price amount multiplied by the quantity plus charges minus allowances at line level
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-BII2-T10-R035.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
  FATAL_ERROR [SI-UBL-INV-R440]-Total payable amount in an invoice MUST NOT be negative
  FATAL_ERROR [BIIRULE-T10-R014]-Tax inclusive amount in an invoice MUST NOT be negative
  FATAL_ERROR [BIIRULE-T10-R018]-Invoice line amount MUST be equal to the price amount multiplied by the quantity plus charges minus allowances at line level
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-BII2-T10-R037.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
  FATAL_ERROR [SI-UBL-INV-R440]-Total payable amount in an invoice MUST NOT be negative
  FATAL_ERROR [BIIRULE-T10-R014]-Tax inclusive amount in an invoice MUST NOT be negative
  FATAL_ERROR [BIIRULE-T10-R018]-Invoice line amount MUST be equal to the price amount multiplied by the quantity plus charges minus allowances at line level
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-BII2-T10-R045.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-BII2-T10-R046.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-EUGEN-T10-R026.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-EUGEN-T10-R030.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-EUGEN-T10-R035.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-EUGEN-T10-R036.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
  FATAL_ERROR [SI-UBL-INV-R451]-Party Identifiers MUST use the PEPPOL PartyID list
  FATAL_ERROR [BIIRULE-T10-R027]-An invoice MUST contain the full name of the customer.
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-EUGEN-T10-R037.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-EUGEN-T10-R038.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-extension.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
  FATAL_ERROR [SI-UBL-INV-R445]-Currency Identifier MUST be in stated in the currency stated on header level.
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-full-multiple-currencies.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V12-INV-R026]-Currency Identifier MUST be stated in the currency as defined on header level
  FATAL_ERROR [SI-V12-INV-R026]-Currency Identifier MUST be stated in the currency as defined on header level
  FATAL_ERROR [SI-V12-INV-R026]-Currency Identifier MUST be stated in the currency as defined on header level
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
  FATAL_ERROR [SI-V11-INV-R026]-Currency Identifier MUST be stated in the currency as defined on header level
  FATAL_ERROR [SI-V11-INV-R026]-Currency Identifier MUST be stated in the currency as defined on header level
  FATAL_ERROR [SI-V11-INV-R026]-Currency Identifier MUST be stated in the currency as defined on header level
  FATAL_ERROR [SI-UBL-INV-R445]-Currency Identifier MUST be in stated in the currency stated on header level.
  FATAL_ERROR [BIIRULE-T10-R018]-Invoice line amount MUST be equal to the price amount multiplied by the quantity plus charges minus allowances at line level
  FATAL_ERROR [BIIRULE-T10-R018]-Invoice line amount MUST be equal to the price amount multiplied by the quantity plus charges minus allowances at line level
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-full-single-currency.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
  FATAL_ERROR [BIIRULE-T10-R018]-Invoice line amount MUST be equal to the price amount multiplied by the quantity plus charges minus allowances at line level
  FATAL_ERROR [BIIRULE-T10-R018]-Invoice line amount MUST be equal to the price amount multiplied by the quantity plus charges minus allowances at line level
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-full-tax-currency.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
  FATAL_ERROR [BIIRULE-T10-R018]-Invoice line amount MUST be equal to the price amount multiplied by the quantity plus charges minus allowances at line level
  FATAL_ERROR [BIIRULE-T10-R018]-Invoice line amount MUST be equal to the price amount multiplied by the quantity plus charges minus allowances at line level
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-full-tax-subcategory.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
  FATAL_ERROR [SI-UBL-INV-R451]-Party Identifiers MUST use the PEPPOL PartyID list
  FATAL_ERROR [SI-UBL-INV-R451]-Party Identifiers MUST use the PEPPOL PartyID list
  FATAL_ERROR [BIIRULE-T10-R018]-Invoice line amount MUST be equal to the price amount multiplied by the quantity plus charges minus allowances at line level
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-full.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
  FATAL_ERROR [SI-UBL-INV-R451]-Party Identifiers MUST use the PEPPOL PartyID list
  FATAL_ERROR [SI-UBL-INV-R451]-Party Identifiers MUST use the PEPPOL PartyID list
  FATAL_ERROR [BIIRULE-T10-R018]-Invoice line amount MUST be equal to the price amount multiplied by the quantity plus charges minus allowances at line level
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-minimal-corrective.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
  FATAL_ERROR [SI-UBL-INV-R440]-Total payable amount in an invoice MUST NOT be negative
  FATAL_ERROR [BIIRULE-T10-R014]-Tax inclusive amount in an invoice MUST NOT be negative
  FATAL_ERROR [BIIRULE-T10-R022]-Prices of items MUST NOT be negative.
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-minimal.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-reference.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-rounding-vat-1.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
  FATAL_ERROR [BIIRULE-T10-R013]-Invoice tax inclusive amount MUST equal the tax exclusive amount plus all tax total amounts and the rounding amount.
  FATAL_ERROR [BIIRULE-T10-R010]-Each tax total MUST equal the sum of the tax subcategory amounts.
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-si-extension-1.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-si-extension-2.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-si-extension-3.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-si-extension.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-single-item.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice
Validating /test-files/simplerinvoicing/SI-UBL-1.2/SI-UBL-INV-1.2-ok-taxes-ae.xml against 2 validation layers using org.simplerinvoicing:invoice:1.2
  FATAL_ERROR [SI-V11-INV-R200]-This XML instance is NOT tagged as an SI-UBL 1.1 invoice

I'm using Saxon HE 9.7....

Only use XSLT/XPath 1.0 compatible checks (get rid of xs:decimal)

Currently the schematron files contain conditions that make use of XPath 2.0 functions/types (xs:decimal) that require the resulting XSL files to be used with a XPath 2.0 compatible library. Unfortunately the support for XPath 2.0 is still very limited. Afaik the SAXON XSLT and XQuery processor in Java and .NET is the only mature library that does support it.

Since SimplerInvoicing requires everyone to validate their documents before sending them this means that everyone is required to add Java and Saxon to their ecosystem. This doesn't make sense if your application is running in Ruby or example.

We can improve the adoption of proper validation if we limit ourselves to XPath 1.0. As far as I can see xs:decimal is currently the only XPath 2.0-only feature being used. If this could be replaced, this issues should be fixed.

Consider creating a check on //cac:PaymentMeans/cac:PayeeFinancialAccount/cbc:ID

Number used for:
//cac:PaymentMeans[cbc:ID = 'GACCOUNT']/cac:PayeeFinancialAccount/cbc:ID
has a specific format (NL15ABNA09900000000).

See:
https://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/belastingdienst/zakelijk/internationaal/personeel/u_bent_niet_in_nederland_gevestigd_loonheffingen_inhouden/wanneer_moet_u_loonheffingen_inhouden1/u_bent_inhoudingsplichtig1/u_zendt_of_leent_personeel_uit_of_u_detacheert_personeel_in_nederland/g-rekening

'Een g-rekeningnummer bevat altijd de cijfers 099 op de 3 posities direct na de uit 4 letters bestaande bankcode.'

Optional cbc:CustomizationID is giving fatal when missing

XSLT
[BII2-T10-R001] An invoice MUST have a customization identifier

https://stpe.t4smm.nl/#/TreeView/Element_1528564882_00008632
BR-1 - An Invoice shall have a Specification identifier (BT-24).

Why is NL:VAT (9944) not allowed in BR-NL-10?

We are running into problems with sending invoices through Peppol using SI UBL 2.0 when our clients try to send to Dutch recipients having a NL:VAT (9944) identifier, e.g. ProRail with 9944:nl804170009b01.

Since the recipient is located in NL rule BR-NL-10 applies and requires that the recipient uses either NL:OINO (0190) or NL:KVK (0106). Why is NL:VAT not part of this list?

And if BR-NL-10 cannot be altered to allow NL:VAT, should any Peppol participant located in NL with NL:VAT (9944) identifier be forbidden to list the SI UBL 2.0 document type as supported document type?

Bug in BR-NL-10 test [SI-UBL-2.0-NLCIUS]

I suspect a bug in schematron/si-ubl-2.0/si-ubl-2.0-nlcius.sch.
More specifically in the test of BR-NL-10.

The way this test is implemented implies that the element in question is optional. This would be an incorrect interpretation of the BR-NL-10 as written in the NLCIUS spec. To be fair, the relevant text in the NLCIUS spec. is unclear, but the comment at BT-47 in the same document confirms that this element is meant to be mandatory

Wrong element checked for TypeCode of CreditNote

InvoiceTypeCode is one of 380, 381, 384, or 389, but in the case of 381, the document is a CreditNote. In those cases, InvoiceTypeCode is the wrong element to check, as it should be CreditNoteTypeCode. This is currently not checked correctly.

Typo in comment [SI-UBL-2.0-NLCIUS]

Found a type in schematron/si-ubl-2.0/si-ubl-2.0-nlcius.sch.
More specifically in the comment that addresses BR-NL-23.

BT-NL-23 should be BR-NL-23

PaymentMeansTypeCode

Op de STPEsite staat dat deze code voor Nederlandse Suppliers wat anders MAG zijn dan de standaard (https://stpe.t4smm.nl/#/TreeView/Element_1528564881_00357966)
In de validaties (BR-NL-12) staat dat je als NL-supplier deze codes VERPLICHT moet gebruiken.
Wat is juist?

Schematron validation for invoice line calculations

We've seen some issues with the calculations made in invoice lines, by softwarevendors that generate UBL invoices.

Here's an interesting fragment, that is OK according to the current schematron validations, but is NOT OK according to the rules in the UBL standard.

This is what is displayed to the end user on the PDF invoice:

Amount	Description	Price per unit	Total excl tax
157,94 liter	Brandstof	1,03	163,41

The UBL representation:

<cac:InvoiceLine>
    <cbc:ID>123456789</cbc:ID>
    <cbc:InvoicedQuantity unitCode="C62" unitCodeListID="UNECERec20">157.94</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">163.41</cbc:LineExtensionAmount>
    <cac:TaxTotal>
      <cbc:TaxAmount currencyID="EUR">34.32</cbc:TaxAmount>
      <cac:TaxSubtotal>
        <cbc:TaxableAmount currencyID="EUR">163.41</cbc:TaxableAmount>
        <cbc:TaxAmount currencyID="EUR">34.32</cbc:TaxAmount>
        <cac:TaxCategory>
          <cbc:ID schemeAgencyID="6" schemeID="UNCL5305">S</cbc:ID>
          <cbc:Percent>21</cbc:Percent>
          <cac:TaxScheme>
            <cbc:ID schemeAgencyID="6" schemeID="UN/ECE 5153">VAT</cbc:ID>
          </cac:TaxScheme>
        </cac:TaxCategory>
      </cac:TaxSubtotal>
    </cac:TaxTotal>
    <cac:Item>
      <cbc:Description>Brandstof</cbc:Description>
      <cbc:Name>Brandstof</cbc:Name>
      <cac:ClassifiedTaxCategory>
        <cbc:ID schemeID="UN/ECE 5305" schemeAgencyID="6">S</cbc:ID>
        <cbc:Percent>21</cbc:Percent>
        <cac:TaxScheme>
          <cbc:ID schemeAgencyID="6" schemeID="UN/ECE 5153">VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
    <cac:Price>
      <cbc:PriceAmount currencyID="EUR">1.03</cbc:PriceAmount>
    </cac:Price>
  </cac:InvoiceLine>

What's wrong?

Well, many vendors just use <cbc:LineExtensionAmount currencyID="EUR">163.41</cbc:LineExtensionAmount> and process 163,41 in the bookkeeping software.

We don't, because we want to give the end user the ability to decide if certain amount belongs may not belong in their administration (it's quite good possible that you want to split up a desired amount for private usage).

That's why we display the following in the user interface:

And, as you can see, there is something wrong here because 157,94 x 1,03 isn't equal to 163,41. In this case the vendor should have used amount with 4 decimals instead of two (http://docs.peppol.eu/poacc/billing/3.0/bis/#_unit_price_amount).

Also stated in http://docs.peppol.eu/poacc/billing/3.0/bis/#lineamount-calc.

I would love to see more stricter schematron validations for this.

Missing flag for some rules

Hi, is it correct for some rules to omit <xsl:attribute name="flag">...</xsl:attribute>, SI-V12-INV-R214 is the example?

Issue with 1.2 Schematron rule

pattern PEPPOL12-UBL-T10
rule <rule context="//*[contains(name(),'Quantity')]" /> contains no assertions

The source is located in file v1.2\si-invoice\PEPPOL\abstract\OPENPEPPOL-T10.sch:
Change from

  <rule context="$Unit_Code">
    <!--<assert test="$EUGEN-T10-R030" flag="fatal" id="EUGEN-T10-R030">[EUGEN-T10-R030]-A unit code attribute MUST have a unit code list identifier attribute 'UNECERec20'.</assert>-->
  </rule>

<!--
  <rule context="$Unit_Code">
    <assert test="$EUGEN-T10-R030" flag="fatal" id="EUGEN-T10-R030">[EUGEN-T10-R030]-A unit code attribute MUST have a unit code list identifier attribute 'UNECERec20'.</assert>
  </rule>
-->

PartyId validation like PEPPOL-COMMON-R041 for OINO and KVK

It would be nice to add validation rules for the value of 0190 (OINO) and 0106 (KVK) to the NLCIUS and BISv3 validation artifacts.

For example: https://docs.peppol.eu/poacc/billing/3.0/2023-Q4/rules/ubl-peppol/PEPPOL-COMMON-R041/

A mistake like this: <cbc:ID schemeID=”0190”>0190.00000000000000000000</cbc:ID> will then be avoided.

Question on November 2023 release

Hi @tjeb quick question on the https://github.com/peppolautoriteit-nl/validation/releases/tag/2023-11-29 release: do I understand you correctly that only the underlying EN rules were updated but the SimplerInvoicing rules are not updated??

However, why haven't the version numbers not changed compared to the May 2023 release?

Thanks

Please update SI-UBL-INV.XSL and SI-UBL-CRE.XSL

It seems that only SCH files are updated in 1.1 and 1.1_no_empty_rules branches

Please specify the license

Hi Rik!
Please specify the license under which these artefacts are available :)
Best is to create a file "LICENSE.txt" in the project root folder.
See https://help.github.com/articles/licensing-a-repository/ for further details.
Thanks, Philip

BR--05 BR--06 BR--07 BR--09 fail on negative zero

Just came across an edge case. There are a couple of PEPPOL BIS Billing rules that fail on a negative zero (-0.0), e.g. BR-AE-09 with <xsl:when test="../cbc:TaxAmount = 0"/>. Imho these rules are unnecessary strict and negative zeros should be accepted.

These rules are affected:

BR-AE-05
BR-AE-06
BR-AE-07
BR-AE-09
BR-E-05
BR-E-06
BR-E-07
BR-E-09
BR-G-05
BR-G-06
BR-G-07
BR-G-09
BR-IC-09
BR-IC-06
BR-IC-07
BR-IC-05
BR-O-09
BR-Z-09
BR-Z-06
BR-Z-07
BR-Z-05

Code BR-GA-0 is not in error text in si-ubl-2.0-ext-gaccount.sch

Other error text contain the errorcode. But not for BR-GA-0

Mimecode rejected in SI1.2 xslt but listed in http://www.iana.org/assignments/media-types/media-types.xhtml

path: si:Invoice/si:AdditionalDocumentReference/si:Attachment/si:EmbeddedDocumentBinaryObject/@mimecode
May containg codes from http://www.iana.org/assignments/media-types/media-types.xhtml

But fatal Error: [CL-T10-R008]-For Mime code in attribute use MIMEMediaType. is thrown for mimeCode="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"

Is the list in XSLT up to date?

Is SI-UBL-INV-STRICT.SCH still needed with 1.2?

As far as I noticed, the default for 1.2 is the previous "strict" mode from 1.1 - so no need to keep this file right?

Make 'contains' of CustomizationID in si-ubl-2.0-nlcius.sch

The construction below does not work for the SETU Invoice.

<let name="is_SI-UBL-2.0" value="$customizationID = 'urn:cen.eu:en16931:2017#compliant#urn:fdc:nen.nl:nlcius:v1.0'" /> <let name="is_SI-UBL-2.0-ext-gaccount" value="$customizationID = 'urn:cen.eu:en16931:2017#compliant#urn:fdc:nen.nl:nlcius:v1.0#conformant#urn:fdc:nen.nl:gaccount:v1.0'" />

Therefore, please change it into the following:
<let name="is_SI-UBL-2.0" value="contains($customizationID, '#compliant#urn:fdc:nen.nl:nlcius:v1.0')" /> <let name="is_SI-UBL-2.0-ext-gaccount" value="contains($customizationID, '#conformant#urn:fdc:nen.nl:gaccount:v1.0')" />

Latest XSL files for v1.1

Would it be possible to have latest XSL files (both invoice and corrective invoice/credit note) available for v1.1 release?

Thanks,
Jussi Koljonen

Suggestion: include preprocessed Schematron file

Instead of copying the source Schematrons from https://github.com/ConnectingEurope/eInvoicing-EN16931/tree/master/cii/schematron and https://github.com/ConnectingEurope/eInvoicing-EN16931/tree/master/ubl/schematron you may use the "preprocessed" version instead - it contains all the resolved includes etc. and therefore compiles a lot quicker:

Bug in BR-NL-11 test [SI-UBL-2.0-NLCIUS]

I suspect a bug in schematron/si-ubl-2.0/si-ubl-2.0-nlcius.sch.
More specifically in the test of BR-NL-11.

The comparison operator should be >= instead of <= like it is now.
After all, the test is meant to check whether the PayableAmount is a positive amount or, if not, a PaymentMeans is specified.

Peppol BIS V3 NL-R-008 cross-border

Hi,

For Peppol BIS V3 the rule [NL-R-008]

For suppliers in the Netherlands, the payment means code cac:PaymentMeans/cbc:PaymentMeansCode) MUST be one of 30, 48, 49, 57, 58 or 59

triggers not only for invoices inside NL, but also for for invoices sent by an NL AccountingSupplierParty, but received by a non-NL AccountingCustomerParty.

Does it make sense for this rule to fire for cross-border invoices? The rule makes sense for NLCIUS (NL->NL) but not for Peppol BIS V3 IMO.

Ticket PEPPOL-8790 is also open with the OpenPeppol service desk for this.

Michael

cbc:PaymentMeansCode is checked against digit and not a string

For errors [BR-NL-12] and [BR-NL-31] a check is done with digits. This must be a string like used in error [BR-50].

Problem occurs with:
cac:PaymentMeans
cbc:PaymentMeansCode</cbc:PaymentMeansCode>

Minor errors in XSLT conversion bat script

Hello, I had to fix the batch file before being able to run it:

Reference to $INPUT_FILE should instead be %INPUT_FILE%
Reference to %file_name%.xsl should instead be %OUTPUT_FILE%
Redundant quotes in if not exist "%TMPDIR%" mkdir "%TMPDIR%"
The &&\ at the end of the line does not work in command prompt nor PowerShell (Windows 10)

In addition, the bat script could also remove the temporary folder (as done in the sh script):
@rmdir /Q /S %TMPDIR%

Feature request:

The EN validation artifacts do not check whether a Purchase order reference (BT-13) exists on invoice level when a Referenced purchase order line reference (BT-132) is used on line level.

I've brought this up with the people of the EN artifacts but they quickly dismissed it, see: ConnectingEurope/eInvoicing-EN16931#154

I suggest we add this rule check to our NLCIUS, to strengthen the validation service of NLCIUS compliant e-invoices.

Let's just deprecate SI-1.2. It's the only Peppol BIS V2 based (Invoice) format left on the earth.

Originally posted by @ri4a in phax/phive-rules#9 (comment)

And yes, I know the NPa is working on this.

Check for [BR-NL-7] is not done with string

cbc:InvoiceTypeCodeType is xsd:normalizedString.
. = 380 will give "FORG0001: invalid floating point value" if a string is used in cbc:InvoiceTypeCode and code will stop.

Possible solution . = '380'

Rarely possible to fulfill rule BR-NL-2

With the SI UBL 2.0 RC1 schematron we get alot of errors due to rule BR-NL-2:

[BR-NL-2] For suppliers in the Netherlands, the invoice MUST contain either the buyer reference (cbc:BuyerReference) or the order reference (cac:OrderReference/cbc:ID)

Having an order reference is a rare scenario. Most of the invoices sent by our users at Moneybird only have an invoice id. Are there any recommendations how to deal with this problem? If this rule makes it into the final version of SI UBL 2.0 it would mean we can only send a small ratio of invoices through SI.