connectingeurope / einvoicing-en16931 Goto Github PK

According to EN 16931-1 BT-18=Invoiced object identifier (An identifier for an object on which the invoice is based, given by the Seller). It may be a subscription number, telephone number, meter point, vehicle, person etc., as applicable.
0..1 Scheme identifier =The identification scheme identifier of the Invoiced object identifierIf it may be not clear for the receiver what scheme is used for the identifier, a conditional scheme identifier should be used that shall be chosen from the UNTDID 1153 code list entries.

How BT-18 is mapped to UBL and which business rules should it respect?

@AndreasPvd please have a look at the following: the example files use e.g. the namespace URL urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100 whereas CII D16B uses to my understanding the namespace URL urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:20.
Can you please clarify what to use here. Thx.

I cannot see that the validations done on these rules in any way is checking for what the rules are stating, so my suggestion is to remove these rules. I do not see a need for validation rules, where we cannot validate the "intention" of the corresponding business rule.

The rule states
An Invoice that contains a line, a document level allowance or a document level charge where the Invoiced item VAT category code (BT-151, BT-95 or BT-102) is “Reverse charge” shall contain in the VAT breakdown (BG-23) exactly one VAT category code (BT-118) equal with "Reverse charge".

It does not seem that the validation checks for only one instance in TaxTotal/TaxSubtotal/TaxCategory.

It seem that the test for CL-01 is wrong. I used the rule via the kosit-validator and it said that the type code 380 (commercial invoice) ist wrong. But this is an allowed value for an invoice.
It seems that the test
test="((not(contains(normalize-space(.), ' 80 ... 935 ')) and contains(' ', concat(' ', normalize-space(.), ' '))))"
should be
test="((not(contains(normalize-space(.), ' ')) and contains(' 80 ... 935 ', concat(' ', normalize-space(.), ' '))))"
as the other tests, e.g. for CL-03 or CL-04.

The following rules has a context targeting an attribute:

• BR-CL-03
• BR-CL-23
• BR-CL-24

Those rules will not trigger when implementers use the official ISO Schematron stylesheets to generate the XSLT version.

Several of the VAT rules are having the following check:
[cac:TaxCategoryCode/cbc:ID='XX']

The element TaxCategoryCode is not existing in the mapping, please check all rules and change all to [cac:TaxCategory/cbc:ID='XX']

Rules are raised if the number of decimals is not the same (example 25.0 and 25.00). Please align these rules with the check done in BR-S-08.

Rule BR-E-10 is not existing in updated EN. Please remove rule from validation artefacts

Rule BR-S-03 and S-04 are checking if PartyLegalEntity/companyID is existing. But this should not be checked, as the rule is stating that VAT identifier(BT-31), Tax identifier (BT-32) or TaxRepresentative VAT identifier (BT-63) is present. No check against the legal entity should be done

Extend XML Validator with commandline flag to support a pre-compiled XSLT instead.

According to the latest UN/CEFACT 5305 codelist the correct VAT category codes should be

L = Canary Island Tax
M = Ceuta and Manilla Tax

http://www.unece.org/fileadmin/DAM/trade/untdid/d16b/tred/tred5305.htm

Please correct validation in all BR-IG and BR-IP rules to check for these two values.

Instance files created for ISO 20022 does not comply to scheme as there is something wrong in the instance files. This should be fixed.

I was just using the Java mapping from /edifact/validator/1INVOIC2ISOXML(JAVA).zip but the output is different than the checked in example file:

Checked in file EDIFACT_EXAMPLE1.xml (line 75)

		<G_SG3>
			<S_RFF>
				<C_C506>
					<D_1153>GN</D_1153>
					<D_1154>57151520</D_1154>
				</C_C506>
			</S_RFF>
		</G_SG3>
		<G_SG3>
			<S_RFF>
				<C_C506>
					<D_1153>VA</D_1153>
					<D_1154>NL8200.98.395.B.01</D_1154>
				</C_C506>
			</S_RFF>
		</G_SG3>

