In den Beispielen

• 02.01a-INVOICE_ubl.xml

• 02.02a-INVOICE_ubl.xml

• 03.01a-INVOICE_ubl.xml

• 03.02a-INVOICE_ubl.xml

sind zwar Angaben zu <cac:AdditionalDocumentReference> vorhanden, aber die eigentlichen Daten als Binärstrom fehlen. In der jeweiligen uncefact-Variante ist alles korrekt.

Hallo,

obwohl die Zeile

  <cac:PaymentTerms>
    <cbc:Note>#SKONTO#TAGE=14#PROZENT=0.00#BASISBETRAG=9371.25#</cbc:Note>
  </cac:PaymentTerms>

in meinen Augen richtig aussieht, wird im Prüfbericht die Fehlermeldung

[BR-DE-18] Skonto/Verzug Zeilen in CreditNote muessen diesem regulaerem Ausdruck entsprechen: #(SKONTO|VERZUG)#TAGE=([0-9]+#PROZENT=[0-9]+.[0-9]{2})(#BASISBETRAG=-?[0-9]+.[0-9]{2})?#$.Die Informationen zur Gewährung von Skonto oder zur Berechnung von Verzugszinsen (...)

ausgegeben.

Auch der Online-Validator "regex101" meint, dies sei ein "Full match": https://regex101.com/r/9GcDE8/2.

Der validationtool-1.4.0 mit validator-configuration-xrechnung_2.0.0 beanstandet die Zeile nicht.

Mach' ich etwas falsch?

Viele Grüße
Björn Winkler

An invoice with multiple invoice lines and at least one invoice line with SubInvoiceLines results in an false positive warning BR-DEX-02. The error does not occur when only one invoice line with SubInvoiceLines is used

Also a warningiUBL-CR-646 is raised that invoice should not include SubInvoiceLine. So far as I understand with "Spezifikation XRechnung Standard und Extension Version XRechnung 2.0.0 | Fassung vom 30.06.2020" SubInvoiceLine should be supported
Temp.zip

see their release https://github.com/CenPC434/validation/releases/tag/validation-1.2.2

Hi Dev Team,

when testing an UBL2.1 Xrechnung CreditNote with the following configuration:

validationtool-1.3.0
validator-configuration-xrechnung_2.0.0_2020-07-31

we get the warning:

[BR-DE-21] Das Element "Specification identifier" (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen.

The value in question looks like this in our document:

cbc:CustomizationIDurn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_2.0</cbc:CustomizationID>

The validator acutally wont even recognize the document if we insert anything else here. But the schema seems to check for xrechnung_1.2 and throws a warning if it does not find that value here. This doesn't seem to make sense.

Kind regards
Roman Gundacker
it20one e-invoicing GmbH

Hi,

we currently use the accept flag calculated by the validator in a webservice. The validator sets the flag to REJECTED if there is a failed assertion, even if it's only a warning

.anyMatch(FailedAssert.class::isInstance)

https://github.com/itplr-kosit/validator/blob/113f1c79264e751cf8a9779504034b7c6213adc0/src/main/java/de/kosit/validationtool/impl/tasks/ComputeAcceptanceAction.java#L71-L74

In the default-report.xml though, the calculation of the recommendation differs from the calculation of the validator. There, only real errors will lead to a reject recommendation. The invoice may contain warnings which are not taken into account here.

In the end the xml-report says "accept" although the report-result says "reject"

select="count(//rep:message[@level eq 'error'])"
select="count(//rep:message[rep:custom-level(.) eq 'error'])"

We are wondering if this discrepancy is intended, since the report-result and generated xml-report say something different.

For our use case we need a machine-readable response to invoice submitters. I am considering to use the generated reports for this purpose. I see there is a schema and even some schematron for the reports, which is great - thanks. I was wondering why the schema doesn't seem to be used however. It should be possible to create another scenario for the reports. I imagine the reason why it's not done is that there would need to be a report for the report? How about the identity transformation?

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
  <xsl:template match="@*|node()">
    <xsl:copy>
      <xsl:apply-templates select="@*|node()"/>
    </xsl:copy>
  </xsl:template>  
</xsl:stylesheet>

And also there needs to be a way to easily differentiate valid from invalid invoices. I've raised another issue for this.

@rkottmann quick question:
Is there a rule in filenames where I can quickly determine if it is a positive or a negative case?

Currently the following CII test files fail for me:

• cii-br-de-1-test-317-remove.xml
• cii-br-de-10-test-336-remove.xml
• cii-br-de-11-test-287-remove.xml
• cii-br-de-13-invalid-test-bg-17-bg-18-311-identity.xml
• cii-br-de-13-test-bg-17-292-remove.xml
• cii-br-de-13-test-bg-18-303-remove.xml
• cii-br-de-14-test-323-remove.xml
• cii-br-de-15-test-283-remove.xml
• cii-br-de-15-test-285-remove.xml
• cii-br-de-16-negative-tests-br-95-br-151-328-code-Z.xml
• cii-br-de-16-negative-tests-br-95-br-151-329-code-E.xml
• cii-br-de-16-negative-tests-br-95-br-151-330-code-AE.xml
• cii-br-de-16-negative-tests-br-95-br-151-331-code-K.xml
• cii-br-de-16-negative-tests-br-95-br-151-332-code-G.xml
• cii-br-de-16-negative-tests-br-95-br-151-333-code-L.xml
• cii-br-de-16-negative-tests-br-95-br-151-334-code-M.xml
• cii-br-de-16-tests-br-95-br-151-304-code-Z.xml
• cii-br-de-16-tests-br-95-br-151-305-code-E.xml
• cii-br-de-16-tests-br-95-br-151-306-code-AE.xml
• cii-br-de-16-tests-br-95-br-151-307-code-K.xml
• cii-br-de-16-tests-br-95-br-151-308-code-G.xml
• cii-br-de-16-tests-br-95-br-151-309-code-L.xml
• cii-br-de-16-tests-br-95-br-151-310-code-M.xml
• "cii-br-de-17-tests-339-code-326.xml",
• "cii-br-de-17-tests-340-code-380.xml",
• "cii-br-de-17-tests-341-code-384.xml",
• "cii-br-de-17-tests-342-code-389.xml",
• "cii-br-de-17-tests-343-code-381.xml",
• "cii-br-de-17-tests-344-code-875.xml",
• "cii-br-de-17-tests-345-code-876.xml",
• "cii-br-de-17-tests-346-code-877.xml",
• "cii-br-de-17-tests-347-code-383.xml",
• "cii-br-de-17-tests-348-code-527.xml",
• "cii-br-de-18-negative-test-280-identity.xml",
• "cii-br-de-18-negative-test-skonto-290-identity.xml",
• "cii-br-de-18-negative-test2-321-identity.xml",
• "cii-br-de-2-test-315-remove.xml",
• "cii-br-de-22-check-unique-file-name-test-uncefact-325-code-01_15_Anhang_02.pdf.xml",
• "cii-br-de-3-test-289-remove.xml",
• "cii-br-de-4-test-338-remove.xml",
• "cii-br-de-5-test-294-remove.xml",
• "cii-br-de-5-test2-327-remove.xml",
• "cii-br-de-6-test-277-remove.xml",
• "cii-br-de-7-test-313-remove.xml",
• "cii-br-de-8-test-279-remove.xml",
• "cii-br-de-9-test-320-remove.xml"

Please confirm this list is correct.

BG-20-00, BG-21-00 indicator ist mandatory.

Habe versehenlich das Beispiel 02.01a-INVOICE_uncefact.xml ohne ChargeIndicator validiert:

ApplicableHeaderTradeSettlement ...
            <ram:SpecifiedTradeAllowanceCharge>
<!-- ohne Indikator:
                <ram:ChargeIndicator>
                    <udt:Indicator>true</udt:Indicator>
                </ram:ChargeIndicator>
  -->

Und bin überrascht, dass das Beispiel als valide durchgeht!

... ohne Indicator:

Ich nutze: validationtool-1.3.0-standalone.jar

Version 1.3.0 of Kosit-Validators with scenario configuration 1.2.2_2019-12-30\scenarios.xml
does not validate the elements "udt:DateTimeString format="102""

According to
https://service.unece.org/trade/untdid/d96a/uncl/uncl2379.htm
format=102 specifies date time format YYYYMMDD.
However, no error is shown in the report if -- for example -- "DDMMYYYY" is used.
I think the validator should output an error if the datetime format is not correct according to the format specifier 102.

Hello,

I think that the latest released version of the schematron rules for the XRechnung version 2.0.0 did not update the expected cbc:CustomizationID value for credit notes. Version 1.4.0 of the rules look like this:

	    <!--ASSERT -->
      <xsl:choose>
         <xsl:when test="cbc:CustomizationID = 'urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_1.2'"/>
         <xsl:otherwise>
            <svrl:failed-assert xmlns:svrl="http://purl.oclc.org/dsdl/svrl"
                                test="cbc:CustomizationID = 'urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_1.2'">
               <xsl:attribute name="id">BR-DE-21</xsl:attribute>
               <xsl:attribute name="flag">warning</xsl:attribute>
               <xsl:attribute name="location">
                  <xsl:apply-templates select="." mode="schematron-select-full-path"/>
               </xsl:attribute>
               <svrl:text>[BR-DE-21] Das Element "Specification identifier" (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen.</svrl:text>
            </svrl:failed-assert>
         </xsl:otherwise>
      </xsl:choose>

The invoice test looks like this:

 <xsl:when test="cbc:CustomizationID = 'urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_2.0' or cbc:CustomizationID = 'urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_2.0#conformant#urn:xoev-de:kosit:extension:xrechnung_2.0'"/>
         <xsl:otherwise>
            <svrl:failed-assert xmlns:svrl="http://purl.oclc.org/dsdl/svrl"
                                test="cbc:CustomizationID = 'urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_2.0' or cbc:CustomizationID = 'urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_2.0#conformant#urn:xoev-de:kosit:extension:xrechnung_2.0'">

It would be amazing if a fixed version could be made public soon. We are currently updating our generation of XRechnung files to 2.0.0 and are relying on the validator to be sure that we are good to go ;-)

Greetings and best wishes from Berlin
Heiko

Does reverse charge (TAX Catory Code AE) work and is correct validated?
I cannot validate documents with Reverse Charge:

[BR-AE-02]-An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is “Reverse charge” shall contain the Seller VAT Identifier (BT-31), the Seller Tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) and/or the Buyer legal

