XRechnung PDF

[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.