klst-de / e-invoice Goto Github PK

Erkannter Dokumenttyp:
EN16931 CIUS XRechnung (UBL Invoice)

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

wg.

Konformitätsprüfung: Das geprüfte Dokument entspricht keinen zulässigen Dokumenttyp und ist damit nicht konform zu den formalen Vorgaben.
Bewertung: Es wird empfohlen das Dokument zurückzuweisen. Da kein Pruefszenario gegriffen hat.

Tests aus xrechnung validationtool-1.3.0\test\testsuite\

Alle tests sollten XRechnung Spezifikationskennung aus ZUGFeRD 2.1 haben

PROFILE_XRECHNUNG = "urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_2.0"

BG-27 0..n INVOICE LINE ALLOWANCES with
// BT-136 +++ 1..1 Invoice line allowance amount
// TODO bis
// BT-140 +++ 0..1 Invoice line allowance reason code
// BG-28.BT-145 +++ 0..1 Invoice line charge reason code

weder PA noch PK sind valide.

In den UNECE findet man aber diese Codierungen:

warum sind sie dann nicht valide?

für die Einheit HR/Stunde bekomme ich das Validierungsergebnis:

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

• der Beleg wir als not valid gekennzeichnet, was den automatischen Ablauf/Test stoppt:

<?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">

zur Info:

BR-23 : Jede Rechnungsposition „INVOICE LINE“ (BG-25) muss eine Einheit zur
Mengenangabe „Invoiced quantity unit of measure code“ (BT-130) enthalten.

Kontext: Invoice Line
Informationselement: BT-130

see klst-de/e-order@bd0188d

I have a question...

From README.md

  CoreInvoice ublInvoice = new CommercialInvoice(XRECHNUNG_12);
  ublInvoice.setId("123456XX");
  ublInvoice.setIssueDate("2016-04-04");
  ublInvoice.addNote("Es gelten unsere Allgem. Geschäftsbedingungen, die Sie unter […] finden."); // optional
  ublInvoice.setDocumentCurrencyCode(EUR);
  ublInvoice.setOrderReference("1234567890");           // optional
  ublInvoice.setBuyerReference("04011000-12345-34");
...
  CoreInvoiceLine line = new InvoiceLine("1"            // invoice line number
    , new Quantity("XPP", new BigDecimal(1))
    , new Amount(EUR, new BigDecimal(288.79))           // line net amount
    , new UnitPriceAmount(EUR, new BigDecimal(288.79))  // price
    , "Zeitschrift [...]"                               // itemName
    , TaxCategoryCode.StandardRate, new BigDecimal(7)); // VAT category code, rate 7%
    );
  ublInvoice.addLine(line);
...
  transformer.toXML(ublInvoice);

First: this documentation seems like deprecated ? For example CommercialInvoice is flagged as deprecated.
Second: What does the transformer belong to? What's its Object to be initialized with ? Can you maybe provide a full example ?

Thankyou !

PrepaidAmount:

• BG-22.BT-113 0..1 (optional) The sum of amounts which have been paid in advance
• Summe bereits gezahlter Beträge.

einen Testfall gibt es in 03.01a-INVOICE

• 03.01a-INVOICE_ubl.xml

Hallöle,

