Hallo allerseits,

ich bin gerade dabei mein Banking auf Hibiscus und die Rechnungen auf Fakturama umzustellen.

Jetzt habe ich testhalber mal versucht, eine (in Fakturama) selbst geschriebene ZUGFeRD-Rechnung in Hibiscus als Überweisung zu importieren. Leider erhalte ich aber nur eine Fehlermeldung "Angaben zum Inhalt fehlen in der Rechnung".

Weiß jemand was diese Meldung genau bedeutet bzw. wie ich evtl. mehr Infos zum Importvorgang bekommen kann um das Problem einzugrenzen oder am besten zu lösen...?

Grüße
Olaf

PS: die Rechnung hat natürlich eingebettete XML-Infos und wird z.B. von Quba auch korrekt/plausibel angezeigt...

welche Spezifikation wurde verwendet

Wurde ja seit "Hibiscus 2.8.7 (28.12.2018)" eingebunden, daher wahrscheinlich noch 1.0 (aktuell wäre 2.2)
hinzu kommen ja auch noch die jeweiligen Profile.

Vielleicht mal mitteilen oder dein Muster zur Verfügung stellen.

Hallo Infoman,

aus deiner Antwort lese ich jetzt mal, dass Hibiscus nur die Version 1 der ZUGFeRD-Spezifikation versteht und es deswegen nicht funktioniert hat - also die Version der Rechnung eine andere war (was wohl korrekt ist, s.u.) - Richtig?

Die Rechnung wurde mit der aktuellen Version von Fakturama erzeugt, lt. der dortigen Einstellungen als "XRechnung / Factur-X" in Version 2.1 mit dem Profil "ZUGFERD_V2_COMFORT". Laut dem Fakturama Forum auch die einzig funktionierende Einstellung.
Hier hochladen kann ich sie leider nicht, da es eine echte mit Kundendaten war.
Wenn es helfen würde kann ich ggf. aber eine zusätzliche Installation von Fakturama machen und damit eine Demo-Rechnung erzeugen.

das war nur eine Idee, vom zeitlichen Ablauf her
schlussendlich kann es Dir nur der Entwickler beantworten, der hier im Forum ja aktiv ist/mit liest.

ZUGFeRD 2.2 vom 01.03.2022 ist die letzte Version, dh. evtl. sollte auch Fakturama dann angepasst werden
evtl. wird es ja dann in Kürze berücksichtigt - https://www.fakturama.info/aktueller-entwicklungsstand-2/


Evtl. mal dies für den Onlinebanking-Import durchführen: https://www.willuhn.de/wiki/doku.php?id=support:fehlermelden

Die Zugferd-Integration in Hibiscus ist vor einigen Jahren geschrieben worden. Hierbei wurde die Bibliothek "konik-io" verwendet. Leider ist die Weiterentwicklung dort eingeschlafen. Das Github-Repo https://github.com/konik-io/konik ist archiviert worden. Die angekündigte Version 2.0 (https://konik.io/blog.html) ist nie veröffentlicht worden.

Das heisst: Um neuere Zugferd-Versionen in Hibiscus zu unterstützen, reicht es leider nicht diese Bibliothek zu aktualisieren, da es von dieser keine neuere Version gibt. Stattdessen muss die bisherige Zugferd-Anbindung verworfen und neu programmiert werden. Mit einer anderen Programm-Bibliothek, die diese neue Zugferd-Version unterstützt. Unter https://www.mustangproject.org/interface/ gibt es ein Java-Projekt. Das scheint aber nur das Erstellen solcher PDF-Dateien zu unterstützen und nicht das Lesen.

Hallo @hibiscus (irgendwie komisch so ohne Vornamen...),

erstmal danke für die Antwort und überhaupt auch für das super Programm.


Ich habe mir die Doku bei Mustang mal durchgelesen.
Die von dir verlinkte Bibliothek ist zwar in der Tat nur für den Export gedacht, darin wird aber auf eine weitere verwiesen, die für den Import und Validierung etc. zuständig ist, die Invoice-Class.
https://www.mustangproject.org/invoice-class/#reading