After mapping with the Java tool:

			<G_SG3/>
			<G_SG3/>

Anyone an idea??

The created XML fails XSD validation:

Starting validation against ERROR - [error] @ file:/D:/Entwicklung/git/validation/edifact/validator/../instance/EDIFACT_
EXAMPLE1.xml(76:12) [SAX] cvc-complex-type.2.4.b: Content des Elements 'G_SG3' ist nicht vollstõndig. '{S_RFF}' wird erw
artet. (org.xml.sax.SAXParseException: cvc-complex-type.2.4.b: Content des Elements 'G_SG3' ist nicht vollstõndig. '{S_R
FF}' wird erwartet.)
ERROR - [error] @ file:/D:/Entwicklung/git/validation/edifact/validator/../instance/EDIFACT_EXAMPLE1.xml(77:12) [SAX] cv
c-complex-type.2.4.b: Content des Elements 'G_SG3' ist nicht vollstõndig. '{S_RFF}' wird erwartet. (org.xml.sax.SAXParse
Exception: cvc-complex-type.2.4.b: Content des Elements 'G_SG3' ist nicht vollstõndig. '{S_RFF}' wird erwartet.)
ERROR - [error] @ file:/D:/Entwicklung/git/validation/edifact/validator/../instance/EDIFACT_EXAMPLE1.xml(95:12) [SAX] cv
c-complex-type.2.4.b: Content des Elements 'G_SG5' ist nicht vollstõndig. '{S_CTA}' wird erwartet. (org.xml.sax.SAXParse
Exception: cvc-complex-type.2.4.b: Content des Elements 'G_SG5' ist nicht vollstõndig. '{S_CTA}' wird erwartet.)
XSD validation done!

BR-CL-13 fires when valid value is used. Codelist check does not seem complete according to latest version of UNCL 4465. Values 98-104 seems missing, in addition to ZZZ

BR-CO-25 is not firing when Payable amount is negative

This is just one example for an invalid check which as I understood still refers back to an issue with the System function current#0 in EDIFACT\EN16931-EDIFACT-model.sch.

Problem:
When currently checking the EDIFACT_Examples as provided in the instance folders, then e.g. in Example 1 I get this issue:

  <error xsi:type="BAR">
     <description>[BR-10]-An Invoice shall have the Sum of Invoice line net amount.</description>
     <location>xml:1210:0</location>
     <test>G_SG28/S_MOA/C_C516[D_5025='79']/D_5004</test>
  </error>

1.) I get it 6 times - I think 1 would be sufficient?
2.) the amount is there - so why this is an error?
in EDIFACT: MOA+79:229.6
in XML transformation: <G_SG52>
<S_MOA>
<C_C516>
<D_5025>79</D_5025>
<D_5004>229.6</D_5004>
</C_C516>
</S_MOA>
</G_SG52>

In the EN it is stated that the VAT rate for IGIC and IPSI VAT should be zero or greater than zero. The validation rules for BR-IG-05, 06 and 07 (and the same for corresponding BR-IP rules) only allowes values greater than zero.

Please correct rule to ensure zero values are allowed as VAT rate for these categories.

I hope I'm not stupid but I looked several times on in the message to find the issue but couldn't find it.
There is just one net amount on line item and should be same as on total level (both 100).
What am I doing wrong? Why I do get:

<failed-assert id="BR-CO-10" location="/M_INVOIC[1]" test="G_SG52/S_MOA/C_C516[D_5025='79']/D_5004 = (round(sum(/M_INVOIC/G_SG27/G_SG28/S_MOA/C_C516[D_5025='203']/D_5004) * 10 * 10)div 100)" flag="fatal">
    <text>[BR-CO-10]-Sum of Invoice line net amount =
  Σ Invoice line net amount. </text>
</failed-assert>