[BR-AE-10]-A VAT Breakdown (BG-23) with VAT Category code (BT-118) "Reverse charge" shall have a VAT exemption reason code (BT-121), meaning "Reverse charge" or the VAT exemption reason text (BT-120) "Reverse charge" (or the equivalent standard text in another language).

[BR-AE-04]-An Invoice that contains a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is “Reverse charge” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) and/or the Buyer legal registration identifier (BT-47).

I have not found any errors in the file, considering the documentation.
Here is the xml code that is not being successfully validated:

<rsm:CrossIndustryInvoice xmlns:a="urn:un:unece:uncefact:data:standard:QualifiedDataType:100" xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100" xmlns:qdt="urn:un:unece:uncefact:data:standard:QualifiedDataType:100" xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">
rsm:ExchangedDocumentContext
ram:GuidelineSpecifiedDocumentContextParameter
ram:IDurn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_1.2</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>
rsm:ExchangedDocument
ram:ID18383</ram:ID>
ram:TypeCode380</ram:TypeCode>
ram:IssueDateTime
<udt:DateTimeString format="102">20201127</udt:DateTimeString>
</ram:IssueDateTime>
</rsm:ExchangedDocument>
rsm:SupplyChainTradeTransaction
ram:IncludedSupplyChainTradeLineItem
ram:AssociatedDocumentLineDocument
ram:LineID1</ram:LineID>
</ram:AssociatedDocumentLineDocument>
ram:SpecifiedTradeProduct
ram:SellerAssignedID1</ram:SellerAssignedID>
ram:NameHSW-Tür Instandsetzung</ram:Name>
</ram:SpecifiedTradeProduct>
ram:SpecifiedLineTradeAgreement
ram:GrossPriceProductTradePrice
ram:ChargeAmount52.00</ram:ChargeAmount>
</ram:GrossPriceProductTradePrice>
ram:NetPriceProductTradePrice
ram:ChargeAmount52.00</ram:ChargeAmount>
</ram:NetPriceProductTradePrice>
</ram:SpecifiedLineTradeAgreement>
ram:SpecifiedLineTradeDelivery
<ram:BilledQuantity unitCode="HUR">4.00</ram:BilledQuantity>
</ram:SpecifiedLineTradeDelivery>
ram:SpecifiedLineTradeSettlement
ram:ApplicableTradeTax
ram:TypeCodeVAT</ram:TypeCode>
ram:ExemptionReasonUmkehrung der Steuerschuldnerschaft</ram:ExemptionReason>
ram:CategoryCodeAE</ram:CategoryCode>
ram:RateApplicablePercent0.00</ram:RateApplicablePercent>
</ram:ApplicableTradeTax>
ram:SpecifiedTradeSettlementLineMonetarySummation
ram:LineTotalAmount208.00</ram:LineTotalAmount>
</ram:SpecifiedTradeSettlementLineMonetarySummation>
</ram:SpecifiedLineTradeSettlement>
</ram:IncludedSupplyChainTradeLineItem>
ram:ApplicableHeaderTradeAgreement
ram:BuyerReference123456789</ram:BuyerReference>
ram:SellerTradeParty
ram:ID116078</ram:ID>
ram:NameMustermann GmbH</ram:Name>
ram:DefinedTradeContact
ram:PersonNameWolfgang Muster</ram:PersonName>
ram:TelephoneUniversalCommunication
ram:CompleteNumber069-12335</ram:CompleteNumber>
</ram:TelephoneUniversalCommunication>
ram:EmailURIUniversalCommunication
ram:URIID[email protected]</ram:URIID>
</ram:EmailURIUniversalCommunication>
</ram:DefinedTradeContact>
ram:PostalTradeAddress
ram:PostcodeCode60388</ram:PostcodeCode>
ram:LineOneMusterstrasse 4</ram:LineOne>
ram:CityNameFrankfurt am Main</ram:CityName>
ram:CountryIDDE</ram:CountryID>
</ram:PostalTradeAddress>
ram:SpecifiedTaxRegistration
<ram:ID schemeID="FC">04523149435</ram:ID>
</ram:SpecifiedTaxRegistration>
ram:SpecifiedTaxRegistration
<ram:ID schemeID="VA">DE152338654</ram:ID>
</ram:SpecifiedTaxRegistration>
</ram:SellerTradeParty>
ram:BuyerTradeParty
ram:ID10099</ram:ID>
ram:NameDB Station&Service AG RB Mitte</ram:Name>
ram:DefinedTradeContact
ram:PersonNameKlaus Koffer</ram:PersonName>
</ram:DefinedTradeContact>
ram:PostalTradeAddress
ram:PostcodeCode10115</ram:PostcodeCode>
ram:LineOneElisabeth-Schwarzhaupt-Platz 1</ram:LineOne>
ram:CityNameBerlin</ram:CityName>
ram:CountryIDDE</ram:CountryID>
</ram:PostalTradeAddress>
ram:SpecifiedTaxRegistration
<ram:ID schemeID="VA">DE152138634</ram:ID>
</ram:SpecifiedTaxRegistration>
ram:SpecifiedTaxRegistration
<ram:ID schemeID="FC">04523249415</ram:ID>
</ram:SpecifiedTaxRegistration>
</ram:BuyerTradeParty>
ram:BuyerOrderReferencedDocument
<ram:IssuerAssignedID />
</ram:BuyerOrderReferencedDocument>
</ram:ApplicableHeaderTradeAgreement>
ram:ApplicableHeaderTradeDelivery
ram:ActualDeliverySupplyChainEvent
ram:OccurrenceDateTime
<udt:DateTimeString format="102">20201123</udt:DateTimeString>
</ram:OccurrenceDateTime>
</ram:ActualDeliverySupplyChainEvent>
ram:DeliveryNoteReferencedDocument
ram:IssuerAssignedID22138</ram:IssuerAssignedID>
</ram:DeliveryNoteReferencedDocument>
</ram:ApplicableHeaderTradeDelivery>
ram:ApplicableHeaderTradeSettlement
ram:InvoiceCurrencyCodeEUR</ram:InvoiceCurrencyCode>
ram:SpecifiedTradeSettlementPaymentMeans
ram:TypeCode1</ram:TypeCode>
ram:InformationRechnung</ram:Information>
ram:PayeePartyCreditorFinancialAccount
ram:IBANIDDE54500800000192632400</ram:IBANID>
ram:AccountNameMustermann GmbH</ram:AccountName>
</ram:PayeePartyCreditorFinancialAccount>
ram:PayeeSpecifiedCreditorFinancialInstitution
ram:BICIDDRESDEFFXXX</ram:BICID>
</ram:PayeeSpecifiedCreditorFinancialInstitution>
</ram:SpecifiedTradeSettlementPaymentMeans>
ram:ApplicableTradeTax
ram:CalculatedAmount0.00</ram:CalculatedAmount>
ram:TypeCodeVAT</ram:TypeCode>
ram:BasisAmount233.00</ram:BasisAmount>
ram:CategoryCodeAE</ram:CategoryCode>
ram:RateApplicablePercent0.00</ram:RateApplicablePercent>
</ram:ApplicableTradeTax>
ram:SpecifiedTradeAllowanceCharge
ram:ChargeIndicator
udt:Indicatortrue</udt:Indicator>
</ram:ChargeIndicator>
ram:BasisAmount0.00</ram:BasisAmount>
ram:ActualAmount25.00</ram:ActualAmount>
ram:ReasonLieferpauschale</ram:Reason>
ram:CategoryTradeTax
ram:TypeCodeVAT</ram:TypeCode>
ram:CategoryCodeAE</ram:CategoryCode>
ram:RateApplicablePercent0.00</ram:RateApplicablePercent>
</ram:CategoryTradeTax>
</ram:SpecifiedTradeAllowanceCharge>
ram:SpecifiedTradePaymentTerms
ram:Description10 Tage 3% Skonto, 30 Tage netto</ram:Description>
ram:DueDateDateTime
<udt:DateTimeString format="102">20201227</udt:DateTimeString>
</ram:DueDateDateTime>
</ram:SpecifiedTradePaymentTerms>
ram:SpecifiedTradeSettlementHeaderMonetarySummation
ram:LineTotalAmount208.00</ram:LineTotalAmount>
ram:ChargeTotalAmount25.00</ram:ChargeTotalAmount>
ram:AllowanceTotalAmount0.00</ram:AllowanceTotalAmount>
ram:TaxBasisTotalAmount233.00</ram:TaxBasisTotalAmount>
<ram:TaxTotalAmount currencyID="EUR">0.00</ram:TaxTotalAmount>
ram:GrandTotalAmount233.00</ram:GrandTotalAmount>
ram:DuePayableAmount233.00</ram:DuePayableAmount>
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>
</ram:ApplicableHeaderTradeSettlement>
</rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>

