Moin, generell ist der aktuelle ZUGFeRD-Export schon in der Beta drin. Wann die freigegeben wird kann ich echt noch nicht sagen. Zum einen möchte ich die Anmerkungen hier noch mit einarbeiten, zum anderen hatte ich größere Pläne bezüglich Import/Export von Daten. Da ich derzeit "nur" erst mal die Umstellung auf Java 11 geschafft habe (was schon ein ziemlicher Brocken war) werde ich mich noch an die anderen Tickets machen. Der Fortschritt ist im Bugtracker immer ganz gut abzulesen. Da gibt's eine Roadmap, wo man auch die offenen und gelösten Tickets sieht. Das ist für die 2.1.1 noch nicht ganz so dolle. Du kannst aber wenn Du möchtest auch schon mit der Betaversion arbeiten. An der Datenbank werde ich voraussichtlich keine Eingriffe mehr machen, von daher ändert sich nur in der Oberfläche noch bißchen was. Momentan ist mein Zeitplan aber etwas eng, weil ich auch noch andere Sachen mache (z. B. Konzerte 😉 ). Updates für die Beta wird es sporadisch geben. WICHTIG: Ab dem nächsten Beta-Release ist Java 11 angesagt! Bitte schon mal drauf vorbereiten. Ich hab's auch schon in den Ankündigungen geschrieben.

Hallo Ralf,

vielen Dank für deine Rückmeldung. Dann werde ich mit der Beta weiter arbeiten. Den von mir geannten Punkt hast Du mit in deine Zeitplanung aufgenommen oder soll ich den gesondert erfassen z.B. im Bug-Tracker? Oder gibt es hierfür einen anderen Weg?

Moin, ein Eintrag im Bugtracker wäre mir am liebsten, da kann man das nämlich dann auch besser nachvollziehen.

Erledigt 🙂

Veröffentlicht von: @derzugfaehrt

Ja, ich habe mich auch zu früh gefreut. Der zugferd-exporter hat zwar eine ZF-..pdf Datei erstellt, aber obwohl es laut "verapdf" eine PDF/3A Datei ist, ist der Inhalt nicht vollständig:

Hallo,

vielleicht kann ich hier zu ein wenig Klarheit beitragen 😉

Ich habe mit LibreOffice 7.0 eine X-beliebige z.B. Writer-Datei als PDF exportiert:

Datei -> Exportieren als -> Als PDF exportieren gewählt und hier ist unbedingt zu beachten, dass als PDF/A-2b (nicht PDF/A3b!) ausgewählt wird.
Nach dem Export merkt sich LibreOffice diese Einstellung.

Wenn ich nun mit Fakturama die Rechnung drucke/das PDF erstellen lasse und danach auf den ZUGFeRD-Exporter gehe, wird in das *bereits erstellte PDF-Dokument* die XML-Information eingebettet.

Mir fehlt allerding ein Tool um den eingebetteten XML-Teil mal zu validieren. Und ich bin mir auch nicht sicher, ob das Ganze jetzt auch schon XRechnung konform ist.

Viele Grüße
Ivan

Veröffentlicht von: @rheydenr

Moin, in der PDF-Datei müßte ein XML eingebettet sein, das factur-x.xml heißt. Das ist das neue Format für die XRechnung / ZUGFeRD. Das ist ja neuerdings alles fast dasselbe. Bloß der Dateiname im PDF ist glaube ich anders. Bei XRechnung reicht auch das blanke XML (das geht aber noch nicht separat zu erzeugen). Aber so im großen und ganzen sollte das schon funktionieren.

Hallo,

bei mir ist eine Datei eingebettet, die sich "ZUGFeRD-invoice.xml" nennt?!

Viele Grüße
Ivan

Ja, das ist noch von der aktuellen Version. Das mit factur-x ist aus der Betaversion. Ich muß hier sowieso nochmal Hand anlegen, weil die XRechnung als reine XML-Datei erzeugt werden soll und nicht in ein PDF eingebunden werden muß.

Veröffentlicht von: @sellerho

↑

Moin !

Ich verwende Fakturam 2.1.1 und mach es so:

Schritt 1, Vorbereitung: Zunächst einmal eine pdf-Datei manuell mit Libreoffice erstellen um die Option pdf/A zu setzen. Danach die Einstellungen in Fakturama auf die eigene Umgebung anpassen. Beim Reiter "Office-Integration" sicherstellen, dass auch eine pdf-Datei erteugt werden soll.

Schritt 2, zugferd erstellen: Rechnung erzeugen und drucken. Die pdf/A-Datei enthält ein xml-Dokument. Fertig.