message:
UNA:+.?*'
UNB+UNOW:4::7+4000001000005:14+4000001000005:14+20150109:1403+87846595'
UNH+1234+INVOIC:D:96A:UN:EAN008'
BGM+380+645643837+9'
DTM+137:20160712:102'
DTM+35:20161012:102'
ALI+++11'
RFF+AAU:2233'
DTM+171:20161011:102'
RFF+ON:4455'
DTM+171:20160610:102'
RFF+VN:8877'
DTM+171:20160712:102'
NAD+BY+5790000000005::9'
RFF+XA:DK10629845'
NAD+DP+5790002330278::9'
RFF+XA:DK23876588'
NAD+SU+5790000000012::9'
RFF+XA:DK10687672'
NAD+IV+5790002330322::9'
RFF+XA:DK98767890'
TAX+7+VAT+++:::25+S'
CUX+2:DKK:4'
PAT+3'
DTM+13:20161112:102'
ALC+C++++ADR'
MOA+8:20'
LIN+1++5776565423456:EN::'
QTY+47:50:KGM'
QTY+46:51:KGM'
QTY+192:1:KGM'
MOA+203:100'
PRI+AAA:20:::10:KGM'
TAX+7+VAT+3010::9DK++:::25+S'
MOA+124:25'
TAX+7+VAT+3010::9DK++:::25+S'
MOA+125:100'
UNS+S'
CNT+2:1'
MOA+79:100'
MOA+86:275'
MOA+125:220'
MOA+131:20'
MOA+176:55'
TAX+7+VAT+3031::9DK++:::25+S'
MOA+124:55'
MOA+125:220'
UNT+49+1234'
UNZ+1+12115118'

The rule BR-CO-09 is stating:
"The Seller VAT identifier, Seller tax representative VAT identifier, Buyer VAT identifier shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’. "

However, the validation rule is checking that the prefix is the same as country code for the party, I am not sure that will allways be the case. Suggest to change validation to check only that the prefix is from ISO 3166-1 alpha-2

In validation/ubl/schematron/UBL/EN16931-UBL-model.sch there are BR-O-02, BR-O-03, BR-O-04 which forbid the usage of Seller VAT ID or Seller tax representative VAT ID or Buyer VAT ID according to the rules defined in EN 16931-1:2017

"BR-O-2 “An Invoice that contains a line where the Invoiced item VAT category code (BT-151) is “Not subject to VAT” shall not contain the Seller's VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) or the Buyer's VAT identifier (BT-46)”.

Wondering why "shall not". "could not" probably is more appropriate.

This is not an issue of the schematron code. It is just to remember that a discussion about this topic could take place.

The same error as in OpenPEPPOL/peppol-bis#38 also applies to the UBL Schematrons in here.
Just add <ns prefix="xs" uri="http://www.w3.org/2001/XMLSchema"/> in the overall XSD to fix the issue.

For each technical rule an ID is required. Within the EN16931-CII-codes.sch the IDs (/pattern/rule/assert/@id) is missing.

Short question:
Shouldn't the code list checks for BR-CL-17 and BR-CL-18 not also contain e.g. "AA" and "S" according to https://www.unece.org/fileadmin/DAM/trade/untdid/d16b/tred/tred5305.htm ??

Thanks,
Philip

Hello,

we have found typo in mimeCode list:

<rule context="@mimeCode" flag="fatal"> <assert test="((. = 'application/pdf' or . = 'image/png' or . = 'image/jpeg' or . = 'text/csv' or . = 'application/vnd.openxmlformats-officedocument. spreadsheetml.sheet' or . = 'application/vnd.oasis.opendocument.spreadsheet'))" id="BR-CL-24" flag="fatal">[BR-CL-24]-For Mime code in attribute use MIMEMediaType.</assert> </rule>

There is an extra space in "application/vnd.openxmlformats-officedocument. spreadsheetml.sheet"
Small one, but needs correction
BR

The example files have errors (and I will fix them - just for documentation):

CII_business_example_01.xml

