Validation Issues due to floating point computations

[danielschneider]

We found several cases where the schema validation for XRechnung fails. After some debugging, the reason seems to be bad floating point operations.

Example

Rule BR-S-08: (EN16391-CII-Validation.xsl) Taxable Amount (BT-116) = 200.05 Sum of Invoice line net amounts (BT-131) = 185.76 Sum of document level charge amounts (BT-99) = 14.29 Sum of document level allowance amounts (BT-92) = 0

Computation: 200.05 === 185.76 + 14.29 - 0 -> 200.05 === 200.0499999999999 --> False

Our document is correct! The rule is correct. But the validation is incorrect. How can we handle this?

I am using: validationtool-dist-1.0.1-standalone validator-configuration-xrechnung_1.1_2018-08-31

[rkottmann]

Hi,

it is an issue in the Schematron rules from https://github.com/CenPC434/validation

and it seems that this error was already reported here https://github.com/CenPC434/validation/issues/74

Therefore, we are waiting for this fix and will then update to latest Schematron rules from CEN.

[apenski]

@rkottmann can you please move this issue to validator-configuration-xrechnung

[jstaerk]

We had two cases of roundinge errors as well (https://github.com/ZUGFeRD/ZUV/issues/22), I'm sure one of them was fixed by the CEN but I'm no longer sure about the second one.

[rkottmann]

Thx for the link, we will have look at this!

[webbasan]

I've got the same Problem, in our case currently with claiming violations of BR-CO-13 and BR-CO-15, for example:

[BR-CO-15]-Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110). Path: /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction[1]/ram:ApplicableHeaderTradeSettlement[1]/ram:SpecifiedTradeSettlementHeaderMonetarySummation[1]

Actual values:

            <!--BT-112-->
            <ram:GrandTotalAmount>87000.00</ram:GrandTotalAmount>

            <!--BT-109-->
            <ram:TaxBasisTotalAmount>75000.00</ram:TaxBasisTotalAmount>
            <!--BT-110-->
            <ram:TaxTotalAmount>12000.00</ram:TaxTotalAmount>

The main issue with this is, that this validator also runs on the receivers side and automatically rejects any XRechnung documents which produce these validation errors. We can disable these rules locally, but that doesn't help if the receiver doesn't do that also.

I just wonder why this happens so regurlarly for us and seemingly not so much for others? At least I would have expected a much more intense discussion of this bug if it would occur more widespread...

[rkottmann]

This is almost exclusivly an issue of the CEN rules https://github.com/ConnectingEurope/eInvoicing-EN16931 which this configuration is using. If you still have this issue, report it there.

If you have an example invoice with this issue I'd be happy to put it into our integration tests to track development of the CEN rules on this issue.

[phax]

May be related to https://github.com/ConnectingEurope/eInvoicing-EN16931/issues/253

@webbasan @danielschneider @jstaerk if you have any example files, please send them to us for integration test and support in getting the error fixed in the EN rules.

[jstaerk]

@phax Steffen Walther had reported BR-S-08 in ZF tracking but confirms that it was fixed in context of https://github.com/ConnectingEurope/eInvoicing-EN16931/issues/199 , he had also reported BR-Z-08 and submitted as https://github.com/ConnectingEurope/eInvoicing-EN16931/issues/254 : thanks for fixing that one as well. Any idea when 1.3.5 could be published? I'd love to update Mustangproject.

[phax]

Release 1.3.5 is available as a pre-release at https://github.com/ConnectingEurope/eInvoicing-EN16931/releases - if there are no further comments or backwards incompatibilites it will become "non-pre" this week.