This post was flagged by the community and is temporarily hidden.
Na ja, der Link führt erst einmal zu einer Version, die auf einen Windows-Rechner herunter geladen wird und wohl als Drucker in LibreOffice mit eingebunden wird. Es geht also nicht um den Upload und Download, der für Firmen sowieso indiskutabel sein sollte.
In der FAQ der Seite ist dann zu erfahren, dass das Ganze ca. 93,76 € ohne Validator kostet und darüber hinaus für einen Invoice Instractor monatlich 3,90 € anfällt.
Die kostenlose Lösung für LibreOffice gibt es allerdings hier: https://wiki.documentfoundation.org/images/d/d5/XRechnung_Extension_2502.zip
Und die kann neben der Erstellung von XRechnungen, erweiterten XRechnungen und ZUGFeRD-Rechnungen auch das Einlesen von Rechnungen, die archivierte Ablage von Rechnungen usw. Inzwischen auch als Serverversion zusammen mit der MariaDB/MySQL und mit der Möglichkeit, englischsprachige Rechnungen automatisch für Länder zu erstellen, die nicht DE, AU oder CH sind.
This post was flagged by the community and is temporarily hidden.
-
Grundkenntnisse im xml-Bereich sind bei der XRechnung-Erweiterung nirgendwo gefragt.
-
Die interne Firebird-Datenbank ist zur Zeit bei den meisten Leuten die erste Wahl. Die Servervariante wird in größeren Firmen nachgefragt.
-
Natürlich erzeugt die XRechnung-Erweiterung im Writer eine ansehnliche Rechnung. Sie wird mit den Daten gefüttert, die zu der Rechnung gehören und lädt das dann in eine entsprechende Vorlagendatei.
-
Die Einbindung von Dateien in PDF-Dateien nach dem Standard, der für ZUGFeRD erforderlich ist, gelingt leider mit LibreOffice nicht direkt. Auch andere Tools schaffen das nicht (wie tkpdf - da wird zwar eingebunden aber die interne Datei kann nicht in Quba angezeigt werden)
Wenn ich das bei der 7-PDF-Version richtig verstanden habe arbeitet die mit KI. Du verlässt Dich dann darauf, dass das, was in Deiner eigentlichen Rechnung steht, auch in der erstellten xml-Datei steht. Dass die Datei gültig ist bedeutet ja nicht, dass die Daten denen entsprechen, die Du in Deiner Rechnung hast. Ich würde tunlichst den Inhalt mittel Quba Viewer überprüfen. Da hast Du bei einer korrekten ZUGFeRD-Datei die PDF-Datei auf der einen Seite, die ausgelesenen Inhalte der xml-Rechnung auf der anderen Seite.
Ich erinnere nur an die Stadt im Münsterland, die für 2 Feuerwehrwagen nach einer xml-Rechnung bezahlt hat - nur war in der xml-Rechnung die IBAN ausgetauscht worden: Stadt Dülmen überweist 400.000 Euro an Betrüger - Nachrichten - WDR
Danke für die Ergänzungen, Robert – super wichtig und berechtigt!
Zur XRechnung-Erweiterung: Ich hatte mich vor allem auf die MariaDB-Variante bezogen, weil die im Thread vorher genannt wurde. Dass Firebird mittlerweile Standard ist und keine XML-Kenntnisse nötig sind, ist natürlich ein klarer Pluspunkt – danke für die Korrektur! 
Zur 7-PDF-Lösung mit KI:
Ich verlasse mich dabei nicht blind auf die erzeugte XML-Datei. Genau deshalb habe ich die generierten Rechnungen mit dem:
- Quba Viewer
- ZUGFeRD Viewer
- und dem offiziellen KoSIT Validator
nochmal manuell geprüft.
Mein Testergebnis:
- Alle Inhalte wurden korrekt übernommen:
- Beträge, Rabatte, Zuschläge
- USt, Reverse-Charge (IGL), steuerfreie Leistungen
- IBAN & BIC
- sogar eine englischsprachige Rechnung wurde korrekt verarbeitet
- Die XML war visuell deckungsgleich mit dem PDF-Inhalt
- Validierung erfolgreich nach EN 16931 / ZUGFeRD 2.1
Ich stimme dir aber völlig zu:
Gültigkeit heißt noch lange nicht, dass die Inhalte korrekt sind.
Ein Validator prüft das XML-Schema, aber nicht, ob jemand z. B. die IBAN ausgetauscht hat – siehe dein Beispiel aus Dülmen.
Gerade bei größeren Beträgen oder automatisierter Verarbeitung sollte man den XML-Inhalt unbedingt visuell gegenprüfen – egal ob per Hand erstellt, mit Makros gebaut oder per KI generiert.
Der Validator von 7-PDF selbst (hab die Trial ausprobiert) kann übrigens auch:
- Schema-Validierung
- PDF/A-3 Konformität prüfen
- GUI und CLI nutzen
Fazit (für mich persönlich):
Für kleinere Firmen oder Solo-Selbstständige, die 1–2 E-Rechnungen im Monat schreiben, war das ein sehr angenehmer Workflow:
LibreOffice-Rechnung → Drucken → XML wird eingebettet → Validieren → Fertig
Roberts Lösung:
- Datenbankdokument und Formular öffnen.
- Rechnung eintragen.
- Schaltfläche klicken.
Ergebnis ist 1 odt, 1 pdf, 1 xml
Die Rechnungsdaten (was, wann, wie, an wen, zu welchen Konditionen) sind in der Datenbank gespeichert. Rechnungsnummern werden autom. erzeugt. Aus den Daten kann jede Rechnung zu jeder Zeit neu erzeugt werden.
Du müsstest wohl noch eine Vorlage für Dein persönliches “Rechnungspapier” (den PDF-Ausdruck) vorbeireiten.
Danke für die Ergänzung, Villeroy – ich finde es gut, dass ihr da eine richtig durchdachte Datenbanklösung aufgebaut habt.
Die Idee, alle Rechnungsdaten strukturiert zu speichern und auf Knopfdruck wiederherstellen zu können, ist natürlich stark – für ein Unternehmen mit festen Strukturen sicher super sinnvoll.
Aber (wirklich nicht wertend gemeint):
Nicht jeder arbeitet so organisiert – oder will das.
Manche schreiben 1–2 Rechnungen im Monat, gestalten die in Writer oder Calc und möchten sie einfach direkt als ZUGFeRD konform drucken – ohne Datenbank, Masken, Formularlogik oder Seriennummernverwaltung.
Für solche Fälle – also eher „visuelles Schreiben + rechtssicher drucken“ – war die getestete Lösung überraschend pragmatisch.
Thema Archivierung und GoBD
Was man (ganz unabhängig von der Lösung) nie vergessen darf:
GoBD-Konformität heißt auch: Archivierung in unveränderbarer Form
Auch bei einer Datenbanklösung gilt: Wenn Rechnungen jederzeit neu erzeugbar und änderbar sind, muss zusätzlich sichergestellt werden, dass das Original (z. B. PDF/A-3 mit eingebetteter XML)
- revisionssicher archiviert,
- unveränderbar abgelegt
- und für die Dauer der Aufbewahrungspflicht auffindbar ist.
Die getestete Drucklösung erzeugt ein PDF/A-3 mit eingebetteter XML, das direkt:
- lokal validiert werden kann (via Quba, KoSIT, ZUGFeRD Viewer etc.)
- und an ein DMS oder Archivsystem übergeben werden kann
Und falls’s größer wird…
Was ich richtig spannend fand:
Die Lösung ist voll automatisierbar, auch via Kommandozeile
D. h. sobald man mehr Volumen hat, kann man auch:
- PDF + XML im Hintergrund erzeugen lassen
- per Skript oder Printjob direkt ans Archivsystem übergeben
- auf Wunsch ohne GUI, ohne Zutun
Und gerade die Anbindung via PDF-Drucker ist da oft ein Vorteil – weil viele Archiv- oder ERP-Systeme genau auf diesen Workflow setzen (Drucken → Archivieren).
KI? Ja – aber mit Sicherheitsnetz!
Ein häufiger Einwand lautet:
„Wenn da KI mitmischt – kann die nicht falsche Daten in die XML schreiben?“
Ja, kann sie – theoretisch.
Aber die getestete Lösung bringt gleich mehrere Sicherungsmechanismen mit:
-
Visuelle Kontrolle
Die erzeugte PDF/A-3 mit eingebetteter XML lässt sich mit dem Quba Viewer, KoSIT-Validator oder dem ZUGFeRD Viewer öffnen und vergleichen
→ Man sieht sofort, ob Beträge, IBANs, Texte und Positionen korrekt übertragen wurden. -
Automatische Validierung
Ein eigener 7-PDF E-Invoice Validator (auch CLI-fähig) prüft das Ergebnis:- ZUGFeRD- oder XRechnung-konform?
- PDF/A-3 konform?
- Optionaler Teil automatisierter Verarbeitungspipeline
-
Integrierte Plausibilitätsprüfung
Der KI-Service selbst prüft:- Stimmen Summen, Steuerbeträge, Positionswerte?
- Sind Einheiten, Währungen und Gesamtsummen stimmig?
➤ Wenn die Rechnung rechnerisch nicht plausibel ist, wird keine XML erzeugt.
Ich finde es ehrlich super, dass es beide Wege gibt – denn am Ende zählt doch:
Rechnung normkonform → Kunde kann verarbeiten → prüfungssicher archiviert → fertig.
Das ist zu 100% Roberts Verdienst, und man kann es auch gleich richtig machen, anstatt das über eine Online-Verbindung eine KI erledigen zu lassen. Das Datenbankformular funktioniert mit einer Rechnung pro Jahr oder tausend Rechnungen am Tag.
Danke dir für die Ergänzung, Villeroy!
Dass das Datenbankformular skaliert – von 1 bis 1.000 Rechnungen – absolut unbestritten.
Und es ist klasse, dass durch Roberts Arbeit da ein richtig solides Werkzeug entstanden ist!
Was ich aber eben auch gut finde:
Dass es eben nicht den einen „richtigen“ Weg gibt – sondern verschiedene Ansätze, je nach Zielgruppe und Bedarf.
Ich persönlich hatte einfach einen anderen Einstiegspunkt:
-
Ich gestalte meine Rechnungen bewusst im Writer/Calc – so wie sie beim Empfänger aussehen sollen -
Und ich wollte eine Lösung, die meinen vorhandenen Workflow ergänzt, nicht ersetzt -
Dabei war mir Datenschutz und lokale Validierung genauso wichtig wie Prüfbarkeit und Archivierung
Und ja, die getestete Lösung arbeitet mit KI – aber nicht ohne Sicherheitsnetz:
-
Visuelle Kontrolle: Quba Viewer, ZUGFeRD Viewer, KoSIT Validator
-
Schema- und PDF/A-Validierung (lokal & automatisiert via CLI möglich)
-
Plausibilitätsprüfung durch den Dienst selbst – inkl. Rechenprüfung
-
Keine XML-Ausgabe, wenn Daten widersprüchlich oder unstimmig sind
Und: Die Lösung erzeugt sofort ein PDF/A-3 mit eingebetteter XML, das archiviert und weiterverarbeitet werden kann – inkl. direkter Übergabe ans DMS oder Archivsystem (z. B. via Printjob).
Fazit aus meiner Sicht:
Wer lieber „gestaltet & druckt“ statt „formuliert & speichert“, findet hier einen gut abgesicherten, einfachen Einstieg.
Und das Schöne ist: Man kann ja beide Ansätze ausprobieren – und selbst entscheiden, was besser zum Alltag passt. 
Viele Grüße!
Organisiert arbeiten sollte sich jeder angewöhnen. Spätestens, wenn das Steuerbüro Rechnungen anfordert, die “irgendwo” verschusselt wurden merkst Du das. (Ich schicke regelmäßig Archivkopien unserer Rechnungen an Kunden, wenn bei denen plötzlich Belege fehlen…
.
Problematisch an Deiner Argumentation ist zweierlei: Einmal ist es egal, was Du oder ich wollen. Die Entscheidungen wurden vom Gesetzgeber getroffen. Der andere Teil ist: Der xml-Teil ist die Rechnung! Dein pdf/die Zugferd-Verpackung ist eine optionale dekorative Verpackung. Ich mag das Format zwar, aber die eigentliche Rechnung per KI zu generieren ist mir zu unsicher. Ich habe letzte Woche nach simplen Öffnungszeiten im Urlaub gesucht und 10-20 Uhr gefunden (Webseite und google, beides schnell sichtbar.) Die “Zusammenfassung mit KI” gab bis 19 Uhr an…
.
Ich mache also doppelte Arbeit: Erst schreiben, dann kontrollieren. Klingt tatsächlich nach “Digitslisierung made in Germany” (Ich kam kürzlich beim elektronischen HBA an die schöne Stelle, wo - nach elektronische Authentifizierung mit dem Personalausweis - unter dem Slogan “digitslisierung einfach machen” die Anfrage kam, den Antrag auszudrucken und auch eine Fotokopie des Personalausweises beizulegen.)
.
Also wird nur geprüft, ob der Empfänger das Ergebnis lesen können sollte, nicht ob die Daten korrekt übernommen wurden.
.
Schon etwas besser. Mir wäre es lieber, wenn die KI sich nicht selbst prüft. Letztendlich verlässt Du Dich auf den Hersteller oder/und kontrollierst selbst.
.
Es wird meist nicht “etwas”, sondern Namen und Adressen Deiner Kunden hochgeladen. Datenschutzkonform ist das allenfalls, wenn Du Deine Kunden darauf hinweist (und evtl. auch auf die KI-Nutzung). Da taucht meist die schöne Frage nach “Auftragsdatenverarbeitung” auf.
??? Und wohin lädst Du die Daten hoch? Wo läuft die KI? Gibt es da eine “niedrige Datenverarbeitungszone unterhalb der Cloud”?
Meiner Ansicht nach redest Du Dir etwas schön, was fur Dich einfach ist.
.
Um nicht nur Deinen Hinweis zu zerpflücken:
Es gab schon länger eine Erweiterung von Thorsten Behrens (ursprünglich fur die französische Variante von XRechnung), die Rechnungen aus einer Calc-Tabelle schreibt. Das wäre mein Ansatz, für ein “kleine” Lösung. Ich verlinke auch mal einen alten Thread aus der “Anfangszeit”, der diverse Links enthalt
1 Like
E-Rechnung einfach erzeugen – darf’s auch mal pragmatisch sein?
Danke für deinen ausführlichen Beitrag, Wanderer – du sprichst wichtige Punkte an!
Einige deiner Anmerkungen verdienen auf jeden Fall eine Einordnung:
“Organisiert sollte man arbeiten” – absolut! Aber…
Niemand will hier Unordnung schönreden.
Aber: Nicht jeder hat eine komplexe Infrastruktur, schreibt tausende Rechnungen im Jahr oder arbeitet mit ERP und DMS.
Für viele ist schon das Wort Formular oder Datenbank abschreckend – die wollen sowas nicht nutzen.
Denn meist sind das die Leute, die:
- nur eine Handvoll Rechnungen im Monat schreiben,
- eine visuelle Kontrolle ihrer Rechnungen (WYSIWYG) schätzen,
- und froh sind, wenn sie eine valide E-Rechnung ohne großes Setup erzeugen können.
Was ist daran auszusetzen? Zumal bei diesem Volumen kaum Unordnung entstehen kann.
Die getestete Lösung bietet hier einen pragmatischen Mittelweg – zwischen rechtlich sauber und technisch zugänglich.
“Die XML ist die Rechnung!” – korrekt. Deshalb prüfe ich sie auch.
Und genau deshalb bringt die Lösung gleich mehrere Sicherheitsmechanismen mit:
-
Visuelle Kontrolle: Die erzeugte PDF/A-3 mit eingebetteter XML kann z. B. im Quba Viewer geöffnet werden – man sieht sofort, ob IBANs, Beträge, Texte, USt-Sätze korrekt übernommen wurden.
Bei wenigen Rechnungen pro Monat: absolut machbar! -
Automatische Validierung: Der integrierte 7-PDF E-Invoice Validator (auch per CLI) prüft:
- ob die XML nach EN 16931 gültig ist,
- ob das PDF PDF/A-3 konform ist.
-
Plausibilitätsprüfung: Die integrierte KI von 7-PDF prüft:
- auf Zahlendreher, fehlerhafte Rechensummen, fehlende Pflichtangaben
- und fängt fehlerhafte XML-Erzeugung ab, bevor die Datei überhaupt gespeichert wird.
Diese Kombination ermöglicht echte Qualitätssicherung ohne Formular- oder Datenbankpflicht.
Die Lösung unterstützt aktiv – so wie ein Formularsystem eben auch.
“Erst schreiben, dann kontrollieren?” – Das ist keine Schwäche, das ist Qualitätssicherung
Die Aussage, dass man bei dieser Lösung „doppelt“ arbeiten müsse, verkennt den Unterschied zwischen Wegwerfen und Verifizieren.
Niemand käme auf die Idee zu sagen:
„Ich hab das Dach gedeckt – warum soll ich nochmal kontrollieren, ob es regnet?“
Gerade bei einer rechtlich relevanten E-Rechnung ist die Kombination aus visueller Kontrolle und technischer Prüfung keine Bürokratie – sondern gelebte Verantwortung.
Und das Beste: Die Kontrolle geht blitzschnell!
- Ein Blick in den Viewer zeigt, ob IBAN, Summen, Steuersätze stimmen.
- Ein Klick im Validator bestätigt: Norm erfüllt
Das ist kein „digitales Bürokratiemonster“, sondern ein Werkzeugkasten für Verantwortung.
Fazit: Wer mehr will, darf mehr machen – wer weniger braucht, bekommt trotzdem Qualität
Dein Ansatz über die Datenbank: top für strukturierte Unternehmen mit IT-Ressourcen.
Aber für kleine Teams, Einzelunternehmer oder Freelancer bei gelegentlichem Bedarf ist ein grafisch orientierter, sofort nutzbarer und validierter Workflow eine extrem wertvolle Alternative.
Nicht besser, nicht schlechter – anders passend für den jeweiligen Nutzerkreis.
Ganz offen?
Langsam beschleicht mich das Gefühl:
Offenbar sind hier andere Meinungen nicht gefragt?!
Oder um es ganz deutsch zu sagen:
Willkommen beim „digitalen Fortschritt“, made in „aber so geht das doch nicht!“
Natürlich darfst du deine Meinung äussern, genauso wie übrigens u.a. auch @Wanderer die Schwachstellen deiner Argumentation kritisch hinterfragen darf!
Und nein »digitaler Fortschritt« bedeutet nicht per se »auf jedes Problem eine KI draufwerfen«
Danke für deinen Hinweis, Karolus – den nehme ich mir gern zu Herzen.
Und keine Sorge: Kritik ist nicht nur erlaubt, sondern ausdrücklich erwünscht.
Unterschiedliche Meinungen? Gerne! Aber bitte ohne Doppelmoral.
Ich habe kein Problem damit, wenn meine Argumente kritisch hinterfragt werden – im Gegenteil.
Nur sollte das bitte auch in beide Richtungen gelten.
Denn was ich beobachtet habe:
- Wer für eine pragmatische Lösung argumentiert, wird schnell als “unorganisiert”, “verwirrend” oder “nicht nachhaltig” abgestempelt.
- Wer bewusst keine KI nutzt, gilt als “altbacken”.
- Wer eine KI nutzt, “wirft einfach irgendwas drauf”.
- Wer nicht gleich eine Datenbanklösung aufsetzt, „nimmt es wohl nicht ernst“.
Das ist kein Austausch mehr – das ist ein Belehrungs-Wettrennen.
Und diese Haltung ist es, die vielen Nutzern das Thema E-Rechnung unnötig verleidet.
Digitalisierung = Vielfalt von Lösungen, nicht Einheitsmeinung
Digitaler Fortschritt bedeutet für mich:
Wählen zu können, was zur eigenen Situation passt – nicht, sich erklären zu müssen, warum man diese eine Lösung nicht nutzt. Ob OpenSource oder kommerziell…
Ob nun Formularlösung, Datenbank, KI oder PDF-Viewer mit Validierung:
Entscheidend ist doch, dass die Rechnung am Ende gültig und nachvollziehbar ist.
Wenn jemand dafür eine geprüfte, lokal lauffähige und verständlich aufgebaute Lösung verwendet –
warum sollte das weniger Wert sein als eine komplexe XML-only-Integration mit ERP-Anbindung?
In diesem Sinne: Vielfalt zulassen, nicht diskreditieren
Ich bleibe gern im Diskurs – aber bitte auf Augenhöhe.
Nicht besser. Nicht schlechter.
Anders passend. Und das darf man sagen, ohne belehrt zu werden.
Diskurs sehe ich bei Dir nicht. Eher ein Muster “Berechtigter Einwand/ Wichtig / Schön” + Wiederholung dessen, was Du schon gesagt hast.
.
Neben meinen Vorbehalten zur KI-Nutzung finde ich das Verfahren einfach zu aufwendig. Ich sitze bei Schreiben der Rechnung an der Quelle, also muss ich Rechnungsnummern und Preise nicht erst (virtuell) drucken, dann wieder (virtuell) scannen um die Ergebnisse dann irgendwie zu validieren.
Das kann Calc beides direkt erzeugen. Writer wurde ich nicht empfehlen, aber mit Deinem Motto “Nicht besser. Nicht schlechter.” wunsche ich einfach viel Spass damit.
.
Ich kann Dein Argument natürlich verstehen
und wenn man dann auch nicht belehrt werden will, dann muss man bei dem bleiben, was man kennt/ zu kennen glaubt.
PS:
Die “Lösung” kommt wahrscheinlich sogar ohne LibreOffice aus: Leg einfach eine mit Schreibmaschinen geschriebene Rechnung
auf einen Scanner und verfüttere das PDF an die KI.
1 Like
Du hast es nicht verstanden. Du kannst natürlich alles hinter einem Knopf verstecken und sagen “Einfach den Knopf drücken”.
Ich argumentiere hier als Programmierer (mal ganz vereinfacht):
r= 12345
p= makepdf(r)
x= makexml(r)
savexrechnung(p, x)
benötigt technisch viel weniger Resourcen als
r= 12345
save(makepdf(r)) as p
i=inputpdf from p
s=searchRinpdf(i)
r= extractRfrompdf(s)
x= makexml(r)
savexrechnung(p, x)
Du kannst Dir auch vorstellen Deine ausgedruckte Rechnung per Post zu verschicken und die Post zu beauftragen den Brief zu öffnen, zu scannen und Dir dann als xrechnung zurückzuschicken (natürlich als email). Geht auch ganz einfach, verbraucht aber eine Menge Resourcen und macht Datenschutzprobleme.
Danke für deinen Beitrag, Wanderer – aber ich sehe das klar anders.
“Du kannst Dir das ja vorstellen…” – klar. Aber das Bild hinkt
Dein Vergleich mit „Rechnung ausdrucken, zur Post tragen, scannen lassen, zurück per E-Mail bekommen“ ist nicht nur überspitzt – er trifft die Realität schlicht nicht:
-
Es wird nichts ausgedruckt oder gescannt.
- Der PDF-Druck ist ein rein virtueller Vorgang – in Sekunden erledigt.
- Die XML wird automatisch eingebettet, keine manuelle Aktion nötig.
- Datenschutzprobleme? Nicht vorhanden. Alles läuft lokal oder auf deutschem Server – nach Zustimmung, temporär und mit automatischer Löschung.
-
Dein Ressourcenvergleich blendet Entscheidendes aus:
x = makexml(r)
Klingt simpel – aber woher kommtr?
Auch in deiner Variante müssen Rechnungsnummer, Positionen, Beträge etc. zuerst erfasst werden.Und genau hier trennt sich die Praxis:
- Bei einer grafischen Lösung: Einmal in Word/Excel getippt → fertig.
- Bei deiner Lösung: Datenmodell bauen, Formulare definieren, Feldlogik pflegen, ggf. LibreOffice Base verstehen – das ist Aufwand.
Was für dich als Entwickler „schlanker“ wirkt, ist für viele ein Overhead, den sie weder wollen noch brauchen – und auch nicht müssen.
Aufwand ≠ Rechenzeit
Du denkst in „Programmierlogik“. Aber:
- Nicht jeder ist Programmierer.
- Nicht jeder will es sein.
Für viele ist „ein PDF drucken“ ein vertrauter und bewährter Workflow.
Und das hat nichts mit Rückständigkeit zu tun – sondern mit Zugänglichkeit.
Vielleicht existiert beim einen oder anderen Unternehmer längst ein Altsystem oder eine WaWi-Lösung,
die keine E-Rechnungen mehr erzeugen kann – aber noch drucken kann.
Und vielleicht ist der zuständige „Programmierer“ inzwischen längst in Rente.
Der demografische Wandel lässt grüßen…
Gerade dann ist eine Lösung wie 7-PDF keine Notlösung – sondern ein digitales Brückensystem, das vorhandene Prozesse nicht ersetzt, sondern erweitert.
Technisch übrigens kein bisschen limitiert
Die Lösung von 7-PDF ist nicht nur „Print & Click“:
- Sie kann per CLI, Automatisierungsskript oder via FastAPI hochperformant angebunden werden.
- Sie lässt sich aus Shoplösungen (PHP, JS) genauso steuern wie aus Desktopumgebungen.
- Sie verarbeitet sogar Papierrechnungen via OCR (Tesseract) und erzeugt aus dem Scan valide ZUGFeRD-XML
Und das alles funktioniert mehrfach (durch mich und vielen anderen) erprobt, voll funktionsfähig wenn die Rechnungsstruktur stimmt.
Fazit: Es geht nicht um „besser“ – sondern um “passend”!!
Wir beide müssen niemanden überzeugen.
Es geht nicht darum, wer schöner abstrahiert oder flüssiger Code schreibt.
Es geht um Lösungen, die im Alltag funktionieren.
Und der eine Ansatz ist besser für Entwickler – der andere für Menschen, die einfach schnell und rechtskonform E-Rechnungen brauchen.
Deine Lösung mag für dich effizient sein –
meine ist für viele effizienter zugänglich.
Der Unterschied ist nicht in der Wahrheit – sondern im Zweck
Dass ich die ganze Zeit NICHT vin einer Datenbanklösung rede hast Du immer noch nicht begriffen??
Wird vorher einmal eingegeben (wie bei Dir), kann dann aber innerhalb einer Datei mehrfach direkt verwendet werden - im Gegensatz zu “Ausdrucken und via KI wieder erkennen”.
(Als Programmierer kann man das noch effektiver machen, aber ich habe hier bewusst keinen Code geschrieben.)
lokal = mein Rechner, also ohne 7-irgendwas-KI
Und vergessen wir den Datenschutz: Du willst nicht belehrt werden und ich halte Deine Einstellung für naiv. Passt aber zur allgemeinen Lage an Datenlecks in der letzten Zeit. Also nur weiter so…
Danke für dein Feedback, Wanderer.
Ich habe den Eindruck, wir drehen uns im Kreis – und das ist schade, denn der eigentliche Sinn eines Austauschs sollte doch ein Dialog auf Augenhöhe sein.
Zur Klarstellung, weil es offenbar immer noch Missverständnisse gibt:
- Ich habe nie von einer Datenbanklösung gesprochen.
- Die von mir beschriebene Lösung soll bewusst eine pragmatische Alternative zu datenbankgestützten oder ERP-nahen Ansätzen aufzeigen – für diejenigen, die genau das nicht möchten oder benötigen.
- Und ja, auch Papierrechnungen lassen sich vollständig verarbeiten – inklusive OCR.
Das ist keine Spielerei, sondern praktische Alltagstauglichkeit, z. B. für hybride oder ältere Rechnungsprozesse.
Alles Weitere ist mehrfach erläutert.
Wer sich informieren möchte, findet alle Informationen offen zugänglich.
Ich steige an dieser Stelle aus dem Gespräch aus – nicht, weil mir Argumente fehlen,
sondern weil ich keine Lust habe, als „naiv“, „nicht begriffen“ oder in belehrendem Ton adressiert zu werden.
Das ist kein respektvoller Umgang – und für mich keine Basis für eine faire Diskussion.
Allen eine gute weitere Diskussion.