I filled TaxCurrencyCode and InvoiceCurrencyCode in the header:
<ram:ApplicableHeaderTradeSettlement> <ram:PaymentReference /> <ram:TaxCurrencyCode>EUR</ram:TaxCurrencyCode> <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>

In SpecifiedTradeSettlementHeaderMonetarySummation I have no currencyID:
<ram:SpecifiedTradeSettlementHeaderMonetarySummation> <ram:LineTotalAmount>3142.5</ram:LineTotalAmount> <ram:AllowanceTotalAmount>104.65</ram:AllowanceTotalAmount> <ram:TaxBasisTotalAmount>3037.85</ram:TaxBasisTotalAmount> <ram:TaxTotalAmount>242.75</ram:TaxTotalAmount> <ram:GrandTotalAmount>3280.6</ram:GrandTotalAmount> <ram:TotalPrepaidAmount>0</ram:TotalPrepaidAmount> <ram:DuePayableAmount>3280.6</ram:DuePayableAmount> </ram:SpecifiedTradeSettlementHeaderMonetarySummation>

Validation result is:

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

If I do this with a currencyID for TaxTotalAmount, the result is fine
<ram:SpecifiedTradeSettlementHeaderMonetarySummation> <ram:LineTotalAmount>3142.5</ram:LineTotalAmount> <ram:AllowanceTotalAmount>104.65</ram:AllowanceTotalAmount> <ram:TaxBasisTotalAmount>3037.85</ram:TaxBasisTotalAmount> <ram:TaxTotalAmount currencyID="EUR">242.75</ram:TaxTotalAmount> <ram:GrandTotalAmount>3280.6</ram:GrandTotalAmount> <ram:TotalPrepaidAmount>0</ram:TotalPrepaidAmount> <ram:DuePayableAmount>3280.6</ram:DuePayableAmount> </ram:SpecifiedTradeSettlementHeaderMonetarySummation>

I cannot find a remark, that currencyID is required for TaxTotalAmount

The visualization tool does not have an issue section, so I am posting this here.

The generated html of the visualization tool does not work correctly without javascript. However in federal projects that is a common requirement. Please add no-js support

The latest release "validator-configuration-xrechnung_2.0.0_2020-07-31" issues a warning in validationtool when validating xrechnung_2.0 and using InvoiceType 875. But this should be accepted.

"[BR-CL-01]-The document type code MUST be coded by the invoice and credit note related code lists of UNTDID 1001."

Temp.zip

Validierungsergebnisse im Detail:

Please adjust the testfile!
regards

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

First link ("validator") in README.md is broken...

Hi @rkottmann, sorry to bug you again ;-)

