search

itplr-kosit / validator-configuration-xrechnung

Configuration for validating documents against the German XRechnung standard using the KoSIT validation tool
https://xeinkauf.de/xrechnung/
Apache License 2.0
61 stars 16 forks source link

Validation failure for invoice type 875 (partial construction invoice) #23

Closed RytisLT closed 3 years ago

RytisLT commented 4 years ago

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>
RytisLT commented 4 years ago

@rkottmann any updates on the issue?

rkottmann commented 4 years ago

Concerning the first issue:

the validation report might see errors, but under certain circumstances, we might still recommend to accept the invoice anyways. This is especially true for these codes, because the offciail code list has theses codes, but CEN does not updte in time. Hence, we ignore the error raised by the CEN rules and accept it via our own rules.

Hence, it is not good to grep for error. It is necessary to look for acceptance or rejection.

Please show the full html report. It should still accept it. At least in my apparently same setting.

rkottmann commented 4 years ago

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?

I do not unserstand, what you are asking for. Please post this question to xrechnung@finanzen.bremen.de

RytisLT commented 4 years ago

I've contacted xrechnung@finanzen.bremen.de regarding the Invoice structure question more than a month ago but received no response. I'll try again...

I've attached the HTML report and the invoice that I've used. The report does indeed state that the invoice can be accepted regardless of minor errors. That said the invoice does conform to the standard and the report should say that it has no errors. I'm assuming this will be fixed in the next release. Any ideas then the next release is coming?

reports.zip

rkottmann commented 3 years ago

it won't be fixed the way you wan't it see #32 and #36

Markus-P commented 1 year ago

3 years later the usage of 875 (partial construction invoice) for the InvoiceTypeCode (BT-3) still produces an error, although 875 is considered as valid according to https://www.xrepository.de/details/urn:xoev-de:kosit:codeliste:untdid.1001_2#version (and newer versions).

Why does the rule BR-CL-01 still raises an error for this value? Some of our customers with a high compliance expectation tend to reject these invoices because of the incomplete fulfillment of the applying validation rules.

Markus-P commented 1 year ago

Example of 875 as InvoiceTypeCode.

Screenshot 2023-07-20 141502

phax commented 1 year ago

Would it be sufficient to change the error text from "... da die vorhandenen Fehler derzeit toleriert werden." to "... da die vorhandenen Informationen derzeit unkritisch sind." or so?

Or what else can be done, to avoid documents getting rejected due to warnings? The intention is clearly, that warnings are an indicator to senders that something can be improved, whereas for receivers they should be ignored...

Markus-P commented 1 year ago

The problem is that 875 is a valid value and therefore shouldn't produce any error or warning at all.

bdewein commented 1 year ago

It may take a while from publication of codelists to implementation in XRechnung. Codelists are published by various organizations and codelist values are not validated by the XRechnung artifacts, but by CEN validation artifacts. The release cycles of each are not synchronized.

However, the codelist values 875, 876 and 877 were included in CEN Schematron with version 1.3.8 (https://github.com/ConnectingEurope/eInvoicing-EN16931/releases/tag/validation-1.3.8), which is in use since validator-configuration-xrechnung v2023-01-31 / XRechnung 2.3. Thus, the warning should not occur since v2023-01-31. As we cannot reproduce the warning with this or newer versions of validator-configuration-xrechnung v2023-01-31, could you please provide an example invoice that does raise the warning?

Markus-P commented 1 year ago

Oh, I see. We validate invoices of XRechnung 2.2.0 with the validator-configuration-xrechnung_2.2.0_2022-11-15 (included in the xrechnung-2.2.0-bundle-2022-11-15.zip of KoSIT). Should have mentioned that, sorry.

Anyway that's clearly older than 2023-01-31. So that's the reason, why 875... produces the error in XRechnung 2.2.0. I can confirm, that a XRechnung 2.3 validates correctly.

Thanks for the help!!!👍