XRechnung ZUGFeRD - Zahlungsmethode - Vorkasse

[Redeemer]

Zitat:

Zitat von sh17 (Beitrag 1544231)

Es gibt den Code 386 Vorauszahlungsrechnung.

Interessant. Hatte ich vorher noch nie gesehen diesen Typ.
Wir hatten das Problem letzte Woche und waren zu dem Entschluss gekommen, dass XRechnung vielleicht nicht mal anwendbar sei, da eine Anzahlungsrechnung keine Rechnung ist.

[user69]

Zitat:

Zitat von sh17 (Beitrag 1544236)

Nutzt Du XRechnung-for-Delphi? Dann gibt es hier Beispiele

https://github.com/LandrixSoftware/X...2TestCases.pas

Danke das hilft schon mal ungemein.

Ich setzte für die Rechnungen nicht delphi ein, da es mir doch recht aufwendig ist ein Rechungsprogramm nachzubauen.

Wir nutzen da sevdesk, besser gesagt stellen gerade darauf um. Aber da die xRechnung noch recht neu ist haperts da doch noch bei einigem. Ich musste aber auch erst mal verstehen was bei der xRechnung geht und wie wir dies abbilden. Gerade für die Vorkassen ist wohl unser derzeitiges Verfahren so nicht mehr nutzbar und wir müssen umdenken. Bei den online shop Rechungen muss sevdesk nachbessern, da die keine Zahlungsmethode dafür haben und eigene fürs xml (verständlicherweise) nicht gehen.

Grundsätzlich finde ich die xRechnung gut, aber die Umsetzung der Rechungsprogramme in letzter Minute (mit zu erwartenden Problemen) finde ich schlecht. So bleibt keine Zeit für Verbesserungen im Vorfeld.

Und ja, ich bin ja noch nicht zur xRechnung verpflichtet, aber große Kunden drängen jetzt schon drauf und wollen normale pdfs per email zukünftig nicht mehr annehmen, nur noch per post.

[Redeemer]

386 führt zu folgender Warnung:

Zitat:

[BR-DE-17] Mit dem Element "Invoice type code" (BT-3) sollen ausschließlich folgende Codes aus der Codeliste UNTDID 1001 übermittelt werden: 326 (Partial invoice), 380 (Commercial invoice), 384 (Corrected invoice), 389 (Self-billed invoice) und 381 (Credit note),875 (Partial construction invoice), 876 (Partial final construction invoice), 877 (Final construction invoice).

Gut, ist nur 'ne Warnung.

[sh17]

in XRechnung mag das sein. Ist das in einer ZUGFeRD 2.3.2 oder XRechnung 3 gekommen?

[Redeemer]

Validiert habe ich eine XML, die mit deiner Bibliothek im Format XRechnungVersion_30x_UBL erstellt wurde.
Sie gehört zwar zu einem ZUGFeRD, aber validiert habe ich sie einzeln.

[AuronTLG]

Ich würde aufgrund kürzlicher Erfahrungen dazu raten, auf Warnungen zu achten, wenn öffentliche Auftraggeber im Spiel sind.

Bei nem Kunden wurde neulich eine XRechnung von einer öffentlichen Stelle zurückgewiesen. Überprüfung ergab, dass alle Validatoren sie als valide eingestuft haben, es aber zwei Warnungen gab, die für die öffentliche Stelle wohl ausschlaggebend waren.
Das wird wahrscheinlich nicht bei jeder Art von Warnung der Fall sein, ist aber eine Möglichkeit.

Es könnte also unter Umständen passieren, muss aber nicht, dass eine öffentliche Stelle keinen Code 386 haben will.

[Redeemer]

Aber was macht man dann mit Anzahlungsrechnungen? 325 würde vielleicht auch passen, aber das wird ebenfalls nicht empfohlen.
326 ist die Teil-Schlussrechnung, aber Anzahlungsrechnungen sind definitiv keine Schlussrechnungen.

[user69]

Ok, nach Rücksprache mit dem Steuerberater ändern wir unser vorgehen:
Es wir immer gleich eine normale Rechnung ausgestellt (bei Vorkasse mit Leistungsdatum in der Zukunft). Dazu gib es dann später einen Lieferschein. Eine Endrechnung ist nicht erforderlich.
PS: das ist unsere Lösung - keine Steuerberatung.

Falls ein Kunde nicht bezahlt könne wir diese sogar einklagen oder aber stonieren.