Most of your UBL CreditNote test files from 2.0.1 trigger the error described in ConnectingEurope/eInvoicing-EN16931#257 because of the duplicate TaxTotal element:

  <cac:TaxTotal>
      <cbc:TaxAmount currencyID="EUR">2048.44</cbc:TaxAmount>
      <cac:TaxSubtotal>
         <cbc:TaxableAmount currencyID="EUR">10781.25</cbc:TaxableAmount>
         <cbc:TaxAmount currencyID="EUR">2048.44</cbc:TaxAmount>
         <cac:TaxCategory>
            <cbc:ID>S</cbc:ID>
            <cbc:Percent>19</cbc:Percent>
            <cac:TaxScheme>
               <cbc:ID>VAT</cbc:ID>
            </cac:TaxScheme>
         </cac:TaxCategory>
      </cac:TaxSubtotal>    
  </cac:TaxTotal>
  
  
  <cac:TaxTotal>
      <cbc:TaxAmount currencyID="EUR">2048.44</cbc:TaxAmount>
  </cac:TaxTotal>

After removing

  <cac:TaxTotal>
      <cbc:TaxAmount currencyID="EUR">2048.44</cbc:TaxAmount>
  </cac:TaxTotal>

other (expected or unexpected) errors occur.
Please update your test file generator accordingly.

Should the TypeCode in /src/test/instances/cii001.xml not be 380=invoice?

With your "Validator Configuration release compatible with XRechnung 2.0.0 in version 2020-07-31" I get an error stating that the Typecode is not coded according to the codelist and the validator suggests rejection of the invoice, which should be a correct CII XRechnung 2.0 with the typecode 875 from the official referenced codelist UNTDID 1001_2.

I haven't changed any configuration, i just downloaded the Validator and the Validator Config for version 2.0.0 (as mentioned above) as instructed in your wiki.

With 2.0.1 it is merely a warning, but it still suggests to the invoice recipient that there is some kind of error even if it is accepted.
But as I see it, the official valid codelist since v1.2.2 should be Revision 2 of UNTDID 1001. Unfortunately many of our customers get their invoices rejected because they have to use these typecodes, considering they work in the construction industry and it is required by law.

XRechnung.zip

the attached EN16931 XRechnung (CII) throws a validation error

[BR-53]-If the VAT accounting currency code (BT-6) is present, then the Invoice total VAT amount in accounting currency (BT-111) shall be provided.

but i dont't see an error with this document, all needed information are present

XRechnung-UNCEFACT.zip

<ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
...
<ram:TaxTotalAmount currencyID="EUR">26.00</ram:TaxTotalAmount>

In my opinion there is a bug in the visualization of the allowances and charges on head an item level.
The "select" and the "match" in the cii-xr.xsl are checking for the wrong tag:

<xsl:apply-templates mode="BG-27" select="./ram:SpecifiedLineTradeSettlement/ram:SpecifiedTradeAllowanceCharge[ram:ChargeIndicator='false']"/>

According to the specification it should be something like this, in my opinion:

<xsl:apply-templates mode="BG-27" select="./ram:SpecifiedLineTradeSettlement/ram:SpecifiedTradeAllowanceCharge/ram:ChargeIndicator[udt:Indicator='false']"/>

If i'm right, i adaped the complete file to get it working even with your provided samples. I can send it to you.

muss gemacht werden

In Firefox the generated report looks like this:

In Firefox the default font is somewhat larger than in chrome. The css elemet

            .metadata dt {
            float: left;
            width: 230px;
            clear: left;
            }

with the hard coded width is to small to hold the elements: Erkannter Rechnungssteller, Erkannte Rechnungsnummer, Erkanntes Rechnungsdatum.

Additionally the charset in the html file should be set with:
<meta charset="utf-8">

Warum wird diese Warnung ausgegeben? Nach Spezifikation ist das Dokument korrekt.

Sie können das zum Beispiel auch in der mitgelieferten Testsuite des aktuellen Releases mit der Datei 04.02a-INVOICE_ubl.xml nachprüfen.

for unit HR/Stunde I get:

mit Bewertung: Es wird empfohlen das Dokument anzunehmen und weiter zu verarbeiten.

ABER ich nutze die api und der automatisierte Ablauf/Test stoppt:

• denn der Beleg wir als not valid gekennzeichnet:

<?xml version="1.0" encoding="UTF-8"?>
<rep:report xmlns:rep="http://www.xoev.de/de/validator/varl/1"
            xmlns:html="http://www.w3.org/1999/xhtml"
            xmlns:in="http://www.xoev.de/de/validator/framework/1/createreportinput"
            xmlns:s="http://www.xoev.de/de/validator/framework/1/scenarios"
            xmlns:svrl="http://purl.oclc.org/dsdl/svrl"
            xmlns:xd="http://www.oxygenxml.com/ns/doc/xsl"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            valid="false"           <=======================
            varlVersion="1.0.0">

• da hilft es wenig wenn die Bewertung aus dem Fehler eine Warnung macht

In XRechnung-v1-2-0 steht
Invoiced quantity unit of measure code / BT-130:
Die für die in Rechnung gestellte Menge geltende Maßeinheit. Die Maßeinheit muss unter Anwendung der in UN/ECE Rec No 20 Intro 2.a) beschriebenen Methode aus den Listen UN/ECE Recommendation No. 20 „Codes for Units of Measure Used in International Trade“a und UN/ECE Recommendation No 21 „Codes for Passengers, Types of Cargo, Packages and Packaging Materials (with Complementary Codes for Package Names)“b ausgewählt werden.
In den meisten Fällen ist es nicht erforderlich, dass Verkäufer und Erwerber diese Listen vollständig in ihren Anwendungen implementieren. Verkäufer müssen nur die erforderlichen Einheiten für ihre Güter und Dienstleistungen unterstützen. Erwerber überprüfen lediglich, ob die in der Rechnung verwendeten Einheiten mit denen in anderen Dokumenten zum Erwerb (wie z. B. Vertrag, Katalog, Bestellung oder Lieferschein) identisch sind.

In den meisten Fällen sollte der Validator dann valid mit Warnung liefern!
Grüße aus Stuttgart

how i can validate against the XRechnung-Extension?

if i add a application/xml mime-type a validation error will be thrown

[BR-CL-24]-For Mime code in attribute use MIMEMediaType.
Pfad: /ubl:Invoice/cac:AdditionalDocumentReference[5]/cac:Attachment[1]/cbc:EmbeddedDocumentBinaryObject[1]

<cac:AdditionalDocumentReference>
  <cbc:ID>attachment.xml</cbc:ID>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject mimeCode="application/xml" filename="attachment.xml">PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxkYXRhPg0KPC9kYXRhPg==</cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

this issue says this mime type is supported

https://4257-gitlab-ee-b2bd6-web.nws.netways.de/xrechnung/xrechnung/-/issues/59

After following the steps as written in the README file and running the follwoing command in CMD:
C:\XRechnung>java -jar validationtool-1.0.1-standalone.jar -s scenarios.xml -h 01.01a-INVOICE_ubl.xml
I'm receiving a ClassNotFound Exception:

Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
        at de.kosit.validationtool.impl.DefaultCheck.<init>(DefaultCheck.java:73)
        at de.kosit.validationtool.cmd.InternalCheck.<init>(InternalCheck.java:48)
        at de.kosit.validationtool.cmd.CommandLineApplication.processActions(CommandLineApplication.java:135)
        at de.kosit.validationtool.cmd.CommandLineApplication.mainProgram(CommandLineApplication.java:105)
        at de.kosit.validationtool.cmd.CommandLineApplication.main(CommandLineApplication.java:85)
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:602)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
        ... 5 more

