XRechnung PDF

[Kaschinerl]

Hallo zusammen,
ich bin bisher nicht fündig geworden.
Hier wird grad auf den letzten Drücker die X-Rechnung ins Rechnungsprogramm gebastelt. Kann ich hier ganz stumpf als Anhang die bisher erzeugte PDF packen?

[sh17]

Mach es doch anders herum, pack die XML als Profil ZUGFeRD Extended in die PDF.

[AuronTLG]

Einfachste Möglichkeit ist meiner Meinung nach das ZUGFeRD-Profil "XRECHNUNG".
Damit kann man eine XRechnung nach der XRechnungs-Spezifikation erzeugen und als "xrechnung.xml" in eine PDF hauen.
Dadurch kann man gültige ZUGFeRDs erzeugen, deren XML-Datei auch problemlos von öffentlichen Stellen, die ja nur XRechnungs-XMLs akzeptieren, angenommen wird.
Das einfache daran ist, dass man nicht zwischen der Ausgabe von XRechnungen und ZUGFeRDs unterscheiden muss. Für XRechnung erzeugt man die XRechnung, für ZUGFeRD erzeugt man dieselbe XRechnung und klatscht sie in die PDF.

Das Profil XRECHNUNG wird in der ZUGFeRD 2.3.2-Spezifikation beschrieben und besitzt auch Beispiele. Man muss halt nur beachten, dass man sich bei diesem Profil letztendlich nach der XRechnung-Spezifikation (momentan 3.0.2) richtet, was die XML angeht.

[Kaschinerl]

Danke euch beiden!
Ja, ist dann wohl die geschicktere Variante. Ich hatte mich nur eben in die XRechnung eingearbeitet und die Attachments haben so verlockend ausgesehen.

[TUhr]

Hallo

Meiner Meinung nach kann man auch binäre Daten (z.b. ein PDF) in eine X-Rechnung codiert integrieren. Ob es so in der Praxis genutzt wird, weiß ich (noch) nicht.

MfG
Thorsten Uhr

[Kaschinerl]

Technisch ist es machbar und es wird auch eine valide XRechnung daraus. Meine Frage ging eigentlich eher Richtung Buchhaltung - irgendwas hab ich dumpf im Hinterkopf, dass irgendwas doppelt gewertet werden KÖNNTE.
Ich bin aber ehrlichgesagt nicht wirklich bewandert in diesem Gebiet und bekomme normalerweise Vorgaben, die ich umsetze. Bei Der E-Rechnung ist das leider nicht der Fall.
PDF mit integriertem XML hat für den Empfänger halt den Vorteil, lesbar zu bleiben, deswegen werd ich darauf umschwenken.

[Papaschlumpf73]

Zitat:

Zitat von Kaschinerl (Beitrag 1544346)

PDF mit integriertem XML hat für den Empfänger halt den Vorteil, lesbar zu bleiben, deswegen werd ich darauf umschwenken.

Meine dritte und letzte Wiederholung dazu: Das ist kein Vorteil, sondern ein Nachteil. Für das FA ist zunächst nur der XML-Teil relevant. Sollte der PDF-Teil grob vom XML-Teil abweichen, kann der PDF-Teil als 2. Rechnung gewertet werden. Somit muss der Empfänger immer beide Teile prüfen - also doppelt. (Jetzt halte ich die Klappe - ich weiß, dass viele Kunden trotzdem eine PDF wollen - aber gleichzeitig nach weniger Bürokratie schreien :-))

[Frickler]

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1544347)

ich weiß, dass viele Kunden trotzdem eine PDF wollen

Manch eine Firma hat einen teuren Designer engagiert, um die Rechnungen mit Logo und eigenen Schriften aufzuhübschen. Und jetzt kann das alles ins Klo? Da ist der Wunsch nach der PDF nachzuvollziehen.

[Papaschlumpf73]

Zitat:

Zitat von Frickler (Beitrag 1544353)

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1544347)

ich weiß, dass viele Kunden trotzdem eine PDF wollen

Manch eine Firma hat einen teuren Designer engagiert, um die Rechnungen mit Logo und eigenen Schriften aufzuhübschen. Und jetzt kann das alles ins Klo? Da ist der Wunsch nach der PDF nachzuvollziehen.

Das klingt aber eher so, als wäre es der Wunsch des Versenders und nicht des Empfängers.

[sh17]

Ich wäre für "Klo" :) Am Ende muss die Rechnung gezahlt werden und vom Finanzamt anerkannt.

[Frickler]

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1544354)

Zitat:

Zitat von Frickler (Beitrag 1544353)

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1544347)

ich weiß, dass viele Kunden trotzdem eine PDF wollen

Manch eine Firma hat einen teuren Designer engagiert, um die Rechnungen mit Logo und eigenen Schriften aufzuhübschen. Und jetzt kann das alles ins Klo? Da ist der Wunsch nach der PDF nachzuvollziehen.

