Wie sieht die Zukunft mit XRechnung, ZUGFerD, Peppol und Co. aus ?

[stalkingwolf]

Zitat von AuronTLG:

Zitat:

Wenn ich unseren Kunden eine PDF mit E-Rechnung als Anhang senden will. Was nehme ich dann am besten für ein Format?

Das hängt von den geschäftlichen Umständen ab.

Ich persönlich benutze das ZUGFeRD-Profil XRECHNUNG. Dieses besteht darin, dass man eine XRechnung (auf Grundlage des XRechnungsformates) in die PDF steckt.
Hintergrund ist, dass meine Kunden häufig ERechnungen an öffentliche Stellen schicken, die nur reine XRechnungen und keine ZUGFeRDs akzeptieren während die Geschäfts- oder Privatkunden ihre normalen PDFs haben wollen. Mit dem ZUGFeRD-Profil XRECHNUNG erzeugt man in allen Fällen gültige XRechnungen, die man entweder in eine PDF stecken kann, für B2B oder B2C, oder auch nicht, wie eben im Falle einer öffentlichen Stelle als Empfänger. Man muss also nur ein Format pflegen.

Edit: Ups, glaube ich habe das missverstanden. Es geht nicht darum, ein ZUGFeRD-Erzeugung bereitzustellen, sondern nur darum, selbst ZUGFeRDs an Kunden zu verschicken, oder?

Hallo. Danke für die Info. Wir haben das ganze umgestellt und damit hat es direkt funktioniert.
Die Datei werden ohne Warnings akzeptiert.

[Rollo62]

Ist vielleicht auch interessant, zum Thema Kleinunternehmer
https://www.onlinehaendler-news.de/r...men-verwirrung
http://www.dstv.de/stellungnahmen-po...vom-18.03.2025
https://www.bundesfinanzministerium....cationFile&v=3

[sqlman]

Hallo zusammen,

auch wir sind, wie viele andere, gerade in der Implementierungvon ZUGFerD, XRechnung usw.

Erst einmal vorweg vielen Dank an die vorherigen Verfasser, das ihr euer Vorgehen hier darstellt. Ich bleibe mit meiner Frage daher mal hier im Thread (wenn falsch, bitte Hinweis), da es - so denke ich - hier ganz gut reinpasst (Zukunft mit XRechnung/ZugPferd).

Unser aktuelles Vorgehen wird sein, die aktuelle PDF-Rechnungserzeugung mit dem XML-Rechnungsanhang zu versehen. Für unsere Kunden scheint das momentan der einfachste Weg.

Folgende Dinge, liegen aber bei uns noch im Nebel verborgen. Zumindest hatte ich bei diesen Frage Probleme, das hier im Thread herauszulesen:

Validierung: aktuell gehe ich davon aus das diese nur während der Implementierung beim Test nötig ist? Manchmal klingt es, als ob jede Rechnung nach Erzeugung validiert werden sollte? Das verstehe ich da dann doch falsch, oder?

Ausgehend davon, das nicht jede Rechnung validiert werden muss: Was passiert eigentlich, wenn die XML dann mal "kaputt" ist? Storno der Rechnung und neue Rechnung unter neuer Rechnungsnummer mit korrigierter Programmversion erzeugen? Oder wird nur die Rechnung wie früher als Duplikat gedruckt und der XML-Teil korrigiert?
Geht ja auch nicht, weil ja nach dem Druck/erzeugen der Rechnung diese unveränderbar archiviert werden sollte. Im obigen Beispiel habe ich dann eine fehlerhafte ZugFerd-Rechnung im Archiv. Was erst einmal seltsam ist, aber (Annahme) aus Prüfersicht richtig, weil die ja ganz normal storniert und neu erzeugt würde?

Wie oft sind solche Fälle (Rechnung ist im XML-Format fehlerhaft und wirft beim Kunden Probleme auf) in euren Implementierungen vorgekommen und wie seid ihr damit umgegangen?