Viele Grüße

Frank

oh man! Schritt 2.. also einfach "machen" wie gewohnt beim Rechnung erzeugen.. aah... und ich hab die ganze Zeit gedacht ich muss eine Rechnung öffnen und dann oben im Menü auf "ZUGFeRD Exporter" klicken!! danke für den dezenten Hinweis 🙂

Habe dazu PDF/A 2 in libreoffice eingestellt und ein PDF erzeugt (und die Einstellungen so in Office gelassen)
... scheint zu klappen, jedenfalls wird nun auch ein XML erstellt. jetzt muss ich nur noch rausfinden wie ich das PDF prüfen kann ob es das xml enthält.. aber wollte trotzdem kurz Danke sagen 😉

Hallo in die Runde, bin neu hier und möchte erst einmal dem Entwickler für die Software danken,auch wenn ich diese bisher nicht genutzt habe. Möchte aber auf Fakturama umstellen, weil eine Cloud-Lösung für mich überhaupt nicht in Frage kommt.

Diesbezüglich hatte ich bereits sehr schlechte Erfahrungen mit einem sehr großen Anbieter gesammelt. Nach dieser Erfahrung arbeite ich nun an einer Eigenentwicklung für die automatische Verbuchung. 

Aktuell bin ich in meinem Projekt mit der Verarbeitung der XML-Dateien beschäftigt. Und hierfür bräuchte ich einige XML-Dateien in unterschiedlichen Formaten UBL, XRechnung, CII und CrossIndustryInvoice.

Falls mir jemand eine solche Datei zu Testzwecken schicken könnte, dann wäre dies sehr hilfreich. An entsprechende Test-Beispiele zu kommen scheint aktuell recht schwierig zu sein. 

-------------------

Gibt es eine Test-Datei erzeugt aus FAKTURAMA, die man mir zur Verfügung stellen könnte? Email an mail at design-company.de.

Falls jemand seine XML-Datei testen lassen möchte, so kann er diese einfach kommentarlos an die Email-Adresse schicken. Ich lasse dann die Datei über den Validator laufen und könnte dann den Report an den Absender zurückschicken.

Gruß

René

Hallo,

ich frage mich, wozu zugferd da sein soll.

Für das Finanzamt dürfte es um ordentliche Rechnungen gehen. Ohne in die ausländerfeindliche Schublade gesteckt zu werden, die arabischen Schriftzeichen können zu verschiedenen lateinischen Schreibweisen führen. So der Attentäter am Berliner Breitscheidplatz Buchstaben getauscht, sonst wären seine Verbrechen in Italien mit ihm verknüpft worden.

Wenn ein Geschäftsmann 2025 eine Rechnung per eMail erhält, wäre es doch spitze, wenn

eine PDF zum Kontrollieren anhängt -> eingebettet

xml zum Einlesen -> Rechnung (Gutschrift), Aussteller, Adresse, UStId..., Beträge, Steuer, Zahlungsbedingung, Artikel....

Eine nicht eingebettete xml wäre schlecht für den Workflow und würden eine Sicherheitslücke öffnen (hat die Fibu eine xml erhalten, die identisch mit der PDF ist).

Veröffentlicht von: @dc_rene

↑

...

Diesbezüglich hatte ich bereits sehr schlechte Erfahrungen mit einem sehr großen Anbieter gesammelt. Nach dieser Erfahrung arbeite ich nun an einer Eigenentwicklung für die automatische Verbuchung. 

Aktuell bin ich in meinem Projekt mit der Verarbeitung der XML-Dateien beschäftigt. Und hierfür bräuchte ich einige XML-Dateien in unterschiedlichen Formaten UBL, XRechnung, CII und CrossIndustryInvoice.

Falls mir jemand eine solche Datei zu Testzwecken schicken könnte, dann wäre dies sehr hilfreich. An entsprechende Test-Beispiele zu kommen scheint aktuell recht schwierig zu sein. 

-------------------

Gibt es eine Test-Datei erzeugt aus FAKTURAMA, die man mir zur Verfügung stellen könnte? Email an mail at design-company.de.

Falls jemand seine XML-Datei testen lassen möchte, so kann er diese einfach kommentarlos an die Email-Adresse schicken. Ich lasse dann die Datei über den Validator laufen und könnte dann den Report an den Absender zurückschicken.

...

Hallo René,

ist Deine Lösung denn als Integration bzw. Erweiterung von Fakturama gedacht? Oder wie kann ich mir das vorstellen? Klingt jedenfalls interessant!

Ich kann Dir evtl. eine paar XML-Dateien generieren bzw. würde die Kundendaten dann jedoch aus dem XML rauslöschen und durch Dummy-Daten ersetzten.

