Closed oriol closed 4 years ago
Hi @oriol , would it be possible to release a new version tomorrow or before new year?
I am asking, because I consider this and other fixes since last release pretty important and I am currently preparing new German CIUS release, which has to be published by Dec 31 and only integrates your release v1.3.0, currently.
Hi @rkottmann, the release of this minor versions depends on the CEF process and I guess it can be expected by mid January.
In the interim, you can use the latest commits that fix these issues and will be included in the next release.
It is solved, but does not work for XPATH 1.0:
you changed from every $rate in
to every $ rate in
> I'd change it to not have whitespace. It'll be more consistent.
it is fixed now, thanks for spotting.
On behalf of Samin Salemi
In our test phase, we have apparently encountered an error in the Schematron validation - unfortunately, some correct invoices are rejected. Since the „Zentrale Rechnungseingangsplattform des Bundes“ https://xrechnung.bund.de/ also uses this validator, we cannot solve the problem alone on our side.
The detail of the error: [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).
The expression BR-S-08 from the validation rule (from EN16931-CII-validation.xsl):
round(sum( /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:IncludedSupplyChainTradeLineItem/ram:SpecifiedLineTradeSettlement [ram:ApplicableTradeTax/ram:CategoryCode = 'S' and ram:ApplicableTradeTax/ram:RateApplicablePercent =19]/ram:SpecifiedTradeSettlementLineMonetarySummation/ram:LineTotalAmount) 10 10) div 100
round( sum(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeAllowanceCharge [ram:ChargeIndicator/udt:Indicator='true' and ram:CategoryTradeTax/ram:CategoryCode='S' andram:CategoryTradeTax/ram:RateApplicablePercent=19]/ram:ActualAmount) 10 10) div 100
round( sum(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeAllowanceCharge [ram:ChargeIndicator/udt:Indicator='false' and ram:CategoryTradeTax/ram:CategoryCode='S' andram:CategoryTradeTax/ram:RateApplicablePercent=19]/ram:ActualAmount) 10 10) div 100
xs:double 190.46999999999997 correct value 190.47
The reason is the sum () function, which returns the data type xs: double (https://www.data2type.de/xml-xslt-xslfo/xslt/xslt-and-xpath-referenz/alphabetische-liste/sum/). Floating-point representation of the xs: double subsequently leads to rounding errors. One possible solution would be an additional cast on decimal values.