Kurze Info: Unser Softwareprojekt ist eine Software für Heizkostenabrechner/Energielieferanten/Stadtwerken. Von Sachbearbeitern werden hunderte Rechnungen erzeugt, die meisten davon automatisiert.

Danke im voraus
Gruß
Ralf

[BlueStarHH]

Jede Rechnung sollte validiert werden. Durch andere Inhalte könnte die Rechnung ja ungültig werden.

[AuronTLG]

Auf irgendeine Weise MUSS unbedingt validiert werden, entweder durch einen selbst oder durch einen externen Validator wie Mustang.
Es sollte für den Anwender nicht möglich sein, eine ungültige oder gar kaputte XRechnung zu erzeugen, und wenn, muss er deutlichst darauf hingewiesen werden.
Was für einen Sinn macht es, still und heimlich eine kaputte oder nicht valide XRechnung zu erzeugen, die dann vom nichts ahnenden Anwender irgendwohin geschickt, mit 100%iger Wahrscheinlich abgelehnt und dann zurückgeschickt wird, woraufhin sich der Anwender einen Ast freut?

Ich mache vor meinem "Druckvorgang" quasi zwei Validierungen. Die erste ist intern von mir selbst erstellt und schaut nach typischen Fehlern und häufig fehlenden Informationen, zu denen sie programmspezifische Hinweise gibt, wie die zu beheben sind.
Ist die interne Validierung in Ordnung, erzeuge ich eine XRechnung und jage den Mustang-Validator drüber. Gibt der auch sein OK, wird der "Rechnungsdruck" ausgeführt.

[Rollo62]

Validieren ist schon sinnvoll.
Aber ist es nicht so, dass eigentlich der Empfänger validieren muss, sonst darf er kann er das nicht weiterverarbeiten?

Meine Kunden sind aktuell noch in der Umsetzung und manchen ist die Validität ziemlich Wurscht.
Ich frage mich, ob DATEV oder sonstige Rechnungswesen Apps da validieren ( und nein, meine Kunden haben kein SAP sondern eigene Lösungen ).

Gibt es vielleicht schon eine Liste kompatibler Software?

[sqlman]

Das validieren sinnvoll sein könnte ist keine Frage, aber ist das Framework bzw. die Datenstruktur so instabil, das validiert werden muss/sollte? Ich meine, ein Prozess der durchgetestet worden ist, muss der ständig wieder überprüft werden? Beim Kunden?
Sollte nicht schon das Erzeugen einer nicht korrekt Rechnung wie im normalen Rechnungsdruck aufgehalten werden? Es werden doch nur bestehende Rechnungsdaten in eine XML-Struktur gewandelt.(Bin hier noch zu ahnungslos, daher subjektive Meinung)
Das ganze System (Zugferd und Co) wäre keine gute Lösung, wenn die Sache so kompliziert wird, das alle erzeugten Rechnungen dieses Landes durch einen Validator müssen. Oder...hm, weiss nicht.

@Rollo: Interessante Frage, ob "Standardprogramme" Lexware, Sage, usw. validieren. Weiß jemand mehr?

Da ich beim Validieren anscheinend die Java-Runtime Nachteile (also etwas, das ich gerade bei der Wahl Delphi als Sprache vermeiden wollte) hereinhole, habe ich dabei Bauchschmerzen. Habe seit mehr als zehn Jahren nichts mehr mit Java (gottseidank) zutun gehabt. Und jetzt müsste auf einmal wieder Java mit in unsere Infrastruktur? Oje.

Gruß
Ralf

[haentschman]

Hallöle...

Zitat:

Auf irgendeine Weise MUSS unbedingt validiert werden, entweder durch einen selbst

...da gehe ich mit.

Zitat:

Was passiert eigentlich, wenn die XML dann mal "kaputt" ist?

...die Frage stellt nicht, weil IMMER validiert wird.

Zitat:

Ich meine, ein Prozess der durchgetestet worden ist, muss der ständig wieder überprüft werden?

...auch der Gesetzgeber hat ggf. Änderungen. Deshalb muß auch der Validator angepaßt werden, um die Rechnungen zu prüfen.

Zitat:

Aber ist es nicht so, dass eigentlich der Empfänger validieren muss, sonst darf er kann er das nicht weiterverarbeiten?

[Meine Meinung] Nein. Aber er kann validieren, wenn er möchte, um sicher zu sein. Das sollte die Software, die er verwendet, leisten können. Da sind wir wieder bei der Frage...was können die Anderen. Bei denen sind es dann Eingangsrechnungen.
PS: Die Eingangsprüfung sollte auch eine Prüfung des PDF "Rechnungsbetrages" zum eingebetten XML beinhalten. (Manipulation der Rechnung auf dem Weg)...ich weiß nicht ob das jemand macht.

Zitat:

Sollte nicht schon das Erzeugen einer nicht korrekt Rechnung wie im normalen Rechnungsdruck aufgehalten werden? Es werden doch nur bestehende Rechnungsdaten in eine XML-Struktur gewandelt.

Grundsätzlich hast du mit der XML Struktur Recht. Du brauchst aber auch das PDF. Aber...
Problem 1:
Die XML muß mit dem PDF gemerged werden. Meistens über ein externes Tool. Beim PDF müssen verschiedene Voraussetzungen stimmen. Am Ende ist es ein PDF/A [Achtung Werbung ] Wir verwenden DynaPDF.
Problem 2:
Die Valdierung nach der Rechnungserstellung.

Zitat:

Von Sachbearbeitern werden hunderte Rechnungen erzeugt, die meisten davon automatisiert.

Jede Validierung eines Beleges braucht ca. 5 Sekunden (nach oben offen je nach Menge der Pos) bei uns. Bei einer Einzelrechnung fällt das Versenden im Workflow (Versenden per Mail) fast nicht auf. Dauert aber länger als sonst.
Wir haben aber manchmal (selten ) Rechnungsläufe bis zu 1300 Rechnungen am Tag. Die Validierung braucht bei diesem Volumen 6h+. Soll der Mitarbeiter nach Hause gehen? Das ist im normalen Workflow nicht abzubilden.
Da muß man sich was einfallen lassen...
* Thread in der Anwendung, seperates eigenständiges Tool was den Versand übernimmt.
* Rückmeldungen der Validierung speichern und Fehler ggf. anzeigen.

Zitat:

Da ich beim Validieren anscheinend die Java-Runtime Nachteile (also etwas, das ich gerade bei der Wahl Delphi als Sprache vermeiden wollte) hereinhole, habe ich dabei Bauchschmerzen

...wir haben die "Struktur" (Bild) auf dem Server abgelegt. Keine Probleme. Für den Aufruf haben wir eine Klasse erstellt die Ergebnisse "kapselt".
https://github.com/LandrixSoftware/X...elphi/releases

Delphi-Quellcode:

// Auszug unvollständig
function TXInvoice.Validation(XML: string): Boolean;
var
  ValidationHelper: IXRechnungValidationHelperJava;
  XMLStream: TStringStream;
begin
  Result := False;

  if XML > '' then
  begin
    CoInitialize(nil);
    XMLStream := TStringStream.Create(XML, TEncoding.UTF8);
    try
      FInvoiceVersion := TXRechnungValidationHelper.GetXRechnungVersion(XMLStream);

      ValidationHelper := GetXRechnungValidationHelperJava;
      ValidationHelper.SetJavaRuntimeEnvironmentPath(FJavaRuntimeEnvironmentPath);
      ValidationHelper.SetValidatorLibPath(FValidatorLibPath);
      if FInvoiceVersion in [XRechnungVersion_230_UBL, XRechnungVersion_230_UNCEFACT] then
      begin
        ValidationHelper.SetValidatorConfigurationPath(FValidatorConfigurationPath23x);
      end
      else
      begin
        ValidationHelper.SetValidatorConfigurationPath(FValidatorConfigurationPath30x);
      end;
      Result := ValidationHelper.Validate(XML, FCmdOutPut, FXmlResult, FHtmlResult);
    finally
      XMLStream.Free;
      CoUninitialize;
    end;
  end;
end;