Pascal-Unit zum Erzeugen von ZUGFeRD XML

[KoBraSoft]

Ich habe mit stetig wachsendem Grauen mitgelesen und gottseidank muss ich mich nicht mehr damit auseinandersetzen

Hast Du es gut

Gar nicht, aber darum geht es @KoBraSoft wohl nicht. Sein Argument zielt eher in Richtung Geschäftsprozess und Aufwand.
Formal kann man das XML ja automatisiert prüfen, inhaltlich aber nie.

Exakt

Wenn also jede PDF-Rechnung mit eingebettetem XML manuell auf Kohärenz überprüft werden muss, dann steigt der Personal-Aufwand dramatisch. Von der korrekten Aufbewahrung der Daten einmal ganz abgesehen. Papier liegt die gesetzliche Aufbewahrungsfrist ohne weitere Wartung nur herum. Bei Daten geht das nicht mehr so einfach.

Genau das wollte sagen. Eine reine xml kann man visualisieren, das hätte den Vorteil dass alle Lieferantenrechnungen vom Aussehen her gleich sind. Die Suche wo zB die Rechnungsnummer versteckt ist, vereinfacht sich dramatisch. Und wer braucht schon das Logo des Lieferanten. Die Inhaltliche Überprüfung ist dann effizienter und weniger fehleranfällig. Den Rechnungsinhalt automatisiert in eine Datenbank zu schreiben sollte nicht allzu schwierg sein.

Es geht also IMHO gar nicht um die Vereinfachung der Kommunikation zwischen Firmen sondern um die mögliche automatisierte Kontrolle.

Genau so ist es. Aber Vorsicht, wer das behauptet, landet sehr schnell in der rechten Ecke
IMHO ist das Zugferd eine Totgeburt. Ich werde nicht mehr versuchen es zu reiten. Ich bin da draußen.

[kirchfritz]

Genau das wollte sagen. Eine reine xml kann man visualisieren, das hätte den Vorteil dass alle Lieferantenrechnungen vom Aussehen her gleich sind. Die Suche wo zB die Rechnungsnummer versteckt ist, vereinfacht sich dramatisch. Und wer braucht schon das Logo des Lieferanten. Die Inhaltliche Überprüfung ist dann effizienter und weniger fehleranfällig. Den Rechnungsinhalt automatisiert in eine Datenbank zu schreiben sollte nicht allzu schwierg sein.

So ganz kann ich Deiner Argumentation nicht folgen.
Du findest reines XML gut, weil man es visualisieren kann und damit alle Rechnungen gleich aussehen.
Warum damit die Inhaltliche Überprüfung effizienter und weniger fehleranfällig sein soll, verstehe ich nicht.
Man kann auch bei der ZUGFeRD -PDF Datei die darin enthaltene factur-x.xml extrahieren und anschließend ohne großen Aufwand visualisieren.
Damit hat man den gleichen Zustand wie bei reinen XML-Rechnungen, nämlich dass alle visualisierten Dokumente gleich aussehen.
Bei ZUGFeRD-Rechnungen hätte man das PDF als Vergleichsmöglichkeit, bei reinen XML hingegen gäbe es keine irgendwie geartete Vergleichsmöglichkeit.
Spricht doch eigentlich FÜR ZUGFeRD. Oder?

[charlytango]

Bei ZUGFeRD-Rechnungen hätte man das PDF als Vergleichsmöglichkeit, bei reinen XML hingegen gäbe es keine irgendwie geartete Vergleichsmöglichkeit.
Spricht doch eigentlich FÜR ZUGFeRD. Oder?

Ich habe vom fachlichen keine Ahnung, aber durchaus von tragfähigen Geschäftsprozessen.

Natürlich kann ein XML-File (egal ob für sich alleine oder in ein PDF eingebettet) falsch oder richtig sein.
Aber hat man dazu noch die PDF Datei, ist eine visuelle Kontrolle durch einen Menschen quasi unumgänglich.
Das wird vielleicht mal eine KI machen können. Aber es erhöht mit Sicherheit so oder so den Aufwand und ist wohl auch insgesamt fehleranfälliger.

Für eine Verlagssoftware habe ich mal speziell formatierte Erlagscheine auf ein A4 Blatt drucken lassen und den freien Bereich für Lieferschein oder Rechnung benutzt. Damit entfiel das fehleranfällige getrennte Drucken und danach zusammen finden von Rechnung und Erlagschein. Das hat Ressourcen gespart und Fehlsynchronisationen ausgeschlossen.

Hier ist es genau umgekehrt -- man bekommt zwei Entitäten von denen man sich nicht 100% sicher sein kann dass sie synchron sind. Und das Format im PDF ist noch dazu frei wählbar.

Ist dann schon vorgegeben was gilt wenn die beiden Versionen asynchron sind? Da ist bei 10 Rechnungen täglich kein Problem, aber häng mal ein bis drei Nullen an, dann sieht das alles ganz anders aus.

Spannend wird es dann erst wenn man das Zeug über die gesetzliche Aufbewahrungspflicht aufbewahren muß. Was gilt, wenn sich die Unternehmen hacken lassen und ganze Jahre von Rechnungsdaten samt den Mailservern und Maildatenbanken im digitalen Nirvana verschwinden. Was wird dann die Steuerbehörde tun, wenn die ganze Buchhaltung plötzlich ohne Belege da steht? Ich sehe die Druckerbranche schon jubeln. Es wird halt dann nicht auf der Sender-Seite gedruckt (obwohl .... ggg) sondern auf der Empfängerseite.

Ihr denkt, das gibt es nicht? Ich kenne mindestens ein Beispiel bei dem ein recht großes internationales unternehmen 5 Monate quasi offline war, weil die Server, die Businesssoftware, die Mail-DB und das Routing tot waren. Und keinerlei valide Restorestrategie in peto.

Bin echt gespannt was sich da noch abspielt