Hallo,
hat sich jemand schon mit dem umgang mit E-Rechnugen gedanken gemacht?
Speziel X-Rechnungen (xml-dateien) sind grade mein Problem.
Diese lassen sich nicht verarbeiten. Zugferd-Rechnugen sind kein Problem da es pdf’s sind.
Hat jemand eine Idee?
Letzteres ist wohl offensichtlich nur für Behörden untereinander wie ich gelesen habe.
Und ne XML lässt sich halt vermutlich leichter manipulieren als n PDF mit Signatur.
Aber funktioniert das nicht über Tika/Gotenberg?
Word und Excel kann man ja auch als XML speichern.
Beides wird ja quasi auch nur „abfotografiert“ und gespeichert.
Hast du das schon probiert ?
Ab 2025 ist im B2B ( Alle mit ein paar ausnahmen) die Empfangsmöglichkeit von E-Rechnugen Plicht, ab xx.2026 auch das versenden .
Das bedeutet das ab 2025 Rechnugen als Zugferd ODER X-Rechnugen kommen können.
Wenn ich probiere eine X-Rechnung (XML-Datei direkt oder per Mail mit Anhang) einzulesen das kommt nicht unterstütztes Format (consume) oder Anhang XML
ignoriert.
Zwar wird die Email Aufgenommen aber der XML- Inhalt ist nicht suchbar
XRechnung wird wohl offensichtlich nur für Öffentliche Rechnungen verwendet z.B. STRABAG an den Bund so wie ich das verstanden habe.
Was man machen könnte wäre ein Pre-Consune Skript ausführen lassen das das xml in ein PDF wandelt.
Und auf jeden Fall ins Git Repository nen Feature Request erstellen für XML Unterstützung.
X-Rechnugen werden leider nicht nur im Öffentlichen bereich kommen, grade größere Firmen ist die am liebsten. Es bleibt jeden freigestellt welches Format er verschickt.
Das mit dem umwandeln hab ich auch schon überlegt zwecks Lesbarkeit es gibt ein paar Repos (in PHP) die das können, es bleibt aber das Problem mit der Archivierung der Original XML-Datei.
Habe bereits einen Request bei Github gemacht. Mal schauen was kommt.
Scheinbar ist die Problematik über das ganze Thema bei vielen noch weit nach hinten geschoben.
Ich hab kein Gewerbe und hab mich deswegen noch nicht damit beschäftigt.
Dann ist für die Buchhaltung ähnlich wie n Überweisung per QR-Code ohne viel Aufwand.
Aber das mit den ersten digital signierten Rechnungen kenne ich noch von vor knapp 10 - 15 Jahren als Europas größter IT-Distributor anfing Signierte Rechnungen zu verschicken als ich mein Gewerbe hatte.
Na die Originalen XML können dann ja Post-Consume verschoben werden …
Zumindest bis das Feature integriert ist.
Hallo @anon58924890,
hättest du vielleicht Zeit und Lust dich zu dem Thema in einem kurzen Gespräch mal auszutauschen? Ich denke das Thema wird in Kürze sehr interessant, da wie @Manni schon geschrieben hat im B2B der Empfang von E-Rechnungen ab 01.01. zur Pflicht wird, und die Belege im Original und unveränderlich gespeichert werden müssen. Wir haben uns hierzu schon ein paar Gedanken gemacht, haben aber nicht ausreichend know-how in paperless, um etwaiges umzusetzen.
Viele Grüße
Prinzipiell ja aber ich habe auch keine Ahnung von Pre/Post Consume Skripte…
Ich weiß nur das es die Möglichkeit gibt.
Letztendlich dürften das einfache Shellscripte sein … da muss man sich halt durchfuchsen.
Wenn es ein anderer Dateityp ist (.xml) muss es ein ‚custom parser‘ sein oder nicht? Erwartet der Weg über Post Consume Skript nicht den selben Dateinamen/-endung nach der Ausführung?
Letztendlich muss die Unterstützung von Paperless kommen bzw über Tika.
Über Post oder Pre Consum wird man keine Lösung finden, da es ja darum geht die Datei nicht zu Verändern.
Momentan testen wir einen Umweg… Die Xml datei kommt per Email, diese dann als eml per Mailparser holen. Paralell dazu die Rechnung Visualisieren ,die PDF consumieren und diese dann mir der EML verknüpfen. Damit ist diese dann auch suchbar und soweit ich es erlesen kann auch revisionssicher.Ist zwar nicht elegant aber zur Not
Gut wenn du ne Lösung hast.
Mein theoretischer Ansatz wäre einfach nur gewesen n PDF daraus zu konvertieren und dann zusammen mit dem Original verschieben.
Wohin verschieben? Das ist ja das Problem! Die Originalen XML -Dateien müssen ja Revisionssicher archiviert werden .Diese nur in ein Verzeichnis zu kopieren reicht nicht. Darum die eml Datei der Mail da sie im Archiv ebenso gespeichert ist (Transaktionslog,… ). Es würde auch gehen aus der XML Rechnung eine Zugferd zu machen PDF + XML ) aber leider würde es im Fall einer Prüfung nicht reichen ( ist ja nicht im Original…).
@anon58924890 hättest du mal 15 min für ein Gespräch um dich auszutauschen? Leider gibt es keine PN Funktion hier (oder?), melde dich gerne bei mir über unsere Webseite
Ich bin da auch nicht so tief in der Materie drin um das Problem zu lösen.
Glaube nicht das ich viel dazu beitragen kann und bin auch kein Programmierer.
Und hab auch weder die Zeit und Lust das zu Lösen… Wenn dann eher nen faulen Workaround wenn es mich selbst betrifft.
Paperless war so ein Neugierde Projekt das sich bei mir integriert hat und ich hab als Privatperson die ganzen Probleme nicht mit Zugfred und co.
Denke also das es mit mir weniger Sinn macht zu quatschen und die Zeit hab ich dafür gerade auch nicht.
Das Forum läuft hier so nebenbei immer als Lückenfüller tagsüber wenn gerade kurz Zeit ist im Außendienst.
Dafür würde ich aber auch kein paperless-ngx nutzen. Als Unternehmer empfehle ich dir ganz dringend, eine der bestehenden, günstigen Lösungen für Buchhaltung zu nutzen, die es auf dem Markt gibt.
Ich z.B. nutze lexoffice für die Buchhaltung und paperless-ngx, um alle wichtigen Dokumente jederzeit zu finden. Außerdem habe ich eine Schnittstelle zwischen paperless-ngx und lexoffice entwickelt, die ich nutze, um auch direkt zu lexoffice scannen zu können und auch E-Mails mit Rechnungen automatisch zu lexoffice zu bekommen.
1 „Gefällt mir“
Mal abgesehen davon, das paperless-ngx in seiner jetzigen Form nicht GoBD konform ist, warum würdest du das nicht empfehlen?
Wir würden gerne in das Projekt investieren um GoBD Konformität, xRechnung und noch ein paar weitere Dinge zu ermöglichen. Hat jemand einen Kontakt zu einem der (Haupt-)Entwickler hinter paperless-ngx?
@anon58924890 ok sorry, ja das macht dann keinen Sinn. Dachte du bist vielleicht Entwickler und hättest Lust auf eine neue Perspektive 
Das mit der GoBD konformität ist ja so eine Sache . Eher eine Auslegungssache bei vielen Punkten.
Die Vorgaben sind allgemein gehalten und lassen sich verschieden auslegen, so lässt sich quasi alles umsetzen. Wichtig ist immer die Verfahrensdokumentation.
Oder übersehe ich was ?
Soweit ich weiß sind einige Punkte schon recht klar in der Auslegung, vor allem was Revisionssicherheit und -protokollierung angeht, oder bspw. dass es „Keine Löschmöglichkeit vor dem Ende der Aufbewahrungsfrist“ geben darf. Oder dass Backups der Daten an einem physisch getrennten Ort gesichert werden müssen (anderes Rechenzentrum). (Quelle)
Insofern würde ich mich @Stefan da grundsätzlich anschließen: für die geschäftliche Archivierung ist paperless-ngx in seiner jetzigen Form nicht ausreichend.
Wir würden das aber gerne ändern