Das klingt aber eher so, als wäre es der Wunsch des Versenders und nicht des Empfängers.

Für den Empfänger ist das unkritisch, denn der kann ja auch die XML drucken, mit einem der vielen Viewer. Denn die Rechnungsprüfung findet oft genug noch mit Papier und Stift statt, weil haben wir schon immer so gemacht.

[AuronTLG]

Ich habe die ZUGFeRD<Profil XRECHNUNG>-Variante genau deswegen gewählt:
Beim Rechnungsdruck wird eine XRechnung sowie ein normales PDF-Rechnungsdruckformular aus denselben Daten erzeugt. Die XRechnung wird dann zusätzlich noch in die PDF geknäult, wodurch sich eine ZUGFeRD ergibt.
Damit können die Kunden dann entweder die reine XRechnung verschicken, z.B. wenn sie an eine öffentliche Stelle geht, oder sie können wie gewohnt die PDF verschicken, die mittels deren sorgsam zusammengebauten Rechnungsformularen erstellt wurde.

Persönlich würde ich auch mit einer visualisierten XRechnung absolut klarkommen, nur bin ich halt ITler und kein Kaufmann.
Ich kann aus kaufmännischer Sicht durchaus verstehen, dass man seinem Kunden ein hübsch aufbereitete Rechnung mit Logo, Briefpapier etc präsentieren möchte. Die visualisierte Variante ist nicht direkt hässlich, besitzt aber eine, nennen wir es "spartanische Qualität".
Würde ich die Kunden zur visualisierten Variante zwingen, müsste ich meine Türen barrikadieren...

[Papaschlumpf73]

Wobei die visualisierte XRechnung auch Vorteile hat. Stell dir vor, du müsstest hundert Rechnungen sachlich prüfen - die manuelle rechnerische Prüfung entfällt ja zum Glück. Jede Rechnung sieht anders aus und du suchst dir einen Wolf nach den Informationen. Und jetzt kommen 100 visualisierte XRechnungen. Die sind (noch) nicht schön; du findest die Infos aber viel schneller, weil alle Rechnungen gleich aussehen und du genau weißt, wo deine Infos stehen.

[Papaschlumpf73]

Ich höre gerade die ersten 10 Minuten der aktuelle Folge des Podcasts "Passwort" aus dem Heise-Verlag. Da die haben was ausgebraben, an das ich auch noch nicht gedacht habe: In der PDF-Datei steht alles richtig drin: Bestellmenge, Preise, Rechnungsbetrag usw.

Diese PDF-Datei wird von der Fachabteilung als "sachlich" richtig geprüft und zur Bezahlung an die Buchhaltung gegeben. Die haben natürlich vernünftige Software, welche den Betrag der xml-Rechnung an das angegebene Konto überweist.

Wenn jetzt in der xml-Rechnung 100x höhere Beträge, als in der PDF-Rechnung stehen, merkt das erstmal keiner. Natürlich passiert das nicht mit regelmäßigen Vertragspartnern. Aber bei einer einmaligen Bestellung für Weihnachtskalender, Kaffeetassen oder sonstwas, könnte schnell ein großer Betrag per SEPA-Überweisung rausgehen, der dann nicht mal einfach so zurück gebucht werden kann. Und das Konto kann ja auch gut im Ausland sein.

[Papaschlumpf73]

Je länger man drüber nachdenkt, desto unsinniger ist das ZUGFeRD-Format.

[AuronTLG]

In diesem Fall griffe das hier:

Zitat:

Der Aussteller der Rechnung bzw. das Unternehmen, in dessen Namen die Rechnung durch
einen Dritten, mit dem eine Mandatsvereinbarung für elektronische Rechnungslegung besteht, erstellt wird,
ist verantwortlich für die Konsistenz der Informationen der hybriden Rechnung. Das bedeutet, dass
sichergestellt sein muss, dass alle in der strukturierten Datendatei enthaltenen Informationen, mit denen in
der lesbaren PDF-Repräsentanz vorhandenen übereinstimmen (identische Datensätze).

Macht es natürlich nicht viel besser. Unter anderem deswegen habe ich es bei uns tatsächlich so implementiert, dass bei einer extern kommenden ZUGFeRD automatisch auch aus der enthaltenen XML eine Visualisierung erzeugt wird, die man sich bei der sachlichen Prüfung dazu anschauen kann, denn es gab bei mehreren Kunden schon Fälle, wo bei einer Lieferanten-ZUGFeRD PDF und XML nicht zusammengepasst haben und es dann Überraschungen beim Auslesen gab.

