Zugferd bzw XRechnung erstellen

[jojoschluckfirma]

Hallo zusammen,

bevor ich mein Problem schilder habe ich natürlich dass Forum durchsucht und bin nicht schlauer geworden, deshalb hier nun mein Anliegen bzw. Problem.
Ab dem 01.01.2025, so will das Gesetz muss man REchnungn in Elekttoniswch versenden bzw. verarbeiten.
Wir haben ein eigenes geschriebenes Warenwirtschaftssystem in RPG.

Wir übermitteln Rechnungen, mit den vorhanden Boardmitteln, per Mail im PDF-Format an unsere Kunden, außerdem versenden wir Rechnungen im EDI-Format.

Desto Mehr ich im Netz suche und lese umso weniger verstehe ich was die Bundesregierung da möchte.
Schlagwörte:
PDF muss in einem PDF/A-3 sein

Deshalb nun meine Frage:
gibt es jemanden in diesem Forum der mit der gleiche Problematik zu kämpfen hatte und mir eventuell einen Hinweis geben kann wie z.B. einen Link im Netz oder irgendwas damit ich hier weiterkomme bzw. einen Plan bekomme.

Vielen Dank
MFg
Joachim

[Andreas_Prouza]

Wenn ich es richtig verstanden habe, wird ein PDF gar nicht mehr erlaubt sein (nur noch als Beilage).
Es wird wohl ein definiertes Format geben (vermutlich XML) welches die Rechnungsdaten beinhaltet.
Ich habe solch eine Umstellung schon einmal umgesetzt, wo alle Rechnungen an das Finanzamt ebenfalls in elektronischer Form stattfinden muss.
Ich schätze, das gleiche wird jetzt auch bei B2B umgesetzt werden müssen.

Das Format heißt wohl XRechnung: https://www.e-rechnung-bund.de/faq/xrechnung/

[ILEMax]

Melde dich mal bei the-tool-company.de

Die können die ganze Palette.
ZUGFeRD, XRechnung in den verschiedenen Versionen (--> öfter mal was neues ...)

Das individuell nach zu bilden und dann immer dem aktuellen hinterher zu laufen dürfte langfristig keinen Sinn machen. Und die setzen auf deinem RG Spool auf.

Preislich unschlagbar, mit diversen Zusatzfunktionen. (auch ausserhalb von ZUGFeERD)

Grüß vom ILEMax

[Fuerchau]

Ja und Zug(p)ferd und EDI sind damit auch erledigt.
Zum Glück betrifft es nicht alle Kunden, also z.B. nicht den Endverbraucher.
Gut für den Einzelhandel.

[ILEMax]

Die ZUGFeRD Variannte hat halt den Vorteil, das man ALLE Rechnungen einheitlich erstellt.
Kann der Kunde ZUGFeRD verarbeiten, bekommt er die Rechnung elektronisch und freut sich, je nach größe des Betriebes, eine Zeit lang noch zusätzlich auf das PDF schauen zu können.
Kann er es nicht verarbeiten bekommt er das PDF.
Wenn er sich meldet, ich kann es nun, ist nur das markieren als eMail-Empfänger notwendig, alles andere ist bereits fertig.
Beim EDI war es bei uns immer so, das es doch noch hier und da einen extrawunsch gab, so das wir zig verschiedene EDI Versionen hatten.
Der Spooldesigner von Meinikat hat den Vorteil, das er auf der Power läuft.
Die grafische Oberfläche für die Bestückung der ZUGFeRD / XRechnung Felder ist verständlich und mit allerlei Hilfen ausgestattet. Und andere Spools können ganz einfach erweitert / verändert werden um z.B. einen Barcode oder ein Bild hinzu zu fügen.
Aber was soll's, Ihr wisst, das ich Spooldesigner Fan der ersten Stunde bin

[camouflage]

Hi Joachim,

