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

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

Zitat:

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

...da gehe ich mit. :thumb:

Zitat:

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

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

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. :zwinker:

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. :zwinker:
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. :gruebel:

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 :wink:] 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 :wink:) Rechnungsläufe bis zu 1300 Rechnungen am Tag. Die Validierung braucht bei diesem Volumen 6h+. :roll: 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. :zwinker:

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?

[haentschman]

Zitat:

Das ist aus buchhalterischer Sicht meines Wissens nach der Empfänger beim Rechnungseingang, welcher eine fehlerhafte Rechnung abweisen muss und den Aussteller informieren muss.

...vieleicht sind es aber auch Personen (später auch B2C) die das gar nicht beurteilen können. Weil die Rechnung NUR das XML, ohne PDF, ist. (Beispiel Conrad) Das muß eine Software machen. Das wird ein Spaß, Rentnern zu erklären wie man die Rechnungen liest und zum Bezahlen geben...USB Stick zur Bank. :zwinker:

Zwischenfrage:
Diese Probleme haben auch andere Länder die länger als wir die elektronische Rechnung (verschiedene Formate) benutzen. Wie sind die Erfahrungen? Kann man was lernen? Hat Deutschland die mal gefragt? :gruebel:

[AuronTLG]

Zitat:

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?

Man ist zum Prüfen natürlich nicht gezwungen.
Ich gebe zu, meine Einstellung zum Prüfen ist stark dadurch beeinflusst, dass das bei uns zumindest das in Praxis zwangsläufig notwendig ist, da unsere Anwender eine andere Erwartungshaltung bei ERechnungen haben als bei den alten Papier/PDF-Rechnungen:

Papier/PDF-Rechnung wird abgelehnt -> Ich habe offensichtlich etwas falsch gemacht.
ERechnung wird abgelehnt -> Mein Programm funktioniert nicht. Ich muss auf der Stelle den Support terrorisieren!

Ist ein wenig überspitzt, aber leider nicht allzu sehr.

Zitat:

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.

Ich bin überhaupt kein Buchhalter, aber bezüglich Validierung ist die XRechnungs-Spezifikation ziemlich simpel:

Zitat:

5.1. Umgang mit Rechnungsempfang, Rechnungsannahme
...
...
...
Das Ergebnis der Validierung ist eine Empfehlung hinsichtlich Annahme oder Ablehnung der
validierten elektronischen Rechnung. Die Entscheidung über die Annahme liegt jedoch letztlich bei der rechnungsempfangenden Stelle. Diese berücksichtigt bei der Entscheidung auch
die jeweils gültigen Gesetze und Rechtsverordnungen auf Bundes- oder Landesebene. Die
Entscheidung kann auch automatisiert unterstützt erfolgen

Die Validierung ist also eine reine Empfehlung, sonst nichts.

[sqlman]

Zitat:

Zitat von haentschman (Beitrag 1548637)

Zitat:

Das ist aus buchhalterischer Sicht meines Wissens nach der Empfänger beim Rechnungseingang, welcher eine fehlerhafte Rechnung abweisen muss und den Aussteller informieren muss.

...vieleicht sind es aber auch Personen (später auch B2C) die das gar nicht beurteilen können. Weil die Rechnung NUR das XML, ohne PDF, ist. (Beispiel Conrad) Das muß eine Software machen. Das wird ein Spaß, Rentnern zu erklären wie man die Rechnungen ließt und zum Bezahlen geben...USB Stick zur Bank. :zwinker:

Hier gebe ich dir so etwas von Recht! B2B ist die ERechnung vollkommen in Ordnung. B2C...tja also das wird meiner Ansicht nach nicht funktionieren.

vor allem: Hier sparen wir Papier ein und im Gegenzug gibt es nun für jedes Brötchen einen halben Meter Bon aufgrund der Transaktionsdaten, dann auch noch die Gutscheine und Werbung des Ladens usw....alles auf dem Bon. Und beim Einbuchen eines Stiftes für 2 EUR für das Büro sicht man sich nach dem Datum dumm und dusselig :?