Damit müsste es nach meinem Verständnis eigentlich gehen.

Meinst du, es wäre möglich da mal ran zu gehen...?
Konkret bei der Programmierung helfen kann ich leider nicht, da ich von Java keine Ahnung habe (bin PHP-Programmierer), ich kann aber gerne bei Tests etc. helfen.

Das Thema bekommt durch die aktuellen politischen Entwicklungen ja auch neue Relevanz, siehe https://www.heise.de/select/ix/2024/2/2330510331487261336

Grüße
Olaf

Ich habe gerade mal unter https://www.mustangproject.org/use/?lang=de#gradle geschaut, welche Bibliotheken ich brauche, um diese Invoice-Klasse nutzen zu können (beim Lesen des Codes der Invoice-Klasse habe ich nicht herausfinden können, wie man damit die IBAN des Empfängers ermitteln kann):

"org.mustangproject:library" erfordert in Summe 73 JAR-Dateien mit einer Gesamtgröße von 41MB. Das ist doppelt so gross wie ganz Hibiscus. Ein paar Bibliotheken davon gibt es schon in Hibsicus und Jameica (Commons, dom4j, jackson). Der Großteil wäre aber nur dafür nötig.

Unter forum/topic.php?p=130064#real130064 hatte ich hierzu vor einigen Jahren schonmal etwas geschrieben. Damals hatten wir noch von 5MB gesprochen. Heute 40. Das steht in keinem Verhältnis zum Nutzen. Unabhängig von der Dateigröße: Die Menge an Bibliotheken, die dadurch neu in Hibiscus auftauchen, würden auch bei einer Reihe anderer Jameica-Plugins Probleme machen, weil die dort ggf. in anderen Versionen bereits enthalten sind und dann dort Inkompatibilitäten auslösen können. Die sauberere Lösung wäre hier - wie schon in dem älteren Thread erwähnt - ein separates Jameica-Plugin. Dafür fehlen mir aber die zeitlichen Ressourcen.

ok, ist im Moment ja auch eher noch exotisch.

Mir ging es bei dem Test hauptsächlich darum, herauszufinden ob die von Fakturama erzeugten Rechnungen in Ordnung sind.
Das war ja nun leider nicht so erfolgreich

Wenn ich das richtig verstehe, ist Zugferd nichts anderes als ein in das PDF eingebettetes XML. Vermutlich kann man das auch komplett ohne irgendwelche zusätzlichen Bibliotheken lesen. Im Moment fehlt mir aber gerade die Zeit.

das aufwändige ist anscheinend, dass die xml in eine PDF/A-3+-Struktur eingebettet werden muss.
des weiteren gibt es seit 02.2024 anscheinend neue Vorgaben - siehe auch https://www.mustangproject.org/mustang-2-10-0/?lang=de
daher ja auch "Wir werden im kommenden Release voraussichtlich auch XRechnung v3 unterstützen" https://www.fakturama.info/aktueller-entwicklungsstand-2/
dh. die Entwickler sind hier dran die Software auf den aktuellen Stand zu bringen

das auslesen soll einfach sein - "getAttachments()-Funktionalität von pdf.js verwenden"
Quelle
https://www.e-rechnung-bund.de/standard-xrechnung-3-0-1/
nachsteht von der Homepage die Beispielrechnung - https://raw.githubusercontent….CE_ubl.xml

Hallo, vielleicht hilft hier das Projekt XRechnung des Datenbank-Spezialisten Robert Großkopf weiter, das er für LO-Base geschrieben hat mit umfangreichen Erläuterungen.
Zu finden hier: https://de.libreoffice.org/get-help/documentation/
unter -Kurzanleitungen/Verschiedenes/XRechnung.
Die Zusammenarbeit mit Base funktioniert ja recht gut, auch paralleler Zugriff auf die h2DB.
Vielleicht könnte man da etwas zusammenfügen...