ich bediene ZUGFeRD oder FacturX (das französische Pendant) mit meiner Schnittstelle seit es ZUGFeRD gibt. Ursprünglich habe ich ja mal mit mit dem österreichischen Format ebInterface auseinander gesetzt, nachdem es in Oesterreich Knall auf Fall geheissen hat, keine XML-Rechnung = keine Knete. Das Gleiche mit Italien und dem eigenen Format FatturaPa. Hier ist die Pflicht nicht nur B2B, sondern auch B2C. Und nicht nur das, für bestimmte Wirtschaftszweige wird da sogar die XML eOrder verlangt. Und die XRechnung wird in Deutschland schon jetzt für gewisse staatliche Instanzen vorgeschrieben, nicht erst 2025. Alternativ zu den aufgeführten Formaten habe ich natürlich auch das UBL/Peppol Format realisiert.

Eine kleine Geschichte:
Die Italiener haben mitunter den Spleen, XML Rechnungen abzulehnen, wenn ihnen etwas nicht passt oder Daten haben wollen das gar nicht zwingend vorgeschrieben ist. Hab da schon die verrücktesten Kopfschüttelstories erlebt.

Unschön an der Sache ist halt die mit PDF/A3 für ZUGFeRD. IBM selbst bringt ja nicht mal ein konformes PDF/A1 auf die Reihe. Und wenn ich nur an die Story IBM und Schweizer Zahl QR-Code denke.

Zum PDF noch ein Hinweis:
Die XML Dateien lassen sich in der Regel auch visualisieren, ein PDF braucht es dann nicht mehr zwingend. Die Italiener handhaben das jetzt schon so.

Also, wie Du siehst, ich habe eine ganze Menge an Erfahrung.

Zu guter Letzt:
Es ist wieder typisch, wer bzgl. XML Rechnung den Integrationsschwanz bildet. Die nordische Staaten habe das schon lange und auch die lateinischen Staaten wie in Südamerika stehen da nicht zurück. Nur eines, bis die Schweiz so weit ist, sind die phlegräischen Felder längst ausgebrochen. Und ja, auch Frankreich führt die FacturX ab 2025 zwingend ein.

[wmr]

Guten Tag an Alle,

gerne können wir in beide Richtungen, also Rechnungsein- bzw. Rechnungsausgang mit dem XML-datenstrom im PDF helfen. Vielleicht werden Sie einen Blick auf www.wmr.at.

Grüße an Alle
Wolfgang M. Roser

[camouflage]

... und ich mach mal wieder den Definition/Validierungs-Kolumbus-Hanswurst für diesen unsäglichen Standard. Wenn die linke Hand nicht weiss, was die andere tut. Es wäre schon mal schön, wenn die Definitionen zur Validierung seitens der Herausgeber alle ausgetestet wären oder die Dok korrekt erstellt ist. Wenn das so weitergeht, war der BER geradezu ein Expressprojekt, Mann!

[ILEMax]

Moin,
also die Validierung sollte der Ersteller der Rechnung (bei uns der Spooldesigner von The-tool-company)
schon vornehmen. Trotzdem hat man danach nur ein 'gültiges' Dokument. Wenn der Empfänger bestimmte Daten in den wahlfreien Feldern erwartet, muß das vereinbart sein.

Jedem der es selber programmieren will sei gesagt.
Alle halbe Jahre gibt es eine neue Version, jeden 2. Versionswechsel sollte man (m.E.) mitmachen.
Ziemlich aufwändig

der ILEMax

[Fuerchau]

Nun ja, die Bürokraten benötigen ja auch ihre Lebensberechtigung.
EIn Kunde von mir hat vor ca. 2 Jahren die E-Rechnung für Italien selber entwickelt.
Neben vielen Abstimmungsprozessen war es allerdings für die Italiener wichtig, dass die XML-Information alle in italienisch sein mussten. Also nicht nur die Inhalte sondern auch die Knoten- und Attributnamen.

Was Versionsupdates angeht so weitet sich das in der SW-Entwicklung außerhalb der IBM i-Welt drastisch aus. Ich spreche hier von der Entwicklung in .Net von Microsoft.
Bisher konnte man sich immer darauf verlassen, dass jede neue Version der Net-Framework Runtime abwärtskompatibel ist. Die aktuelle letzte Version ist 4.8.1. Ob es jemals weitere Versionen geben wird ist da fraglich.
Windows Server 2022 ist wohl die letzte Version, auf der das Framework ausgeliefert wird und der Lebenszyklus beträgt hier 10 Jahre. M.a.W: ab 2032 ist hier Schluss, danach gibts nur noch Net-Core.
Auch die alten 32-Bit-Anwendungen soll es dann nicht mehr geben.

