itplr-kosit/validator-configuration-xrechnung

BR-DE-20 Incorrect Validation

playunits opened this issue · 3 comments

Validating a valid IBAN according results in a Failure with the BR-DE-20 Error Code.

The Problem is that in the Rule the modified IBAN is being converted to "xs:integer".
According to ISO/IEC 7064 in order to validate a IBAN it has to be converted to a decimal value e.g. "xs:decimal".

Example

IBAN: DE93420700240615192200

Incorrect Rule:

not(ram:TypeCode = '59') or matches(normalize-space(replace(ram:PayerPartyDebtorFinancialAccount/ram:IBANID, '([ \n\r\t\s])', '')), '^[A-Z]{2}[0-9]{2}[a-zA-Z0-9]{0,30}$') and xs:integer(string-join(for $cp in string-to-codepoints(concat(substring(normalize-space(replace(ram:PayerPartyDebtorFinancialAccount/ram:IBANID, '([ \n\r\t\s])', '')),5),upper-case(substring(normalize-space(replace(ram:PayerPartyDebtorFinancialAccount/ram:IBANID, '([ \n\r\t\s])', '')),1,2)),substring(normalize-space(replace(ram:PayerPartyDebtorFinancialAccount/ram:IBANID, '([ \n\r\t\s])', '')),3,2))) return (if($cp > 64) then $cp - 55 else $cp - 48),'')) mod 97 = 1

Results in false

Corrected Rule:

not(ram:TypeCode = '59') or matches(normalize-space(replace(ram:PayerPartyDebtorFinancialAccount/ram:IBANID, '([ \n\r\t\s])', '')), '^[A-Z]{2}[0-9]{2}[a-zA-Z0-9]{0,30}$') and xs:decimal(string-join(for $cp in string-to-codepoints(concat(substring(normalize-space(replace(ram:PayerPartyDebtorFinancialAccount/ram:IBANID, '([ \n\r\t\s])', '')),5),upper-case(substring(normalize-space(replace(ram:PayerPartyDebtorFinancialAccount/ram:IBANID, '([ \n\r\t\s])', '')),1,2)),substring(normalize-space(replace(ram:PayerPartyDebtorFinancialAccount/ram:IBANID, '([ \n\r\t\s])', '')),3,2))) return (if($cp > 64) then $cp - 55 else $cp - 48),'')) mod 97 = 1

Correctly results in true

Notice that the only changed element is from xs:integer to xs:decimal

Best Regards

Juri Scholz

phax commented

Thanks for pointing that out - that indeed sounds like a classical integer overflow

which version of xslt/xpath are you using? we cannot reproduce the error with xslt/xpath 2.0, because type promotion to xs:decimal occurs automatically in xslt/xpath 2.0

In addition the ISO Standard ISO/IEC 7064 does not make any statements on which variable types should be used. It only talks about calculation in the "decimal" system w.r.t to radix 10, which is not to be confused with a variable type named "decimal"