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

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

[AuronTLG]

Wenn man Geschwindigkeit braucht, würde ich wahrscheinlich die externe Validierung weglassen und nur die eigene interne Validierung verwenden, da diese logischerweise blitzschnell geht; immerhin muss man ja nur selbst schnell prüfen, dass für alle Pflichtknoten Informationen da sind, bevor man überhaupt die XML erzeugt.
Die einzigen Nachteile daran sind, dass man sich selbst darum kümmern muss, die Validierung aktuell und korrekt zu halten sowie der zugegebenermaßen ziemlich unwahrscheinliche Fall, dass einem unter Umständen nicht auffällt, wenn eine kaputte XML/PDF rauskommt.

[sqlman]

Danke für die Argumente. -> Brainstorming.

Schreibt Ihr eigentlich Statistiken? Wie viele Rechnungen wurden validiert? Wie viele waren defekt?

Und, wie habt ihr das Problem gelöst, das eine Rechnung aktuell nach Druck unveränderlich gespeichtert wird, nun aber (bei Validierungslauf von 6h, wie einer der Vorredner sagte) eventuell am Rechnungsdatum der 1.3. steht, die Rechnung am 2.3. als fehlerhaft ausgesondert wurde. Die Rechnungsnummer ist futsch. Änderung widerspricht dem Grundsatz der Unveränderlichkeit nach erzeugen/Druck/Versand der Rechnung. Oder fällt das mit dem XML-Anhang (das ist ja die eigentliche Rechnung) dann in den Bereich "Versandadresse(nicht Leistungsempfänger!) der Rechnung ändern" ?

Es muss ja dann storniert werden und neu erzeugt, oder? Wie sind da eure Erfahrungen.

Mir widerstrebt momentan immer noch das dauerhafte prüfen. Auch beim Druck ohne XRechnung/Zugpferd konnten fehlerhafte Rechnungen theoretisch entstehen. Die wurden auch nicht in dieser Art geprüft. Sind dann bei der Betriebsprüfung oder beim Sachbearbeiter oder beim Empfänger aufgefallen und die Welt ist nicht untergegangen. Gesetzänderungen können natürlich vorkommen und man muss dann (wie vorher auch bei der normalen Rechnung) aktuell bleiben. Aber deswegen JEDE Rechnung prüfen?

Noch ein Punkt (eine Meinung) zu:
Wer muss prüfen. Das ist aus buchhalterischer Sicht meines Wissens nach der Empfänger beim Rechnungseingang, welcher eine fehlerhafte Rechnung abweisen muss und den Aussteller informieren muss. Im Betriebsprüfungsfall trägt er die Verantwortung.

Meine Zeit beim Rechenzentrum der Finanzbehörde liegt etwa 100 Jahre zurück. Kann natürlich sein, das sich da etwas geändert hat, aber da wäre es nett, wenn jemand eine Textstelle hat. Solange würde ich sagen: Der Rechnunsempfänger muss beim Eingang validieren. Das macht er ja beim Buchen der Rechnung.

Klar natürlich: Eine Software die hundertfach falsche Rechnungen ausstellt, sollte nicht vorkommen. Aber das jede erzeugte Rechnung durch einen Validator soll...da habe ich ein seltsames Gefühl bei, als ob normale Softwaretests in diesem Bereich auf einmal nicht mehr greifen sollen?