Bei Net Core ist es jedoch so, dass es alle 3 Jahre eine neue Version geben wird und die Vorvorversion dann keine Sicherheitsupdates mehr erhält.
Aktuell gibts nun Net-Core 8, die 9 ist schon in der Entwicklung.

Was heißt das für Softwarehersteller?
Sämtliche Net-basierte Software (also auch Nicht-Windows, da Core ja überall laufen soll) muss sich alle 3 Jahre anpassen.
Microsoft gibt keine Garantie mehr, dass neue Core-Versionen zu 100% abwärtskompatibell sein werden.
Z.B. werden Funktionen, die Sicherheitsrisiken haben nicht mehr korrigiert sondern einfach nicht mehr übernommen. Stattdessen werden dann sichere Alternativen angeboten.

Inzwischen kenne ich da schon einige Komponentenhersteller, die das nicht mehr mitmachen und ihre Version eingefroren haben. Somit kann man u.U. seine eigene Software mit neuen Komponenten, die garantiert nicht mehr kompatibel sein werden, neu entwickeln oder eben auch ihren Laden zumachen.

Parallel zu Core gibts noch Net-Standard. Aktuell ist hier Standard 2.1, da Standard 2.0 komplett eingestellt wurde. I.W. sollte Net-Standard Komponentenentwicklung ermöglichen, die zu allen Core-Versionen kompatibel sein sollen. Leider ist wohl 2.1 nur wenig kompatibel zu 2.0, so dass auch hier bereits keine Nachfolgeprodukte mehr angeboten werden.

Da die SW-Entwicklung im Windowsumfeld erheblich stärker von Komponenten abhängt als die IBM i-Entwicklung, stehen sämtliche Komponentenhersteller vor dem Update-Problem.
Im sog. Nuget-Netzwerk gibt es 10.000 Komponenten für alles Mögliche, wobei hier stark auf die Versionskompatibilität geachtet werden muss. Und wenn der Entwickler dann keine Lust mehr hat, steht man auf dem Schlauch und muss sich nach was Neuem umsehen, was sicherlich dann nicht mit dem Vorherigen vergleichbar sein wird und der Kunde wird es einem nicht danken.

Da lobe ich mir die IBM i, die seit V2R1 bis heute immer noch kompatibel ist.
Wenn ich mir dieses Chaos für die IBM i vorstellen müsste, wäre ich wahrscheinlich schon auf Java.

[camouflage]

EIn Kunde von mir hat vor ca. 2 Jahren die E-Rechnung für Italien selber entwickelt. Neben vielen Abstimmungsprozessen war es allerdings für die Italiener wichtig, dass die XML-Information alle in italienisch sein mussten. Also nicht nur die Inhalte sondern auch die Knoten- und Attributnamen.

Baldur,
Ja hätte er mal mit mir gesprochen oder Du, ich hätte dies alles erklären können. Ist halt FatturaPa. Kunden von mir machen das schon seit Jahren, die italienische Regierung verlangt ja dies von jedem der eine Rechnung ausstellt, egal ob Business oder privat. Neuerdings müssen sogar für gewisse Bestellungen diese auch im UBL Orderformat erstellt werden. Diese in ein ERP System zu bringen, ist dann eine ganz andere Hausnummer. Nun, da ich ja auch des italienischen mächtig bin, alles kein Problem.

Und ja, das Nachführen der Versionen kann schon intensiv sein, vor allem das Studium der Dokumentation. Alles in allem ist es dann doch nicht so schlimm, bei guter Beschreibung sind die Änderung im Appendix aufgeführt und leicht zu bewerkstelligen. Grundlegend kann man eh nicht jedesmal alles neu erfinden - der Zorn der Anwender wäre dir zu 1000 Prozent gewiss.