Moin in die runde,
das stichwort zugferd haben ja ziemlich viele von uns noch auf der liste. Auch wenn man da im Januar noch nicht wirklich in probleme kommt, sollte man das nicht unterschätzen ! dachte ich auch ...
Wir machen ja viel über lazarus mit lazreport und exportieren von da dann pdfs, die auch immer ihren zweck erfüllt haben. pdf output hat wohl fast jede software irgendwie mittlerweile.
Nun ist es aber ja nicht so, das ab Januar jede Rechnung den Zugferd inhalt oder ähnlich zwangsweise haben muss, weil sonst die Rechnung ungültig ist (es sei denn der geschäftspartner zwingt euch dazu).
Es gibt keinen Grund zur Hetik für kleinere Endkunden, denn ab januar ist es nur erforderlich, das Unternehmen solche Rechnungen digital als Eingangsrechnung akzeptieren müssen.
Wenn jemand dann also nur eine komplett unlesbare
xml datei sendet, die dem standard aber entspricht, muss man damit leben. Ich glaub aber kaum eine gute Geschäftsbeziehung ziwschen b2b partnern wird das ungefragt so machen, es sei denn der softwarehersteller kann das nicht anders.
Und um mal vorteile zu erkennen: Bei Zugferd ist ja der vorteil, das es weiterhin einen druck- und meistens auch verständlich lesbaren teil gibt. Wenn man aber zum beispiel viele Eingangsrechnungen verbuchen muss, der kann durch den integrierten
XML teil dann auch vergleichsweise einfach alle relevanten daten daraus importieren und in seine ERP Software packen.
Es stellen sich aber die wichtigen Fragen: wie bekomme ich aus einer solchen pdf die
xml daten heraus? und wie bekomme ich die pdf, die meine software eh schon erstellt, so ergänzt, das diese alle relevanten
xml dateien standardkonform enthält und trotzdem lesbar bleibt.
Da ich heute mal eine relativ ruhigen terminplan hatte dachte ich mir mal, das muss auch irgendwie einfach gehen. Alle tools und frameworks die ich dafür bisher gesehen habe, liessen mich das immer weiter nach hinten schieben.
Was mir dabei schon die ersten kopfschmerzen verursacht hat wurde durch download dieser datei teilweise bestätigt, aber eigentlich auch weniger schlimm als gedacht erscheinen.
https://www.awv-net.de/upload/ferd/ZF232_EN.zip
was bekommt man da? aus meiner sicht ziemliche einfache brauchbare beispiele welchen inhalt die
xml dateien denn nun mindestens haben müssen, um die validierung zu überstehen.
zB "ZF232_EN\Examples\5. XRECHNUNG\XRECHNUNG_Einfach"
Das deckt lange nicht alle möglichen varianten ab, aber die dort liegende
xml datei kann man sich ggf ja zB mit platzhaltern als template ablegen und dann einfach mit den daten der eigenen anwendung füllen (stringreplace oder ähnlich) und dann speichern.
wie bekomm ich den kram nun in eine pdf als anhang? aus meiner sicht war das, nachdem ich das passende open source tool dafür gefunden hatte, ein einfaches. ich mache so was sowieso immer gerne als serverside batch daher fand ich das als kommandozeilen version sehr hilfreich.
welches tool ist das?
https://qpdf.sourceforge.io/ einfach runterladen und ausprobieren.
Ich hab dann nun eine pdf datei aus meiner eigenen software, das mit lazreport erzeugt wurde, einfach mal als datei so gespeichert wie immer. d.h. noch hat es keine integrierten
xml Anhang der das zugferd format vorlegt.
ganz wichtig: der visuelle teil muss nichts mit dem
xml datenteil in eienr zugferd datei zu tun haben. die ausgedruckte pdf kann auch sonstwas anzeigen. es gibt da keine prüfung. Im sinne einer verlässlichen Software wäre es aber hilfreich, wenn das übereinstimmt.
Nun denn, weiter:
Code:
\qpdf\bin\qpdf.exe C:\test\rechnung.pdf --add-attachment c:\test\xrechnung.xml -- c:\test\rechnung_mit_zugferd.pdf
ging ohne fehlermeldung durch. hui. aber ist das auch nun gültig?
also mal auf diese seite datei uploaden und testen
https://belegmeister.de/zugferd-e-re...line-anzeigen/
und siehe da: der findet das scheinbar einwandfrei. was will man mehr ....
weiter geht es mit der eigentlich dringenderen Anforderung das man solche zugferd
xml kram exportieren kann
Code:
\bin\qpdf.exe c:\test\rechnung_mit_zugferd.pdf --show-attachment=xrechnung.xml >c:\test\rechnung_mit_zugferd.xml
wunderbar, da ist alles drin was man braucht ....
hab ich mit mehreren anderen demo dateien auch getestet und alles war problemlos auslesbar.
Leider wissen wir alle das damit zwar nur die Infrastruktur hergestellt ist, nämlich irgendein pdf um die relvanten daten zu ergänzen und aus einer solchen datei den
xml kram auszulesen.
Was nun aber bei welchem Geschäftvorfall mit welchem tag da in den
xml teil rein gehört ist eine komplett andere baustelle.
Es zwingt euch aber auch niemand dazu, das alles was ihr an infos auf die rechnung andruckt, auch zwingend in der
xml sein muss. Es gibt wichtige inhalt die drin sein müssen und der rest kann drin sein, muss aber nicht. Ich kenne Kundenrechnungen an industriekunden, deren Aufbau da ziemlich sicher nicht 100 % abbildbar ist, aber zwingend auf der Rechnung sein muss.
Wenn ihr also zB in Stufe 1 nur das o.a. basic
xml beispiel nehmt und das mit den für euch relevanten daten füllt, wird euch niemand probleme machen.
Wenn der warum auch immer aber mehr haben will, kann man das kundenspezifische zB in firebird als stored proc zusammensuchen, packt die passenden
xml tags dafür in entsprechende teile des results und speichert am ende den sp result als datei ab, die dann mit dem o.a. tool an die evtl eh schon von euch abgelegte pdf angehängt wird. Wir werden das für unsere kunden auf jeden fall so machen, das wir den
xml kram in der
db zusammenstellen und zum speichern per batch zum beispiel mit ibescript/ibeblock ablegen und dann sobald die datei komplett ist nach dem batchaufruf den blod einfach wieder in die datenbank einlesen. Alternativ geht das auch direkt per shellexecute o.ä. aus delphi/lazarus aber alle weitere steps können in eurer software so bleiben wie die sind.
im Moment herrscht unter vielen Anbietern ja goldgräber stimmung. Für die hier beschriebene Funktion könnte ihr so manchen closed source anbieter finden, der minimum 10000 € aufruft und ggf noch runtime lizenzen verkaufen will. Und damit mein ich exlizit SH17 Sven Harazim nicht, denn das Wissen, was sven auch im forum hier und in seinen Komponenten anbietet und umsetzt, stellt in ganz großem Teil den teil dar, geschäftsprozesse in den ganzen
xml mumpitz so einzubauen, das es standardkonform ist. ob das aber am ende irgendein Endbenutzer in allen Details braucht oder die visuelle Erklärung in der ausgedruckten pdf ausreicht, ist immer nur eine Frage zwischen den beteiligten Geschäftspartnern. Das Vorwissen von Sven hatte mich in seiner Remotesession schon positiv beeindruckt, daher in detailfragen ist er da meine Empfehlung als Consultant für den
xml zusammenstell kram.
so, genug für heute, falls jemand meine Erkenntnisse hilfreich fand darf er mir gerne auf den nächsten Forentagen ein bierchen ausgeben oder ein Hotline paket bei uns buchen, um details wenn erfofrderlich zu besprechen oder mit unserer bzw meiner Hilfe dann auch schnell umzusetzen. gerne weise ich noch auf ibexpert preiserhöhungen ab 1.1.2025 hin, wer vorher noch bestellt, hat noch die alten preise ...
Vielleicht hab ich ja jemandem von euch dafür noch einigen Stress über den Jahreswechsel erspart und ihr nutzt dann die Zeit für Familie und Freunde.
Frohe weihnachten an alle