erst einmal vielen Dank für das Projekt, waber warum ist es kein Maven Projekt?
Man muss sich die fehlenden Abhängigkeiten Mühsam zusammen suchen. :-(

Depending on https://github.com/itplr-kosit/validator-configuration-xrechnung/blob/ac36c5066a791178ffa32ac7f0ba86a452859200/scenarios.xml#L47

Seems like the namespace of Invoice has changed from ubl:Invoice to invoice:Invoice. The e-invoice library seems to generate still ubl:Invoice namespaces like this one:

<ubl:Invoice xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" xmlns:cec="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">

Does that in general happen because I use the cast (GenericInvoice<InvoiceType>) to the CoreInvoice (which is a Type of CoreInvoice anyway) ? Or is that related to your library ?

Thanks !

BG11_SellerTaxRepresentative (without Party)

similar to BG4_Seller

01.15a-INVOICE_uncefact.xml beinaltet:

                <ram:SpecifiedTaxRegistration>
                    <ram:ID schemeID="VA">DE123456789</ram:ID>
                </ram:SpecifiedTaxRegistration>

das führt beim validieren zu Fehlern:

Referenz: 01.15a-INVOICE_uncefact.xml
Zeitpunkt der Prüfung: 26.7.2019 16:33:52
Erkannter Dokumenttyp: EN16931 CIUS XRechnung (CII)

Erkannter Rechnungssteller: [Seller name]
Erkannte Rechnungsnummer: 0000123456
Erkanntes Rechnungsdatum: 20171211

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

Die Ursache ist das schemeID="VA" - Korrekt wäre "VAT"

dort Fehler in (59) DirectDebit/Lastschrift:

  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>59</cbc:PaymentMeansCode>
  
    <cac:PaymentMandate>
      <cbc:ID>[Mandate reference identifier]</cbc:ID>
      <cac:PayerFinancialAccount>
        <cbc:ID>DE75512108001245126199</cbc:ID>
      </cac:PayerFinancialAccount>
    </cac:PaymentMandate>
  </cac:PaymentMeans>

not BG7_Buyer :

	// BG-7 + 1..1 BUYER @see BG7_Buyer
	public void setBuyer(String name, PostalAddress address, IContact contact);
	public void setBuyer(BusinessParty party);
	public BG7_Buyer getBuyer();

• similar in getSeller(), etc

derzeit kann nur ein Seller identifier definiert werden

BusinessParty::setId(String name, String schemeID)

• separate api
• and implementation

das xml war in zugferd2_invoice_pdfa3b.pdf eingebettet - dort validierte es auch nicht, siehe
https://github.com/klst-de/AD-e-invoice/issues/2#ref-commit-46c5432

Der Prüfbericht:

need an example.

test nicht bestanden:

val-sch.1.1 | BR-E-01 | error | [BR-E-01]-
An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is "Exempt from VAT" shall contain exactly one VAT breakdown (BG-23) with the VAT category code (BT-118) equal to "Exempt from VAT".

// SOLL:
	public String getProcessType();
// IST:
	public String getProfile();

Der Name "Profile" suggeriert den Parameter für BG-2.BT-24, wie er in "ZUGFeRD-2.1.1 - Spezifikation_TA.pdf" definiert ist. In dem Technischen Anhang hat man CII im Blick gehabt und den Begriff Profil verwendet:

EN16931-ID: BT-24
Anwendung: 
Profil EXTENDED: urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended
Profil EN 16931 (COMFORT): urn:cen.eu:en16931:2017
Profil BASIC: urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic
Profil BASIC WL: urn:factur-x.eu:1p0:basicwl
Profil MINIMUM: urn:factur-x.eu:1p0:minimum

In EN16931 wird der Begriff ProcessType verwenden. Dieser BT wird in UBL auf ProfileID abgebildet. Das ist irritierend, wenn man den TA von ZUGFeRD liest.

        <ram:IncludedNote>
            <ram:Content>Trainer: Herr […]</ram:Content>
            <ram:SubjectCode>ADU</ram:SubjectCode>   <!-- fehlt -->
        </ram:IncludedNote>

EN16931-ID: BT-21 . Anwendung: Folgende Codes aus UNTDID 4451 werden empfohlen:
AAI : Allgemeine Informationen
SUR : Anmerkungen des Verkäufers
REG : Regulatorische Informationen
ABL : Rechtliche Informationen
TXD : Informationen zur Steuer
CUS : Zollinformationen

ADU ist nicht dabei

"Access rule" is to be defined in eclipse:

Use com.sun.xml.bind.marshaller.NamespacePrefixMapper instaed.
It is in lib jaxb-runtime-2.3.3.jar

• BG-3 hat die Kardinalität 0..n : in CII kann aber nur 0..1 abgebildet werden
• in UBL ist 0..n möglich

Dieser Fehler wurde bereits gemeldet. Siehe ConnectingEurope/eInvoicing-EN16931#207 : Use of BG-3 in CrossIndustryInvoice

/* beim Test von 01.04a-INVOICE_ubl.xml bekommt man

Pos 	Code 	Adj. Grad (Grad) 	Text
val-sch.1.1 	BR-O-02 	error 	[BR-O-02]-An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code 
                                    (BT-151) is “Not subject to VAT” shall not contain the Seller VAT identifier (BT-31), 
                                    the Seller tax representative VAT identifier (BT-63) or the Buyer VAT identifier (BT-46).
                                    Pfad: /ubl:Invoice
val-sch.1.2 	BR-CO-09 	error 	[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’.
                                    Pfad: /ubl:Invoice/cac:AccountingSupplierParty[1]/cac:Party[1]/cac:PartyTaxScheme[1]

*/

Validierungsergebnisse im Detail:

just released ZUGFeRD 2.1 and Factur-X 1.0

in de - Veröffentlichung von ZUGFeRD 2.1