Is there something I missed?

Best regards.

i think it's a false positive when using SubInvoiceLine and AllowanceCharge on InvoiceLine-level

[BR-DEX-02] Der Wert von "Invoice line net amount" (BT-131) einer "INVOICE LINE" (BG-25) oder einer "SUB INVOICE LINE" (BG-DEX-01) soll der Summe der "Invoice line net amount" (BT-131) der direkt darunterliegenden "SUB INVOICE LINE" (BG-DEX-01) entsprechen.

see attached document

XRechnung-UBL-200.zip

Date fields in Cross Industry Invoices (CII) are not validated and can therefore contain invalid dates (see attached invoice Line 14)

The visualization needs correct dates in order to convert them into the German format and therefore fails in this case.

Versions:
Validator: 1.4.0
Configuration: 2.0.0

Hi,

attachments of type application/xml do not work as expected for me.

Using java -jar validationtool-1.4.0/validationtool-1.4.0-standalone.jar -s validator-configuration-xrechnung_2.0.0_2020-07-31/scenarios.xml with the attached files yields the following results.

XRechnung-UBL-2020-12-17-with-xml-attachment-and-extension-urn.xml
Rejected but expected to be valid.

--------------------------------------------------------------------------------------------------------------------------------------------------------------
|filename                                                            |Schema |Schematron|Acceptance|Error/Description                                         |
| XRechnung-UBL-2020-12-17-with-xml-attachment-and-extension-urn.xml |   Y   |    N     |  REJECT  | [BR-CL-24]-For Mime code in attribute use MIMEMediaType. |
--------------------------------------------------------------------------------------------------------------------------------------------------------------
Acceptable:  0  Rejected:  1

XRechnung-CEFACT-2020-12-17-with-xml-attachment-and-extension-urn.xml
Rejected but expected to be valid.

---------------------------------------------------------------------------------------------------------------------------
|filename                                                               |Schema |Schematron|Acceptance|Error/Description   |
| XRechnung-CEFACT-2020-12-17-with-xml-attachment-and-extension-urn.xml |   N   |    Y     |  REJECT  |                    |
---------------------------------------------------------------------------------------------------------------------------
Acceptable:  0  Rejected:  1

XRechnung-CEFACT-2020-12-17-with-xml-attachment-without-extension-urn.xml
Accepted but expected to be invalid.

-------------------------------------------------------------------------------------------------------------------------------
|filename                                                                   |Schema |Schematron|Acceptance|Error/Description   |
| XRechnung-CEFACT-2020-12-17-with-xml-attachment-without-extension-urn.xml |   Y   |    Y     |ACCEPTABLE|                    |
-------------------------------------------------------------------------------------------------------------------------------
Acceptable:  1  Rejected:  0

XRechnung-CEFACT-2020-12-17-with-invalid-attachment-without-extension-urn.xml
Accepted but expected to be invalid. I think this hints at #20 being unresolved for CEFACT.

---------------------------------------------------------------------------------------------------------------------------------------
|filename                                                                       |Schema |Schematron|Acceptance|Error/Description   |
| XRechnung-CEFACT-2020-12-17-with-invalid-attachment-without-extension-urn.xml |   Y   |    Y     |ACCEPTABLE|                    |
---------------------------------------------------------------------------------------------------------------------------------------
Acceptable:  1  Rejected:  0

Github-KoSIT-Validator-Configuration-Issue-40-XML-test-files.zip

Originally posted by @tze in #40 (comment)

denn seller country code wurde auskommentiert.

Das ergibt

Referenz:
ubl003.xml
Zeitpunkt der Prüfung:
28.5.2019 17:49:14
Erkannter Dokumenttyp:
EN16931 CIUS XRechnung (UBL Invoice)

Erkannter Rechnungssteller:
De Koksmaat
Erkannte Rechnungsnummer:
12115118
Erkanntes Rechnungsdatum:
2015-01-09

Konformitätsprüfung: Das geprüfte Dokument enthält 1 Fehler / 0 Warnungen. Es ist nicht konform zu den formalen Vorgaben.

There seems to be an inconsistency in the latest release (XRechnung 1.1 on 2018-08-31) in the validation of the Seller VAT Identifier (BT-31) -(SellerTradeParty/ram:SpecifiedTaxRegistration/ram:ID) between the EN16931 and the XRechnung validation files.

The rules BR-CO-26 and BR-S-02 (EN16931) are testing with the schemeID="VAT".
The rule BR-DE-16 (XRechnung) ist testing the Seller VAT Identifier with the schemeID="VA".
In the current validation-scenario you cannot win....
Which one is correct?

Kind regards,
Tomislav Dedus

denn seller country code wurde auskommentiert.

Das ergibt

Referenz:
ubl003.xml
Zeitpunkt der Prüfung:
28.5.2019 17:49:14
Erkannter Dokumenttyp:
EN16931 CIUS XRechnung (UBL Invoice)

Erkannter Rechnungssteller:
De Koksmaat
Erkannte Rechnungsnummer:
12115118
Erkanntes Rechnungsdatum:
2015-01-09

Konformitätsprüfung: Das geprüfte Dokument enthält 1 Fehler / 0 Warnungen. Es ist nicht konform zu den formalen Vorgaben.

Wann darf man mit der Konfiguration für XRechnung 2.1 rechnen?

Using InvoiceTypeCode 875 (partial construction invoice) produces validation error:

[BR-CL-01]-The document type code MUST be coded by the invoice and credit note related code lists of UNTDID 1001.

The examples included in validation configurator 1.2.2 are also invalid. Running following commands shows the issue:

curl -L 'https://github.com/itplr-kosit/validator/releases/download/v1.2.0/validationtool-1.2.0.zip' --output validator.zip
curl -L 'https://github.com/itplr-kosit/validator-configuration-xrechnung/releases/download/release-2019-12-30/validator-configuration-xrechnung_1.2.2_2019-12-30.zip' --output validator-configuration.zip
unzip validator.zip
unzip validator-configuration.zip
java -jar validationtool-1.2.0-standalone.jar -s scenarios.xml  -h test/construction-codes.xml/*
find . -iname "*.html" -exec grep  -H "Dokument enthält 1 Fehler" {} \;

The following output is produced:

./construction-codes.xml-11-876-report.html:      <p class="important"><b>Konformitätsprüfung: </b>Das geprüfte Dokument enthält 1 Fehler / 0 Warnungen. Es ist <b>nicht konform</b> zu den formalen Vorgaben.</p>
./construction-codes.xml-12-877-report.html:      <p class="important"><b>Konformitätsprüfung: </b>Das geprüfte Dokument enthält 1 Fehler / 0 Warnungen. Es ist <b>nicht konform</b> zu den formalen Vorgaben.</p>
./construction-codes.xml-7-876-report.html:      <p class="important"><b>Konformitätsprüfung: </b>Das geprüfte Dokument enthält 1 Fehler / 0 Warnungen. Es ist <b>nicht konform</b> zu den formalen Vorgaben.</p>
./construction-codes.xml-9-381-report.html:      <p class="important"><b>Konformitätsprüfung: </b>Das geprüfte Dokument enthält 1 Fehler / 0 Warnungen. Es ist <b>nicht konform</b> zu den formalen Vorgaben.</p>
./construction-codes.xml-6-875-report.html:      <p class="important"><b>Konformitätsprüfung: </b>Das geprüfte Dokument enthält 1 Fehler / 0 Warnungen. Es ist <b>nicht konform</b> zu den formalen Vorgaben.</p>
./construction-codes.xml-8-877-report.html:      <p class="important"><b>Konformitätsprüfung: </b>Das geprüfte Dokument enthält 1 Fehler / 0 Warnungen. Es ist <b>nicht konform</b> zu den formalen Vorgaben.</p>
./construction-codes.xml-5-381-report.html:      <p class="important"><b>Konformitätsprüfung: </b>Das geprüfte Dokument enthält 1 Fehler / 0 Warnungen. Es ist <b>nicht konform</b> zu den formalen Vorgaben.</p>
./construction-codes.xml-10-875-report.html:      <p class="important"><b>Konformitätsprüfung: </b>Das geprüfte Dokument enthält 1 Fehler / 0 Warnungen. Es ist <b>nicht konform</b> zu den formalen Vorgaben.</p>

Furthermore, the construction test invoices do not include a reference to the previous partial construction invoice therefore, it is not quite clear where this information should be stored. Can the document level AllowanceCharge field be used for this purpose like in the invoice below?

<?xml version="1.0"?>
<Invoice xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_1.2</cbc:CustomizationID>
  <cbc:ProfileID>XRechnung 1.2.2</cbc:ProfileID>
  <cbc:ID>3/445566</cbc:ID>
  <cbc:IssueDate>2020-06-10</cbc:IssueDate>
  <cbc:DueDate>2020-07-02</cbc:DueDate>
  <cbc:InvoiceTypeCode>875</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  <cbc:BuyerReference>1234567890</cbc:BuyerReference>
  <cac:InvoicePeriod>
    <cbc:StartDate>2020-04-11</cbc:StartDate>
    <cbc:EndDate>2020-05-11</cbc:EndDate>
  </cac:InvoicePeriod>
  <cac:OrderReference>
    <cbc:ID />
    <cbc:SalesOrderID />
  </cac:OrderReference>
  <cac:BillingReference>
    <cac:InvoiceDocumentReference>
      <cbc:ID>1/445566</cbc:ID>
      <cbc:IssueDate>2020-04-10</cbc:IssueDate>
    </cac:InvoiceDocumentReference>
  </cac:BillingReference>
  <cac:BillingReference>
    <cac:InvoiceDocumentReference>
      <cbc:ID>2/445566</cbc:ID>
      <cbc:IssueDate>2020-05-10</cbc:IssueDate>
    </cac:InvoiceDocumentReference>
  </cac:BillingReference>
  <cac:OriginatorDocumentReference>
    <cbc:ID />
  </cac:OriginatorDocumentReference>
  <cac:ContractDocumentReference>
    <cbc:ID />
  </cac:ContractDocumentReference>
  <cac:ProjectReference>
    <cbc:ID />
  </cac:ProjectReference>
  <cac:AccountingSupplierParty>
    <cac:Party>
      <cbc:EndpointID schemeID="0088">Email8a7e0c5f-b444-47cc-9f26-f39c3fa03566</cbc:EndpointID>
      <cac:PostalAddress>
        <cbc:StreetName>Street8c486a98-c46c-4826-ab8e-464486d3676b</cbc:StreetName>
        <cbc:CityName>Cityae6cb87a-6877-4bbe-826a-e41680efa0de</cbc:CityName>
        <cbc:PostalZone>PostCode73def61f-989e-42c5-a407-3ebba912bf16</cbc:PostalZone>
        <cbc:CountrySubentity>State29d5813e-68b8-4eea-93cd-bde280693267</cbc:CountrySubentity>
        <cac:Country>
          <cbc:IdentificationCode>DE</cbc:IdentificationCode>
        </cac:Country>
      </cac:PostalAddress>
      <cac:PartyTaxScheme>
        <cbc:CompanyID>DE1234567890</cbc:CompanyID>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:PartyTaxScheme>
      <cac:PartyTaxScheme>
        <cbc:CompanyID>TaxRegistrationIdentifieree46398f-498d-401e-9877-57de78af09b3</cbc:CompanyID>
        <cac:TaxScheme>
          <cbc:ID>FC</cbc:ID>
        </cac:TaxScheme>
      </cac:PartyTaxScheme>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>CompanyName2cd9bc36-5e12-4171-87fc-93b0079c839b</cbc:RegistrationName>
      </cac:PartyLegalEntity>
      <cac:Contact>
        <cbc:Name>ContactName2629f480-f1e5-4f55-97bb-117be755cb30</cbc:Name>
        <cbc:Telephone>Phonee963017c-3587-4380-847b-8d404b455334</cbc:Telephone>
        <cbc:ElectronicMail>Email8a7e0c5f-b444-47cc-9f26-f39c3fa03566</cbc:ElectronicMail>
      </cac:Contact>
    </cac:Party>
  </cac:AccountingSupplierParty>
  <cac:AccountingCustomerParty>
    <cac:Party>
      <cbc:EndpointID schemeID="0088">Email9087e37e-7f68-42dc-ae2a-966e1657eacc</cbc:EndpointID>
      <cac:PostalAddress>
        <cbc:StreetName>Street5ae2abb6-3f38-4ca4-91d1-51201e1915d2</cbc:StreetName>
        <cbc:CityName>Cityb95ef052-9c48-4cc0-a698-009a968f76a4</cbc:CityName>
        <cbc:PostalZone>PostCode17405f20-c4e0-49a4-8a37-1943f6314924</cbc:PostalZone>
        <cbc:CountrySubentity>State3690a742-6cb8-4750-8552-a8c5616e6576</cbc:CountrySubentity>
        <cac:Country>
          <cbc:IdentificationCode>DE</cbc:IdentificationCode>
        </cac:Country>
      </cac:PostalAddress>
      <cac:PartyTaxScheme>
        <cbc:CompanyID>DE1234567890</cbc:CompanyID>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:PartyTaxScheme>
      <cac:PartyTaxScheme>
        <cbc:CompanyID>TaxRegistrationIdentifier2b324ff7-a397-4ce3-a41a-7e05f9e635ce</cbc:CompanyID>
        <cac:TaxScheme>
          <cbc:ID>FC</cbc:ID>
        </cac:TaxScheme>
      </cac:PartyTaxScheme>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>CompanyName1ae950d1-aa37-4e21-a23d-9794b343132d</cbc:RegistrationName>
      </cac:PartyLegalEntity>
      <cac:Contact>
        <cbc:Name>ContactName0b073579-b63b-4d87-b54c-c8aea626c3c3</cbc:Name>
        <cbc:Telephone>Phonebccce2a5-c6f6-4ec4-a61d-710373d0954d</cbc:Telephone>
        <cbc:ElectronicMail>Email9087e37e-7f68-42dc-ae2a-966e1657eacc</cbc:ElectronicMail>
      </cac:Contact>
    </cac:Party>
  </cac:AccountingCustomerParty>
  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
    <cac:PayeeFinancialAccount>
      <cbc:ID>DE123123123</cbc:ID>
    </cac:PayeeFinancialAccount>
  </cac:PaymentMeans>
  <cac:AllowanceCharge>
    <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
    <cbc:AllowanceChargeReason>Abschlagsrechnung 1/445566</cbc:AllowanceChargeReason>
    <cbc:MultiplierFactorNumeric>100</cbc:MultiplierFactorNumeric>
    <cbc:Amount currencyID="EUR">10</cbc:Amount>
    <cbc:BaseAmount currencyID="EUR">10</cbc:BaseAmount>
    <cac:TaxCategory>
      <cbc:ID>S</cbc:ID>
      <cbc:Percent>19</cbc:Percent>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:TaxCategory>
  </cac:AllowanceCharge>
  <cac:AllowanceCharge>
    <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
    <cbc:AllowanceChargeReason>Abschlagsrechnung 2/445566</cbc:AllowanceChargeReason>
    <cbc:MultiplierFactorNumeric>100</cbc:MultiplierFactorNumeric>
    <cbc:Amount currencyID="EUR">20</cbc:Amount>
    <cbc:BaseAmount currencyID="EUR">20</cbc:BaseAmount>
    <cac:TaxCategory>
      <cbc:ID>S</cbc:ID>
      <cbc:Percent>19</cbc:Percent>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:TaxCategory>
  </cac:AllowanceCharge>
  <cac:TaxTotal>
    <cbc:TaxAmount currencyID="EUR">33.05</cbc:TaxAmount>
    <cac:TaxSubtotal>
      <cbc:TaxableAmount currencyID="EUR">170</cbc:TaxableAmount>
      <cbc:TaxAmount currencyID="EUR">32.3</cbc:TaxAmount>
      <cac:TaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>19</cbc:Percent>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:TaxCategory>
    </cac:TaxSubtotal>
    <cac:TaxSubtotal>
      <cbc:TaxableAmount currencyID="EUR">7.0</cbc:TaxableAmount>
      <cbc:TaxAmount currencyID="EUR">0.75</cbc:TaxAmount>
      <cac:TaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>10.7</cbc:Percent>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:TaxCategory>
    </cac:TaxSubtotal>
  </cac:TaxTotal>
  <cac:LegalMonetaryTotal>
    <cbc:LineExtensionAmount currencyID="EUR">207.0</cbc:LineExtensionAmount>
    <cbc:TaxExclusiveAmount currencyID="EUR">177.0</cbc:TaxExclusiveAmount>
    <cbc:TaxInclusiveAmount currencyID="EUR">210.05</cbc:TaxInclusiveAmount>
    <cbc:AllowanceTotalAmount currencyID="EUR">30</cbc:AllowanceTotalAmount>
    <cbc:PayableAmount currencyID="EUR">210.05</cbc:PayableAmount>
  </cac:LegalMonetaryTotal>
  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="XPP">100</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">200</cbc:LineExtensionAmount>
    <cac:Item>
      <cbc:Name>Apple</cbc:Name>
      <cac:ClassifiedTaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>19</cbc:Percent>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
    <cac:Price>
      <cbc:PriceAmount currencyID="EUR">2</cbc:PriceAmount>
    </cac:Price>
  </cac:InvoiceLine>
  <cac:InvoiceLine>
    <cbc:ID>2</cbc:ID>
    <cbc:InvoicedQuantity unitCode="XPP">0.5</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">7.0</cbc:LineExtensionAmount>
    <cac:Item>
      <cbc:Name>Orange</cbc:Name>
      <cac:ClassifiedTaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>10.7</cbc:Percent>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
    <cac:Price>
      <cbc:PriceAmount currencyID="EUR">14</cbc:PriceAmount>
    </cac:Price>
  </cac:InvoiceLine>
</Invoice>

Hallo,
ich versuche derzeit Rechnungen aus unserem System als XRechnungen zu verschicken. Ich kenne mich leider noch nicht sehr gut mit dem System aus und weiß deshalb nicht mal, ob ich mit der Frage hier richtig bin:

Ich bekomme beim Validator den folgenden Fehler:

Ungültiger Content wurde beginnend mit Element 'cac:PartyLegalEntity' gefunden. 
'{"urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2":Person, 
"urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2":AgentParty, 
"urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2":ServiceProviderParty, 
"urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2":PowerOfAttorney, 
"urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2":FinancialAccount}' wird erwartet.

Der entsprechende Block sieht wie folgt aus:

<cac:AccountingSupplierParty>
 <cac:Party>
  <cac:PartyName>
   <cbc:Name>Supplier Company Name</cbc:Name>
  </cac:PartyName>
  <cac:PostalAddress>
   <cbc:StreetName>Test</cbc:StreetName>
   <cbc:CityName>Test</cbc:CityName>
   <cbc:PostalZone>12345</cbc:PostalZone>
   <cac:Country>
    <cbc:IdentificationCode>DE</cbc:IdentificationCode>
   </cac:Country>
  </cac:PostalAddress>
  <cac:Contact>
   <cbc:Telephone>030123456</cbc:Telephone>
  </cac:Contact>
  <cac:PartyLegalEntity>
   <cbc:RegistrationName>Supplier Company Name</cbc:RegistrationName>
   <cbc:CompanyID>Company Registration</cbc:CompanyID>
  </cac:PartyLegalEntity>
 </cac:Party>
</cac:AccountingSupplierParty>

Dabei habe ich festgestellt, dass wenn der Contact-Block mit dem PartyLegalEntity-Block vertauscht wird dieser Fehler nicht mehr auftaucht. Spielt die Reihenfolge eine Rolle? Das dürfte doch in einer XML-Datei eigentlich egal sein, oder liege ich hier falsch?

Vielleicht kann mir hier jemand weiterhelfen.

I checked an invoice with "reverse charge" and got an error. Would be very grateful if you would give me an indication why the error appears.
The invoice and the test-report are attached.

Regards

reversecharge.zip

Hello!

I wanted to replace the old Xrechnung-Standard 1.2.2. with the newest release: https://github.com/itplr-kosit/validator-configuration-xrechnung/releases/tag/release-2020-07-31

After some analyze I found out that I can't use the new release for Credit Notes because of this validation (file: XRechnung-UBL-validation-CreditNote.xsl):

      <xsl:choose>
         <xsl:when test="cbc:CustomizationID = 'urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_1.2'"/>
         <xsl:otherwise>
            <svrl:failed-assert xmlns:svrl="http://purl.oclc.org/dsdl/svrl"
                                test="cbc:CustomizationID = 'urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_1.2'">
               <xsl:attribute name="id">BR-DE-21</xsl:attribute>
               <xsl:attribute name="flag">warning</xsl:attribute>
               <xsl:attribute name="location">
                  <xsl:apply-templates select="." mode="schematron-select-full-path"/>
               </xsl:attribute>
               <svrl:text>[BR-DE-21] Das Element "Specification identifier" (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen.</svrl:text>
            </svrl:failed-assert>
         </xsl:otherwise>
      </xsl:choose>

as you can see the CustomisationID has still the same value as for the Version 1.2.2. In file scenarios.xml we can find the right value for CustomisationID:

<match>exists(/creditnote:CreditNote[ cbc:CustomizationID/text() = 'urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_2.0'])</match>

So with this state I can't really validate any Credit Note...
I wonder if it is a real bug or maybe the newest release doesn't affect the Credit Note Validations?

Thanks for your help!

I found a problem with the validator version 1.3.1.

The attached XRechnung in UNCEFACT is rejected due to BR-Z-8, however it looks perfectly valid to me...

out.xml

It seems to me that the actual problem occurs with the charge indicator for allowances on document level in case the VAT category code is 'Z'.

The XPath expression from rule BR-Z-8 on the attached document returns 55.53, although it should return nothing.

sum(
/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeAllowanceCharge[ram:ChargeIndicator/udt:Indicator=true() and ram:CategoryTradeTax/ram:CategoryCode='Z']/ram:ActualAmount
)

However the actual XML looks like this (see attached XML)

<ram:SpecifiedTradeAllowanceCharge>
            <ram:ChargeIndicator>
               <udt:Indicator>false</udt:Indicator>
            </ram:ChargeIndicator>
            <ram:BasisAmount>55.53</ram:BasisAmount>
            <ram:ActualAmount>55.53</ram:ActualAmount>
            <ram:Reason>Rechnungskorrektur</ram:Reason>
            <ram:CategoryTradeTax>
               <ram:TypeCode>VAT</ram:TypeCode>
               <ram:CategoryCode>Z</ram:CategoryCode>
               <ram:RateApplicablePercent>0</ram:RateApplicablePercent>
            </ram:CategoryTradeTax>
</ram:SpecifiedTradeAllowanceCharge>

The charge indicator is clearly set to false and the XPath expression matches anyway.

This results in BR-Z-08 to fire and rejecting the document.

Am I overlooking something or is this some bug in the schematron rules?

When validating an invoice with one of the construction type codes (875, 876, 877) I get an error when validating a CII-invoice but an information when validating a UBL-invoice.

scenarios.xml contains <customLevel level="information">BR-CL-01</customLevel> but only for the UBL rules.

Is this an error or is it not allowed to generate construction invoices using the CII standard?

Between...

and...

<acceptMatch>/rep:report[@valid='true']</acceptMatch>

It seems the latter is a bit more concise.

Just this:

/invoice:Invoice[starts-with(cbc:CustomizationID, 'urn:cen.eu:en16931:2017') or starts-with(cbc:CustomizationID, 'urn:ce.eu:en16931:2017')]

I use validationtool-1.1.0

The following xml is valid even though there are no BG-22 DOCUMENT TOTALS. It is based on 01.01a-INVOICE_uncefact.xml

validationtool-1.1.0-test.zip

I attach the CII xml and the validation reslut files as zip

regards

If I use an unsupported MimeType in Additional-Documents, no Validation Errors are thrown.

From 1.2.0 spec : https://www.xoev.de/sixcms/media.php/13/XRechnung-v1-2-0.pdf

Der MIME Code des angehängten Dokumentes. Zugelassen sind die Codes
• application/pdf
• image/png
• image/jpeg
• text/csv
• application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
• application/vnd.oasis.opendocument.spreadsheet

01.15a-INVOICE_ubl_nicht_unterstuezter_mimetyp.xml.zip

If I vaildate the example Invoice 01_15_ubl with embeed Document, but not supported Mime-Type, the validation is o.k.; Expected : Validation error.

Please add validation Rules for supported Mime-Types from additional Documents defined in spec.

Ich habe den Testfall 03.02a-INVOICE_ubl etwas abgewandelt, denn

• BG-18 ++ 0..1 INFORMATIONEN ZUR ZAHLUNSKARTE hat nur ein mandatory Element
• BT-87 +++ 1..1 Zahlungskartennummer

das andere ist optional:

• BT-88 +++ 0..1 Name des Zahlungskarteninhabers

In DIN EN 16931-1:2020-12 werden keine weiteren Elemente genannt.
Daher habe ich im Testfall 03.02a-INVOICE_ubl das Element cbc:NetworkID entfernt. So sieht die modifizierte Stelle aus:

    <cac:PaymentMeans>
        <cbc:PaymentMeansCode>48</cbc:PaymentMeansCode>
        <cac:CardAccount>
            <cbc:PrimaryAccountNumberID>41234</cbc:PrimaryAccountNumberID>
            <!-- entfernt, denn in EN16931 nicht definiert:
            <cbc:NetworkID>mapped-from-cii</cbc:NetworkID>  mandatory ??? -->
        </cac:CardAccount>
    </cac:PaymentMeans>

Der Valdator meldet daraufhin einen Fehler, was nicht sein sollte:

Ich nutze: validationtool-1.3.0-standalone.jar:

2020-12-21 20:18:25 [INFO] Using resolving strategy STRICT_RELATIVE
2020-12-21 20:18:25 [INFO] Creating default scenario repository (alongside scenario definition)
2020-12-21 20:18:26 [INFO] Load schema from source file:/C:/proj/factur-X/xrechnung/validationtool-1.3.0/validationtool-1.3.0-standalone.jar!/xsd/scenarios.xsd
2020-12-21 20:18:26 [INFO] Loading scenarios from file:///C:/proj/factur-X/xrechnung/validationtool-1.3.0/scenarios.xml
2020-12-21 20:18:26 [INFO] Creating default scenario repository (alongside scenario definition)
2020-12-21 20:18:26 [INFO] Loading scenario content from file:/C:/proj/factur-X/xrechnung/validationtool-1.3.0/
2020-12-21 20:18:27 [INFO] Loading XSLT script from  resources/ubl/2.1/xsl/EN16931-UBL-validation.xsl
2020-12-21 20:18:28 [INFO] Loading XSLT script from  resources/xrechnung/2.0.0/xsl/XRechnung-UBL-validation-Invoice.xsl
2020-12-21 20:18:28 [INFO] Loading XSLT script from  resources/xrechnung-report.xsl
2020-12-21 20:18:28 [INFO] Loading XSLT script from  resources/ubl/2.1/xsl/EN16931-UBL-validation.xsl
2020-12-21 20:18:29 [INFO] Loading XSLT script from  resources/xrechnung/2.0.0/xsl/XRechnung-UBL-validation-CreditNote.xsl
2020-12-21 20:18:29 [INFO] Loading XSLT script from  resources/xrechnung-report.xsl
2020-12-21 20:18:29 [INFO] Loading XSLT script from  resources/cii/16b/xsl/EN16931-CII-validation.xsl
2020-12-21 20:18:29 [INFO] Loading XSLT script from  resources/xrechnung/2.0.0/xsl/XRechnung-CII-validation.xsl
2020-12-21 20:18:29 [INFO] Loading XSLT script from  resources/xrechnung-report.xsl
2020-12-21 20:18:29 [INFO] Loading XSLT script from  resources/ubl/2.1/xsl/EN16931-UBL-validation.xsl
2020-12-21 20:18:30 [INFO] Loading XSLT script from  resources/xrechnung-report.xsl
2020-12-21 20:18:30 [INFO] Loading XSLT script from  resources/ubl/2.1/xsl/EN16931-UBL-validation.xsl
2020-12-21 20:18:30 [INFO] Loading XSLT script from  resources/xrechnung-report.xsl
2020-12-21 20:18:30 [INFO] Loading XSLT script from  resources/cii/16b/xsl/EN16931-CII-validation.xsl
2020-12-21 20:18:30 [INFO] Loading XSLT script from  resources/xrechnung-report.xsl
2020-12-21 20:18:30 [INFO] Loading XSLT script from  resources/default-report.xsl
2020-12-21 20:18:30 [INFO] Loaded scenarios for Validator Configuration XRechnung 2.0.0 by Coordination Office for IT Standards (KoSIT) from 2020-08-06. The following scenarios are available:

EN16931 XRechnung (UBL Invoice)
EN16931 XRechnung (UBL CreditNote)
EN16931 XRechnung (CII)
EN16931 (UBL Invoice)
EN16931 (UBL CreditNote)
EN16931 (CII)

Gruß aus Stgt