Viele Grüße
Ivan

@blu-IT Hallo Ivan, das System welches ich aktuell bezüglich der automatischen Verbuchung programmmiere, basiert aus der export-Datei des Archivierungsprogramms ecoDMS. Letztendlich wird es aber kein Unterschied machen, woher oder in welcher Form (in ZIP-Datei) die Daten kommen. Dies könnte man individuell anpassen. 

Fakturama würde ich verwenden als Ersatz für ein "altes" Lexware, welches ich seit über 25 Jahren in einer virtuellen Maschine nutze. Mit Fakturama werde ich mich wohl erst Mitte / Ende Dezember beschäftigen können. Theoretisch werden nur PDF-Dateien oder XML-Dateien benötigt, wobei jetzt mit XML bezüglich der OCR natürlich alles vereinfacht wird. Letztendlich werden aber auch zukünftig PDF benötigt werden, denn Kassenbelege / Tankquittungen, etc. gibt es weiterhin. Letztendlich ist der Aufwand nun doppelt so hoch, was die Programmierung angeht. Genauso werden Endverbraucher auch weiterhin PDF erhalten, wenn die Übertragung des Beleges nicht auf dem Postweg erfolgt.  Aktuell läuft das ganze System auf einem Linux-Server.

Intuition des ganzen Projekts war es erst einmal "nur", ein System zu entwickeln, welches möglichst die Buchungen mit KI-Unterstützung durchführt. Und wenn man sich einmal mit dem Thema befasst, merkt man ganz schnell, dass das was da von einem großen Start-Up angeboten wird, welches 2016 über 20 Millionen eingesammelt hat, ein einziger Betrug ist und mich letztendlich innerhalb von einem Jahr der Nutzung, fasst meine Agentur gekostet hat, weil das System nur "Müll" produziert hat.

Daher entwickle ich nun seit fast 2 Jahren ein eigenes System, bei dem ich jetzt die XML-Verarbeitung integriere und bei manchen Feldern ist es dann schwierig eine schnelle Beurteilung zu treffen, wenn einfach "Daten" nicht angegeben sind. Und die Beispieldaten, die man sich herunterladen kann, sind eigentlich für die "Tonne".  Leider konnte ich mich zeitlich noch nicht konkreter mit den PDF und den integrierten XML-Daten befassen. Aktuell arbeite ich an den reinen XML-Dateien, d.h. wenn diese valide sind, werden diese weiter verarbeitet, ansonsten wird eine Email verschickt, dass die Datei nicht valide ist und nicht weiterverarbeitet werden kann, etc. Wenn nur mir einige XML-Rechnungen schicken könntest, vielleicht auch aus Fakturama heraus, dann wäre dies schon hilfreich. 

Was mir gerade zufällig einfällt:

Gibt es in Fakturama eine Export-Funktion für die Rechnungseingänge oder Rechnungsausgänge nach Zeitraum?

Ich habe vor Jahren mit einer FiBu gearbeitet. Datev kompatibel (also dos-lastig ,, oder ** zum Korpieren der vorigen Buchung). Ein dms und papierlos, praktisch alle Lieferanten schrieben beleglose Rechnungen und es gab einen externen Scan-Dienstleister. Ocr und eine Datenbank der Artikelnummern. Mit 2 Bildschirmen konnten 100 Rechnungen pro Stunde gebucht werden, ging ja nur um Kontrolle der Mustererkennung.

Mit .xml sollten die ocr Einlesefehler wegfallen.

@dc_rene eco dms? Will ich seit Jahren mandentenfähig nutzen. Da es nicht vorgesehen ist, denke ich an Docker. Wer dms benutzt, hat auch ein Privatleben, Ehepartner... Also sind getrennte Datenbanken nötig.

DMS = document management system.

Hast Du Wissen in Docker oder vm?

Veröffentlicht von: @york

↑

@dc_rene eco dms? Will ich seit Jahren mandentenfähig nutzen. Da es nicht vorgesehen ist, denke ich an Docker. Wer dms benutzt, hat auch ein Privatleben, Ehepartner... Also sind getrennte Datenbanken nötig.

DMS = document management system.

Hast Du Wissen in Docker oder vm?

Hallo York,

auf einem Synology-NAS habe ich ecoDMS mal installiert. Dafür gibt es ein Anleitung im Inst.-Handbuch von ecoDMS.
Wenn Du mit Docker vertraut bist, kannst Du Dir daraus sicher auch ein Leitfaden für eine Docker-Inst. auf einer anderen Basis ableiten.

Viele Grüße
Ivan