[Rollo62]

Genau, ich kann beim Erstellen 1000x Prüfen, wenn der Empfänger niemals prüft und jeden Mist durchlässt,
dann ist das ganze System eigentlich für die Tonne.
Der Empfänger muss prüfen und bei Fehler dem Sender mitteilen.

Das auch, weil das ganze Eystem hochdynamisch ist und ständige neue Versionen und Regeln rauskommen,
wo keiner genau Bescheid weiss was er braucht und machen muss.
Da ist der Empfänger meiner Meinung nach voll in der Verantwortung, für ihn falsche Rechnungen abzuweisen,
selbst wenn die beim Sender durch die Validierung kämen.

Ich denke es gibt viele Möglichkeiten für logische Fehler, wo ein z.B. Feld falsch benutzt wird,
was dann womöglich durch alle Validatoren kommt, aber trotzdem falsch ist.

Deshalb wäre mein Fazit:
Der Empfänger ist verantwortlich für seine Prüfung, wenn er Aufgrund einer solchen Rechnung eine Überweisung tätigt.
Der Sender sollte validieren, um nicht im ersten Schritt Schrott zu senden und einen Rückläufer zu produzieren.

Mir scheint es aber fast so, dass die Empfänger gar nicht validieren, es dann lieber ausdrucken und abheften.
Schöne digitale Welt :-D

Das Problem sind meiner Meinung nach immer die vollkommen überkomplexen Spezifikationen und nicht vorhandenen Standardtools,
wo am es Ende noch nicht mal ein einfaches Bedienungshandbuch zu gibt und jeder es auf seine Weise interpretieren muss.
Wenn man XRechnung will, dann muss man doch zuerst ein für alle nutzbares Standardtool bereitgestellt werden,
das MustangProject kommt der Sache noch am nächsten, aber ehrlich, ist das was eine kleine Galabau Firma nutzen möchte?
Die muss dann erst noch einen IT-Spezialisten einstellen.

Besser wäre es gewesen, man hätte einfach die auf Papierrechnungen üblichen Felder so leicht und flexibel wie möglich belassen,
das hätte wohl den meisten (99,9%) gereicht.

[haentschman]

Moin...8-)

Ich sehe es so:
Der Versender sollte die Rechnung validieren. Quasi auf syntaktische Richtigkeit prüfen. Der Empfänger sollte die Rechnung auf Korrektheit des Inhaltes prüfen...wie er es schon immer gemacht hat und ggf. beanstanden. :wink: Dazu braucht der Empfänger aber Werkzeuge um das beurteilen zu können. (Einfache! Software)

[arnof]

Ich mache das mittlerweile seit 2020 mit Landrix seinem Tool und habe mich intensiv mit Zugferd und X Rechnung beschäftigt. Ich habe meine Software mittlerweile über 5000 Kunden mit E Rechnung ausgeliefert, aber jeden Tag kommt jemand und hat ein neues Problem. Das kriegt man im Allgemeinen nicht im Griff. Manche Kunden vor allen Dingen große Firmen brauchen zum Beispiel unbedingt die XMP Erweiterung im PDF sonst sagen Sie es ist keine E Rechnung.Die nächsten Kunden. Wollen irgendwelche Angaben haben die eigentlich nirgendswo definiert sind z.B. eine Abrechnungbank will die Objektnummer und solche Sachen wie Vertragsnr und sonstige Sachen in der E Rechnung sehen. Also hier sind ständig Erweiterung nötig. Ich habe allein dieses Jahr schon über zehn Updates gebracht Und jeden Tag kommt ein neuer Kunde mit einem anderen Problem Wunsch oder wo der Endkunde einfach irgendwelche Bedingungen setzt und diese umgesetzt haben will, sonst kriegt man die Rechnung halt nicht bezahlt. Also das ist ein Thema das wird uns lange beschäftigen.