Prüfregeln BR-CO-17 und BR-S-09 schließen sich bei negativen Werten aus
VoidTenshi opened this issue · 10 comments
Bei der Validierung einer XRechnung mit negativen "VAT category taxable amount (BT-116)" kommt es, je nach Rundung, zu einem Fehler durch BR-CO-17 oder BR-S-09. Mit den vorhandenen Werten lässt sich die XRechnung nicht validieren.
Hier die Fehlerberichte:
error.zip
May be fixed with ConnectingEurope/eInvoicing-EN16931#256 in release EN 1.3.5.
@VoidTenshi can you please provide us with a test file? Thank you
Here is a testfile for you.
Super danke - sorry fürs Englisch ;-)
Würden weitere Testdaten (oder was sonst?) helfen, diesen Fehler zu beheben? Vielen Dank....
Bei uns besteht mit dem KOSIT 1.4.1 der Fehler leider immer noch
[BR-CO-17]-VAT category tax amount (BT-117) = VAT category taxable amount (BT-116) x (VAT category rate (BT-119) / 100), rounded to two decimals.
Gibt es eine zusätzliche Regel, die ggf. mit eingebunden werden muss?
Vielleicht hilft diese Situation bei der Behebung des Problems:
Wenn ein gewisser Minusbetrag im Steuerbetrag steht, schlägt der Validator fehl. Die Rundungsregelungen im Kosit-Validator
widersprechen sich.
- Wenn die Original-Datei durch den Validator läuft, kommt folgende Fehlermeldung:
Pos | Code | Adj. Grad (Grad) | Text |
---|---|---|---|
val-sch.1.1 | BR-CO-17 | error | [BR-CO-17]-VAT category tax amount (BT-117) = VAT category taxable amount (BT-116) x (VAT category rate (BT-119) / 100), rounded to two decimals. |
Pfad: /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction[1]/ram:ApplicableHeaderTradeSettlement[1]/ram:ApplicableTradeTax[1] |
Wir rechnen für dieses Beispiel mit folgenden Werten:
- (BT-117) => VAT category tax amount => CalculatedAmount => -145.64 ( => Kategoriespezifischer Steuerbetrag)
- (BT-116) => VAT category taxable amount => BasisAmount => -766.50 ( => Steuerbasisbetrag)
- (BT-119) => VAT category rate => RateApplicablePercent => 19.00 ( => Kategoriespezifischer Umsatzsteuersatz)
Folgende Rechnung wurde versucht zu validieren:
[BR-CO-17]-VAT category tax amount (BT-117) | = VAT category taxable amount (BT-116) | x (VAT category rate (BT-119) / 100), rounded to two decimals. |
---|---|---|
VAT category tax amount | = VAT category taxable amount | x (VAT category rate / 100), rounded to two decimals. |
(BT-117) | = (BT-116) | x (BT-119 / 100) |
-145.64 | = -766.50 | x (19.00 / 100) |
Diese Rechnung macht mathematisch Sinn, wenn 0,635 auf 0,64 gerundet werden würde.
Wenn wir das ganze jetzt aber mit dem vorgesehenen XPath-Formeln berechnen taucht der Fehler auf.
XPath-Rechnung:
ram:CalculatedAmount = round(ram:BasisAmount * .[upper-case(ram:TypeCode) = 'VAT']/ram:RateApplicablePercent) div 100 +0 or not (.[upper-case(ram:TypeCode) = 'VAT']/ram:RateApplicablePercent)
round(-766.50 * .[upper-case(VAT) = 'VAT'] /19.00) div 100 +0 = Double='-145.63'
-145.64 = round(-766.50*.[upper-case(VAT) = 'VAT']/19.00) div 100 +0 or not (.[upper-case(VAT) = 'VAT']/19.00)= Boolean='false'
Bei der Rundung der XPath-Rechnung kommt -145.63 heraus und nicht -145.64.
- Wenn die -145.63 nun mit der -145.64 ersetzt wird kommt aber ein weiterer Fehler:
Pos | Code | Adj. Grad (Grad) | Text |
---|---|---|---|
val-sch.1.1 | BR-S-09 | error | [BR-S-09]-The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where VAT category code (BT-118) is "Standard rated" shall equal the VAT category taxable amount (BT-116) multiplied by the VAT category rate (BT-119). |
Pfad: /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction[1]/ram:ApplicableHeaderTradeSettlement[1]/ram:ApplicableTradeTax[1]/ram:CategoryCode[1] |
Wir rechnen mit folgenden Werten:
- (BT-117) => VAT category tax amount => CalculatedAmount => -145.63 ( => Kategoriespezifischer Steuerbetrag)
- (BT-116) => VAT category taxable amount => BasisAmount => -766.50 ( => Steuerbasisbetrag)
- (BT-119) => VAT category rate => RateApplicablePercent => 19.00 ( => Kategoriespezifischer Umsatzsteuersatz)
Folgende Rechnung wurde versucht zu validieren:
[BR-S-09]-The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where VAT category code (BT-118) is "Standard rated" | shall equal the VAT category taxable amount (BT-116) | multiplied by the VAT category rate (BT-119). |
---|---|---|
The VAT category tax amount | shall equal the VAT category taxable amount | multiplied by the VAT category rate. |
(BT-117) | = (BT-116) | x (BT-119) |
-145.63 | = -766.50 | x 19.00 |
Diese Rechnung ist mathematisch falsch, ist aber nicht ausschlaggebend, da alles mit XPath berechnet wird.
Wenn wir das ganze jetzt aber mit dem vorgesehenen XPath-Formeln berechnen taucht der Fehler auf.
XPath-Rechnung:
abs(xs:decimal(../ram:CalculatedAmount))= round(abs(xs:decimal(../ram:BasisAmount)) *../ram:RateApplicablePercent) div 100 +0
abs(xs:decimal(-145.63)) = Decimal='145.63'
round(abs(xs:decimal(-766.50)) * 19.00) div 100 + 0 = Double='145.64'
abs(xs:decimal(-145.63)) =round(abs(xs:decimal(-766.50)) * 19.00) div 100 + 0 = Boolean='false'
Bei dieser Rechnung wird nicht wie in der vorherigen Rechnung gerundet und somit taucht der Fehler auf.
Rechnung 2 berechnet den Wert 145.64, aber Rechnung 1 berechnet den Wert 145.63.
Die Rundungsregelungen, welche der Validator in den 2 Situationen nutzt sind verschieden und somit tauchen 2 verschiedene Fehler auf, welche sich gegenseitig blockieren.
Ich hoffe, dass diese Situation verständlich ist und vielleicht bei der Lösung des Problems helfen kann,
Auf Rückfragen antworte Ich gerne!
MfG
@rkottmann it seems this issue has been solved in the new release of XRechnung 2.1.1
It includes releases 1.3.5 and 1.3.6a from EN16931
https://github.com/ConnectingEurope/eInvoicing-EN16931/releases
Hey, das sind ja good news :)
Gut ding will Weile haben. Dann close ich mal mit Happy End 😄