Wäre es nach mir gegangen, hätten wir es so gehandhabt wie in Italien: Ein einziges Format, eine zentrale Schnittstelle, nur die XML zählt rechtlich, keine ewigen Umsetzungsfristen.
In dem Fall hätte ich den Kunden dann auch leichter vermitteln können, dass sie sich von ihren geliebten Briefrechnungen verabschieden müssen. Kann ich so, wie die Lage bei uns ist, aber natürlich nicht machen, also gibt es ZUGFeRDs.
Die Italiener sind uns übrigens, wenn bei uns dann 2028 wie momentan geplant die vollständige Einführung der XRechnung kommt, mehr oder weniger 10 Jahre voraus. Ziemlich peinlich...

[farnk]

An alle die eine XRechnung in ein PDF packen wollen.
Mit Delphi 12.2 und fastreport vcl ist das möglich.
In den Demos von Fastreport sind XRechnungen enthalten.
Der Haken ist nur, das die dabei erzeugten PDFS zur zeit
noch invalide metadaten enthalten.
Wenn man in der frxExportPDF.pas in der Funktion TfrxPDFExport.AddMetaData;
seine eigenen validen Metadaten einbaut, klappt es.
(fehler ist schon an Fastreoort gemeldet).

// Austausch des meta_xml-Inhalts
xmlFile := TStringList.Create;
try
xmlFile.LoadFromFile('XRechnungMetadata.xml');
meta_xml := AnsiString(xmlFile.Text);
xmlFile.Free;
finally
// xmlFile.Free;
end;

Das hier ist der Knackpunkt.
// PDF-Export konfigurieren
frxPDFExport1.FileName := Rechname;
frxPDFExport1.PdfA := True;
frxPDFExport1.PDFStandard := psPDFA_3b;
frxPDFExport1.AddEmbeddedXML2('ZUGFeRD invoice', Now, XMLStream, TZUGFeRD2_Profile(3)); // 0 bis 5

Im XMLStream ist die zuvor mit Delphi erzeugte XRechnung.

Die Erstellung der RechnungsXML in Delphi ist relativ simple.
Man nehme sich eine MusterXML , baue sich Platzhalter in die Struktur
Lese die Struktur und ersetze die Platzhalter durch die Werte vom Programm.
Eine einzige Funktion mit weniger als 200 Zeilen code.
Mit https://erechnungsvalidator.service-bw.de/ kann man sich dann die XML validieren lassen.
das PDF mit verapdf (super !)
Das PDF kann man sich auch mit https://www.portinvoice.com/ validieren lassen

Gruss Frank

[farnk]

Hier noch ein paar Tipps zur Steuerberechnung:

// Ansatz 3: Steueraufschlüsselung mit Rundung nach den offiziellen Regeln (nach EN16931)
// Laut den europäischen Standards (z. B. EN16931) und den Anforderungen von ZUGFeRD/Factur-X wird empfohlen,
// die Steuerbeträge wie folgt zu berechnen:
// 1. Schritt: Berechne den Netto-Betrag pro Position und runde ihn auf 2 Dezimalstellen.
// 2. Schritt: Berechne die MwSt pro Position, aber runde erst nach der Addition aller Steuerbeträge.

// Steuersatz BT-151 (Umsatzsteuerkategoriecode) Erklärung
// 19 % S Standardrate (normaler Steuersatz in Deutschland)
// 7 % AA Ermäßigter Steuersatz
// 0 % Z Steuerbefreit
// keine Steuer O Außerhalb des Steueranwendungsbereichs

Nach meinem Wissen sind bei der Steuerberechnung max.Abweichungen von 1 cent
erlaubt sonst gibt es einen Validierungsfehler.
Deswegen sollte man bei der Berechnung der
VkNettogesamt pro Position zuerst auf 2 Nachkommastellen runden
und dann die MWst mit voller Genauigkeit berechnen.

Nachdem man dann die MWst aller Positionen mit der vollen Genauigkeit berechnet hat,
wird diese dann zum Schluss auf 2 nachkommastellen gerundet.

In einer grossen Rechnung hat 1 cent gefehlt.
Dabei ist folgender Fehler bei 1,15 * 4,90 = 5,635 in Delphi passiert. Ergebnis muss 5,64 lauten

Erst nachdem ich das so umgestellt hat,
hat er richtig gerechnet.
// VkNettoGesamt := Int(VkNettoGesamt * 100 + 0.5) / 100; Falsch
VkNettoGesamt := VKNetto * Menge;
VkNettoGesamt := VkNettoGesamt * 100;
VkNettoGesamt := VkNettoGesamt + 0.5;
VkNettoGesamt := int(VkNettoGesamt) / 100;


Gruss Frank

[omnibrain]

Zitat:

Zitat von farnk (Beitrag 1545107)

In einer grossen Rechnung hat 1 cent gefehlt.
Dabei ist folgender Fehler bei 1,15 * 4,90 = 5,635 in Delphi passiert. Ergebnis muss 5,64 lauten

Delphi rundet wissenschaftlich, statt kaufmännisch.