ZUGFeRD - Elektronische Rechnung

[loeweadolf]

Hallo,

heute wurde ich von einem Kunden angesprochen bzgl. Elektronischer Rechnung
ab 2025.
Am liebsten wäre ihm ZUGFeRd (nicht Edifakt).

Gibt es das für die AS-400?

Im Internet habe ich gelesen, dass es sich wohl um die Ausgabe der Rechnung
als PDF handelt. In dem PDF ist gleichzeitig eine XML-Datei eingebunden, die die
Daten der Rechnung enthält.

Was kann ich machen ?

[Fuerchau]

Nun, am besten die Fragen, die sowas auch auf der IBM i machen.

https://www.google.com/search?q=ibmi+zugferd

Native geht das nun mal nicht mit Boardmitteln.

[B.Hauser]

Schau mal bei Meinikat und ROHA

[loeweadolf]

Danke sehr fürs Erste.

[camouflage]

Ich hab das schon lange realisiert, seit Beginn der ZUGFeRD Definitionen im Extended Format. Das geht sehr wohl native auf der IBM i, nur das Einbinden in das PDF benötigt einen Java Teil. Dazu ist weder IBM noch Gumbo fähig, obwohl sie es schon lange wissen. Allerdings wird das PDF nicht zwingend werden, es geht auch als reines XML. Dazu es gibt als Equivalent auch noch Factur-X, X-Rechnung und die ganze UBL Fraktion. Daneben wären auch noch die kommenden Anforderungen der Bestellungen wie Order-X oder UBL Order 2.1 zu beachten. In Italien ist das für gewisse Bereiche bereits zwingend. Geht auch native auf IBM i.

[Fuerchau]

Klar, kann ich alles dafür selber entwickeln. Java ist da durchaus ein Kandidat.
Allerdings ist das mit nicht unerheblichem Aufwand verbunden und ob jeder IBM i Nutzer auch eigene Kapazitäten für die Entwicklung hat, kann ich schon lange nicht mehr glauben.
Die Eh-da-Kosten sind da nicht zu unterschätzen.
Da kann es schon mal preiswerte sein, die Leistungen zuzukaufen, zumal wenn da bereits langjährige Erfahrungen vorliegen da die Formate schon durchaus lange existieren.

Vielleicht kannst du ja einfach deine Lösung als Zip hier rein stellen mit dem Hinweis auf "freie Nutzung des geposteten Codes";-)?

[Robi]

Moin zusammen,
Baldur hat natürlich mal wieder recht! Natürlich kann ich das alles selber entwickeln.
Tool Hersteller wie wir können ja auch nicht zaubern.
ZUGFeRD, X-Rechnung, 'einfaches' XML, u.v.m.
Der Vorteil: Man erstellt genau das, was man (glaubt) zu brauchen.
Der Nachteil: man hat nur das erstellt, was man glaubte zu brauchen.
Anpassungen / Erweiterungen / neue Versionen / neue Funktionen, das ist der Rattenschwanz, den man bewältigen MUß!
Diese Zeit hört NIE auf ...
Ausserdem bringt ein Tool den Vorteil, einige andere Features zu bieten.
mal eben eine Barcode, QR oder Strich., Hervorheben von Informationen, Kästen, Linien, zus. Infos als dynamischen Textbaustein. Infos aus dem Spool weglassen, Excel, u.v.m.

Ibm hat die 'eigene' Textverarbeitung vor Jahren eingestellt.
Einfache Begründung:
Soetwas kann man günstig kaufen. Das hat jeder verstanden.

Elektronische Rechnung mit PDFA/A, geprüft, kann man auch günstig kaufen.
Günstiger als man denkt!

Meldet Euch für eine kostenlose Online Demo

[camouflage]