• Character set of special German Umlauts was broken
• [BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’.
  • replaced 37/302/30168 with DE37/302/30168

CII_business_example_02.xml

• [BR-05]-An Invoice shall have an Invoice currency code (BT-5).
  • Changed <ram:InvoiceCurrencyCode></ram:InvoiceCurrencyCode> to <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
• [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 problem here is, that the applicable tax rate is sometimes given as 19 and sometimes as 19.00 which is considered different by the rules. Unifying all to 19.00
• [BR-DEC-01]-The allowed maximum number of decimals for the Document level allowance amount (BT-92) is 2.
  • Changed <ram:ActualAmount>0.0000</ram:ActualAmount> to <ram:ActualAmount>0.00</ram:ActualAmount>
• [BR-S-06]-In a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is "Standard rated" the Document level allowance VAT rate (BT-96) shall be greater than zero.
  • Changed <ram:RateApplicablePercent>0.00</ram:RateApplicablePercent> to <ram:RateApplicablePercent>19.00</ram:RateApplicablePercent>
• [BR-15]-An Invoice shall have the Amount due for payment (BT-115).
  • Added <ram:DuePayableAmount>11.90</ram:DuePayableAmount>
• [BR-CO-11]-Sum of allowances on document level (BT-107) = Σ Document level allowance amount (BT-92).
  • Added <ram:AllowanceTotalAmount>0.00</ram:AllowanceTotalAmount>
• [BR-CO-15]-Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110).
  • Changed currencyID="" to currencyID="EUR"

CII_example1.xml

• [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).
  • This requires a change in the rules because of rounding errors. Instead of sum (...) we need to use round (sum (...) * 10 * 10) div 100 to ensure exactly 2 decimal digits are present. (see commit below)

CII_example2.xml

• [BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’.
  • Replaced 123456789MVA with NO123456789MVA
  • Replaced 987654321MVA with NO987654321MVA
  • Replaced 967611265MVA with NO967611265MVA

CII_example5.xml

• [BR-62]-The Seller electronic address (BT-34) shall have a Scheme identifier.
  • added schemeID="email"
• [BR-63]-The Buyer electronic address (BT-49) shall have a Scheme identifier.
  • added schemeID="email"
• [CII-DT-018] - TypeCode should not be present
  • removed <ram:TypeCode>...</ram:TypeCode>

CII_example6.xml

• [BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’.
  • Replaced 123456789MVA with DK123456789MVA

CII_example7.xml

• [BR-O-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is " Not subject to 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 “Not subject to VAT".
  • This is because the rule is invalid. The rules refers to VAT Category O (which means "services outside of tax") but the rules refer to and ram:RateApplicablePercent=ram:CategoryTradeTax/ram:RateApplicablePercent - removing the dependence to the applicable percentage solves the issue
  • The second commit down below fixes this rule error

The final check in these two rules are
or not(exists(//cac:ClassifiedTaxCategory[cbc:ID = 'AE']))

This should be changed to
or not (exists(//cac:AllowanceCharge[cbc:ChargeIndicator='false']/cac:TaxCategory[cbc:ID = 'AE']))

According to EN 16931-1 BT-21=Invoice note subject code (The subject of the textual note in BT-22)->
To be chosen from the entries in UNTDID 4451

How is this field mapped to UBL? Is the following example correct?

BT-21 -> <cbc:Note>#AAA#</cbc:Note>
where AAA= Goods item description in UNTDID 4451

It looks like BR-CL-19 is the business rule related to BT-21 but in EN16931-UBL-codes.sch it refers to Code allowance reason and in UBL\EN16931-UBL-model.sch it contains numbers instead of the 3 chars of UNTDID 4451.

Could you please have a check?

In the UBL rule BR-S-02 the TaxScheme ID is verified to be "VA", while it has always been "VAT"

Is it a typo or is it correct? Because now our nvoices with cac:TaxScheme/cbc:ID = 'VAT' are failing validation.

<param name="BR-S-02" value="(exists(//cac:ClassifiedTaxCategory[normalize-space(cbc:ID) = 'S']) and (exists(//cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme[cac:TaxScheme/cbc:ID = ('VA', 'FC')]/cbc:CompanyID) or exists(//cac:TaxRepresentativeParty/cac:PartyTaxScheme[cac:TaxScheme/cbc:ID = 'VA']/cbc:CompanyID))) or not(exists(//cac:ClassifiedTaxCategory[normalize-space(cbc:ID) = 'S']))"/>

Both rules have a check "or not(exists(//cac:ClassifiedTaxCategory[normalize-space(cbc:ID) = 'Z']))"/>" this should be cac:TaxCategory, as ClassifiedTaxCategory does not exist in AllowanceCharge

Rule does not trigger when deliver to country code is blank/empty element

Why does this check fails? the Account ID is there and if I even add a value for the NAD+SE_C088/3434 (=instition branch identifier) as mentioned in the schematron rule it still fails. B ut even if it would not fail, is the check really correct requiring the 3434?

edited sample string: FII+RB+SE1212341234123412+SEXDABCD:::TEST'

The validation rule for BR-CO-15 does not handle the TaxCurrency and DocumentCurrency correctly. Now there is a check if the count of TaxTotal is >1, it uses TaxAmount where @currencyID = EUR.

This will not allways be the case, the check should look for the value in DocumentCurrencyCode, and use the TaxTotal where @currencyID = DocumentCurrencyCode.

I added new unit test for this BR-CO-15-2

In the EN16931-UBL-codes.sch the check to find valid codes is using the normalize-space function. However, when we for the VAT rules perform checks/calculations based on a VAT category, there is no normalize-space function.

This results in that a file with
<cbc:ID> S</cbc:ID>

Will not be handled as standard rate "S". Example in most of the VAT rules (BR-S-09 as one example). Similar issues for PaymentMeans in rule BR-61 and there might be more.

In UBL validation there are [UBL-DT-01]-Amounts shall be decimal up to two fraction digits which raise the error when using more then 2 decimals on Item price discount (BT-147) and Item gross price (BT-148):

<cac:Price>
	<cbc:PriceAmount currencyID="HRK">0.1212</cbc:PriceAmount>
	<cbc:BaseQuantity unitCode="EA">1</cbc:BaseQuantity>
	<cac:AllowanceCharge>
		<cbc:ChargeIndicator>false</cbc:ChargeIndicator>
[UBL-DT-01]-Amounts shall be decimal up to two fraction digits 
		<cbc:Amount currencyID="HRK">0.0022</cbc:Amount>
[UBL-DT-01]-Amounts shall be decimal up to two fraction digits 
		<cbc:BaseAmount currencyID="HRK">0.1234</cbc:BaseAmount>
	</cac:AllowanceCharge>
</cac:Price>

According to the EN 16931-1 Semantic data model document, p. 93-94, Table 26 - Allowed number of decimals, there is no restriction on maximum allowed number of decimals for Item net price (BT-146), Item price discount (BT-147) and Item gross price (BT-148). However, in the same table, Invoice line net amount (BT-131), Invoice line allowance amount (BT-136) and base amount (BT-137), Invoice line charge amount (BT-141) and base amount (BT-142) are restricted to two decimal digits which is all right. Item net price can be more than 2 digits, but gross price and discount amount cannot.

The dilemma is if this is a validation issue or way of rounding Item prices and discounts.

Currently none of the existing codes of the UNTDID 1001 code list will be accepted. It seems that the correction which has been done in UBL regarding the document type code needs also to be done for the CII validation artefacts.

BR-61 does not fire when Payment means code is 30 or 57, and PayeeFinancialAccount/ID is missing. See unit test BR-61

The rule for BR-CL-12 should be rewritten I think. As the valid values have / in them, I think they must all be individually wrapped in ''. Example: .='text/csv' or .= 'application/pdf'

Rule does not trigger when Actual delivery date or delivery period is blank

When I check any of the currently available EDIfact instances in the downloaded version of the validator then I get for all 10 files the same kind of problem which stops the checking. See screenshot (check 1 line below the highlighted lines)

What is wrong here? The VAT rate seems to be greater then zero (=21). Sample string: TAX+7+VAT+++:::21+S'

<fired-rule context="/M_INVOIC/G_SG27[G_SG35/S_TAX/D_5305 = 'S']"/>
<failed-assert id="BR-S-05" location="/M_INVOIC/G_SG27[0]" test="C_C243/D_5278 &gt; 0" flag="fatal">
    <text>[BR-S-05]-In an Invoice line where the Invoice
  item VAT category code (BT-151) is "Standard rated" the Invoiced item VAT rate (BT-152) shall
  be greater than 0 (zero). </text>
</failed-assert>

rule BR-O-02 does not fire when expected, assume it is due to the "..or (not(//cac:AccountingCustomerParty...), should be "and" and not "or" I think

In validation/ubl/schematron/codelist/EN16931-UBL-codes.sch:

Why UNTDID 2475? The EN 16931-1:2017 for BT-8 refers to UNTDID 2005 (probably values could be Invoice document issue date –“3”, Delivery date, actual -“35”, Paid to date – “432”)

I tried to fill the PAI_4461 with several codes (53,58,60), but still get this error. How does this check work?
e.g.: PAI+::53'

The Business rule error text is misleading because there is an invoice currency, but CUX:3:EUR:18 might be expected and is missing
cen_edifact.EDIFACT_EXAMPLE1.report.xml
</G_SG2> <G_SG7><S_CUX><C_C504>
<D_6347>2</D_6347> <D_6345>EUR</D_6345>
</C_C504>
</S_CUX>
</G_SG7> <G_SG8>
[BR-05]-An Invoice shall have an Invoice currency code.
xml:2:0
G_SG7/S_CUX/C_C504[D_6347='3' and D_6343='18']/D_6345

e.g. Something like….Shall be used in combination with the Total VAT amount in accounting currency when the VAT accounting currency code differs from the Invoice currency code.

Rule BR-CO-17 triggers if TaxableAmount is negative, and tax percent = 0 (zero).

Example file 2 has this issue, and also updated unit test BR-CO-17 to include the same example.

Please correct validation to handle negative numbers multiplied by zero.

within CII-DT-018 (validation/cii/schematron/CII/EN16931-CII-syntax.sch) the following typo needs to be corrected: ram:TypCode -> ram:TypeCode

Rules in CII Schematron are for my understanding not correct. With respect to the EN 16931-1 an INVOICE NOTE group might occure 0..n times.

The following structure (attached you will find a complete document) seems to me conform to the syntax binding but leads to a warning during validation ([CII-SR-029] - IncludedNote should exist maximum once):

    <rsm:ExchangedDocument>
        <ram:ID>123456</ram:ID>
        <ram:TypeCode>380</ram:TypeCode>
        <ram:IssueDateTime>
            <udt:DateTimeString format="102">20160621</udt:DateTimeString>
        </ram:IssueDateTime>
        <ram:IncludedNote>
            <ram:Content>Bei Fragen zu Ihrer Rechnung wenden Sie sich bitte an unseren Kundenserivce. Sie erreichen uns per Email: […], Tel.: […] oder Fax: […]</ram:Content>
            <ram:SubjectCode>ADU</ram:SubjectCode>
        </ram:IncludedNote>
        <ram:IncludedNote>
            <ram:Content>Die Lieferung erfolgt aufgrund der AGB […] erhältlich unter […]. Auf Wunsch senden wir sie auch zu.</ram:Content>
            <ram:SubjectCode>ADU</ram:SubjectCode>
        </ram:IncludedNote>
        <ram:IncludedNote>
            <ram:Content>Hinweis gemäß § 33 BDSG: Kundendaten werden gespeichert.</ram:Content>
            <ram:SubjectCode>ADU</ram:SubjectCode>
        </ram:IncludedNote>
        <ram:IncludedNote>
            <ram:Content>Beschädigt eingehende Sendungen bitte sofort beim Spediteur bzw. Paketdienstleister reklamieren. Genehmigte Rücksendungen schicken Sie bitte mit den Unterlagen an: […]</ram:Content>
            <ram:SubjectCode>ADU</ram:SubjectCode>
        </ram:IncludedNote>
    </rsm:ExchangedDocument>

01.02a-INVOICE_uncefact.zip

E.g. the example instance 1 produces the following errors:

[[SVRLResourceError@0x545de5a4: ErrorLevel=FATAL_ERROR; ErrorFieldName=/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax[0]; ErrorLocation=[ResourceID=/test-files/cii/instance/CII_example1.xml]; ErrorText=[Text=[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-96) is “Standard rated” and the VAT rate (BT-152, BT-103, BT-96) equals the VAT category rate (BT-119). ]]; test=ram:BasisAmount = (round(sum(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:IncludedSupplyChainTradeLineItem/ram:SpecifiedLineTradeSettlement[ram:ApplicableTradeTax/ram:CategoryCode = 'S' and ram:RateApplicablePercent=ram:ApplicableTradeTax/ram:RateApplicablePercent]/ram:SpecifiedTradeSettlementLineMonetarySummation/ram:LineTotalAmount)1010)div 100) + (round(sum(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeAllowanceCharge[ram:ChargeIndicator/udt:Indicator='true' and ram:CategoryTradeTax/ram:CategoryCode='S' and ram:RateApplicablePercent=ram:CategoryTradeTax/ram:RateApplicablePercent]/ram:ActualAmount)1010) div 100) - (round(sum(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeAllowanceCharge[ram:ChargeIndicator/udt:Indicator='false' and ram:CategoryTradeTax/ram:CategoryCode='S' and ram:RateApplicablePercent=ram:CategoryTradeTax/ram:RateApplicablePercent]/ram:ActualAmount)1010) div 100)],

[[SVRLResourceError@0x61526469: ErrorLevel=FATAL_ERROR; ErrorFieldName=/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax[1]; ErrorLocation=[ResourceID=/test-files/cii/instance/CII_example1.xml]; ErrorText=[Text=[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-96) is “Standard rated” and the VAT rate (BT-152, BT-103, BT-96) equals the VAT category rate (BT-119). ]]; test=ram:BasisAmount = (round(sum(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:IncludedSupplyChainTradeLineItem/ram:SpecifiedLineTradeSettlement[ram:ApplicableTradeTax/ram:CategoryCode = 'S' and ram:RateApplicablePercent=ram:ApplicableTradeTax/ram:RateApplicablePercent]/ram:SpecifiedTradeSettlementLineMonetarySummation/ram:LineTotalAmount)1010)div 100) + (round(sum(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeAllowanceCharge[ram:ChargeIndicator/udt:Indicator='true' and ram:CategoryTradeTax/ram:CategoryCode='S' and ram:RateApplicablePercent=ram:CategoryTradeTax/ram:RateApplicablePercent]/ram:ActualAmount)1010) div 100) - (round(sum(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeAllowanceCharge[ram:ChargeIndicator/udt:Indicator='false' and ram:CategoryTradeTax/ram:CategoryCode='S' and ram:RateApplicablePercent=ram:CategoryTradeTax/ram:RateApplicablePercent]/ram:ActualAmount)1010) div 100)]]]

For rule BR-S-08, if there is a line with VAT rate = 25.0, the rule fires when TaxCategory says 25.

The rule should not fire just because the number of decimals is not equal, as the value 25.0 is the same as 25 and 25.00

Please see unit test BR-S-08-1, test no 2, which is not expected to fire, but it does.