ich komme nochmals hierauf zurück
... da ja erst umgestellt werden soll, stellt sich die Frage ob Fakturama das richtige Produkt ist, nachdem die roadmap klick ja nicht im Plan ist und nur ein weiterer Entwickler, bestimmt in kurzer Zeit nicht alles auffangen kann.
daher evtl. schauen ob es nicht bessere Alternativen gibt: Archivierung von Belegen + papierloses Büro - mit welchen Services umsetzbar, gerade auch im Hinblick auf die GoBD.

@hibiscus
bezugnehmend auf #10 (auslesen/anzeigen der Daten) schaue doch auch mal hier:

https://quba-viewer.org
https://github.com/ZUGFeRD/quba-viewer
An wen richtet sich euer Tool? Größte Zielgruppe sind Verbraucher:innen, die eine e-Rechnung empfangen.
Wir sind Quba - Aber wir sind auch Mustangproject
Mustang's Fokus ist die Erstellung und das maschinelle Auslesen von elektronischen Rechnungen. Das beinhaltet das Validieren, also auch das Nachrechnen dieser Rechnungen. Bei Quba geht es um die visuelle, menschenlesbare Darstellung um die Rechnungen inhaltlich und semantisch zu prüfen.
https://quba-viewer.org/p/quba-1-4-0/ u.a. gesponsert bei Würth

https://www.ferd-net.de/aktuelles/meldungen/quba-viewer.html
https://prototypefund.de/project/quba-viewer/

vielleicht ist ja die Reaktivierung / das auslesen der Daten doch umsetzbar.

Das ist in Javascript implementiert und kann daher für Hibiscus nicht wiederverwendet werden.

Technisch umsetzbar ist es natürlich. Man kann das XML sicher mit iText aus dem PDF extrahieren und das dann ganz regulär mit einem XML-Parser lesen. Es ist halt einfach Aufwand, der irgendwann von irgendwem gemacht werden muss.

Ich habe den alten ZUGFeRD-Importer sowie die verwendete Bibliothek "konik.io" jetzt rausgeworfen und das Extrahieren der XML-Daten aus dem PDF per Apache PDFBox neu implementiert. Beim Lesen des XML habe ich mich an den XPath-Ausdrücken aus https://github.com/ZUGFeRD/mus…orter.java orientiert.

Ab morgen gibt es im Nightly-Build bei den Überweisungen ein neues Import-Format "PDF-Rechnung im XRechnung-Format". Das sollte dann auch XRechnung in Version 2 importieren können. Ob Version 3 auch funktioniert, kann ich nicht sagen.

prima

und wegen Format:

Quelle: https://www.e-rechnung-bund.de/standard-xrechnung-3-0-1/

Danke für die Infos. Leider liegen da nur XML-Dateien zum Testen. Das Extrahieren des XML aus dem PDF kann man damit also nicht testen. Da müsste ich den Importer so erweitern, dass er auch direkt mit den XML-Dateien klar kommt.

Download XRechnung Beispiel: XRechnung 3.0.1 UBL

Download: PDF-Ansicht

Quelle: https://invoice-portal.de/rech…-beispiel/

Danke für die Links. In der Beispiel-PDF-Datei wird gar kein embedded XML gefunden. Bin mir jetzt nicht sicher, ob dort tatsächlich eine XRechnung enthalten ist. Müsste man mal noch mit einem anderen Tool testen.

Ich denke, in dem Beispiel-PDF ist gar kein XML enthalten. Es soll nur aufzeigen, was in der XML-Datei unter https://invoice-portal.de/wp-c…-3.0.1.xml enthalten ist.

Laut https://www.mustangproject.org/xrechnung/?lang=de ist für XRechnung ds Hybrid-Format (XML embedded in PDF) gar nicht vorgesehen. Hinzu kommt, dass XRechnung nur für B2B-Geschäfte vorgesehen ist - und auch dort nur "mit Abstimmung". Für Endkundengeschäfte (also B2C) ist das gar nicht gedacht. Da Hibiscus primär eine Software für Privatnutzer ist, würde ich bei der Importmöglichkeit solcher Rechnungen auch das Format priorisieren, welches für Privatnutzer relevant ist. Wenn eine Firma XRechnung direkt im XML-Format mit Hibiscus lesen möchte, können sie die Entwicklung des Features ja sponsoren