Ganz so trivial ist die Geschichte nicht, wie man manchmal zu glauben macht. Ich entwickle seit Jahren explizit auf UBL und EN16931 mit der IBM i. Mit dem simplen PDF ist es eben gerade nicht getan, auch nicht mit einem Spool auslesen. Anforderungen von Kunden und Finanzämtern verlangen manchmal viel mehr Daten als auf herkömmlichen Rechnungen stehen. ZUGFeRD oder X-Rechnung ist nur ein Format unter vielen das abgebildet wurde - es sind noch viel mehr. Wenn Robi seine Lösung anpreist, sein gutes Recht. Allerdins wird nichts nach Baldurs Vorschlag einfach so in's Netz gestellt. Oder Baldur, magst Du dein FTIS auch so anbieten? Finde es nicht so lustig, hast einige Sympathien verspielt mein Lieber!

Die NET:BILLER Lösung erlaubt XML-Erstellung verschiedenster Formate UBL und EN16931 aufgrund klar definierter Schnittstellen, Import der XML Daten, sowie auch die Abbildung der Order BIS 3.0 und Order-X und zwar als Export wie Import. Die PDF Erstellung ist sekundär (das ginge sogar mit Bordmitteln), es geht vielmehr um eine hochwertige und aktuelle XML Erstellung für verschiedenste Länder.

Abgesehen davon, das EN16931 Format ist wieder mal die komplizierteste Art den XML Datenaustausch zu implementieren. Ausser DE und FR verwendet den praktisch niemand und die X-Rechnung kann auch in einem Unterhalt freundlicherem UBL Format erstellt werden.

Und es soll mir jetzt keine(r) noch mit SQL kommen. Kann man machen, viel Spass!

Wenn es um eInvoicing und XML geht, kann man sich alternativ bei Ecosio, Seeburger oder Menten (i-effect) umschauen. Nur der Vollständigkeit halber, ich hab damit kein Problem.

[Robi]

Trivial nicht, unmöglich auch nicht.

Der SpoolDesigner war das erste iSeries Produkt das ZUGFeRD konnte und kann heute alle Formate, die unsere Kunden brauchen. Fehlt eins, kommt es hinzu!
Das KnowHow ist vorhanden, ganz anders als bei einem engagierten Entwickler, der das mal für seinen Chef ganz toll lösen will.
Fehlende Daten werden i.d.R via Schnittstelle, die bei uns UserExit heist, geholt.
Das macht der Kunde wenn er will/kann selber oder wir machen das für Ihn.

Niemand hat von einem simplen PDF gesprochen.

Du hast beschrieben das du es selbst gelöst hast, das klang schon ein bisschen nach: 'alles ganz easy'!
Baldur und ich haben nur bestätigt das das geht.

Unser SpoolDesigner ist auch eine eigene Entwickung und allgemein, für jeden einsetzbar.
Kunden ohne Sourcen nutzen die vorhandenen Spools genau so wie andere die keine Userexit wollen und daher ihren Spool mit zusätzlichen Daten anreichern.

Das 'besondere' am SpoolDesigner ist ja, das er NICHT speziell für Rechnungen ist.
Alle Spoolausgaben können verändert / verschönert / verschlimmbessert werden.
incl. PDF, PDF/A, Mail, Excel, TEXT, u.v.m. selbst die Ausgabe einer Schlagwort Datei für DMS Systeme ist möglich

[camouflage]

Diese Diskussion ist mir jetzt doch zu blöd.

Ich wollte Ludger eine Antwort auf seine Frage geben und wenn er wissen will wie das geht, erklär ich es ihm gerne. Ich denke, dafür reicht das Knowhow noch.

[Fuerchau]

Ich bitte um Entschuldigung, wenn meine Ironie hier nicht rüber gekommen ist.

Aber die Beiträge zeigen auf jeden Fall auf, dass es mal eben nicht so einfach ist, wie es scheint.
Unsere Bürokraten machen uns halt das Leben schwer, aber verdienen wir nicht damit auch unser Geld?

Wie in einem anderen Thread schon erwähnt, ist selbst das Erstellen von PDF/A-x., ohne Hilfsmittel wie Java eben nicht native möglich. Und erzählt nun nicht, dass Java auf IBM i native IBM ist.
Natürlich kann man auch jede andere Sprache nehmen, die das unterstützt.

Und ich vermeide es inzwischen bewusst, Produktempfehlungen hier zu nennen, denn dafür gibts einfach zu viele und ich mag nicht entscheiden.