Error in Validation of Rule BR-E-08

[MatthiasHainz]

Hello together

we already contacted you once a time ago, because we came across a bug in the .xsl schema file which was used in the validation for EN-16931 conform invoices.
The error on that case was:
[BR-S-08]-For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is "Standard rated", the VAT category taxable amount (BT-116) in a VAT breakdown (BG-23) shall equal the sum of Invoice line net amounts (BT-131) plus the sum of document level charge amounts (BT-99) minus the sum of document level allowance amounts (BT-92) where the VAT category code (BT-151, BT-102, BT-95) is “Standard rated” and the VAT rate (BT-152, BT-103, BT-96) equals the VAT category rate (BT-119).

And it was due to a problem with comparisons between doubles during the validation of the document and was fixed by applying decimal-casts to the values before doing further calculation steps.

We now came across the same problem at another part in the validation process:
[BR-E-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Exempt from VAT" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are "Exempt from VAT".

The error is thrown even though the values in the invoice add up and the calculation done is correct when validated manually. We could solve the problem by applying manual decimal-casts to all values read from the document, as they are treated as doubles by default, which leads to errors in some cases.
The error.xml file is the correct invoice which is classified as faulty. You can review it to confirm the false behaviour.
The hits for (sum.txt includes a list of all the places, where we found the use of the sum() operator, which was involved in the error both times we reported it. However we think, that everywhere, where a numeric value is read from the document to do further calculations and comparisons is potentially at risk to raise an error even though the file is correct.

The solution.txt shows the formel for the calculation which wrongly raises an error at the top and the fixed formula from the first reported issue, which does not wrongly raise errors anymore on the bottom.

Data.zip

[oriol]

BR-E-applies now a slack of +/- 1 so I think it is solved.