cd187585dd
Rechnungen mit konfigurierten Bündel-Positionen (Signal: 'Menge Komponenten') haben einen völlig anderen Aufbau: Produktname + Dutzende Komponentenzeilen über viele Seiten, Preis als 3-Zeilen-Block mittendrin, Service-Tags erst danach. Der bisherige Parser scheitert daran (falsche Namen, Fehltreffer). Neu in invoice_logic.py: - is_bundle_invoice / extract_bundle_items: eigener Parser, verankert am 3-Zeilen-Preisblock (Menge+Einheit / Einzelpreis / Zeilensumme), segmentiert an den Positions-Headern; entfernt Seitenmöblierung (Kopf RECHNUNG..Betrag €, Bank-/Registerzeilen, Übertrag/Vortrag). Beschreibung (BT-154) = volle Komponentenliste + Service-Tags. - extract_invoice_items: Dispatcher (Bundle vs. Standardparser) - die bekannten Service-Rechnungen bleiben unverändert. - extract_stated_tax_basis: liest die ausgewiesene Bemessungsgrundlage aus der Steuerzeile. main.py: nutzt den Dispatcher; Summen-Abgleich als Sicherheitsnetz - weicht die Summe der erkannten Positionen von der ausgewiesenen Bemessungsgrundlage ab, erscheint eine deutliche Warnung. Verifiziert an R26-252 (9 Seiten): 4 Positionen korrekt, Summe 217.500,55 = Bemessungsgrundlage, Brutto 258.825,65 = Endbetrag, valides XRechnung/ZUGFeRD mit Service-Tags in BT-154. Alle 7 bekannten Rechnungen unverändert. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|---|---|---|
| .dockerignore | ||
| .gitignore | ||
| Dockerfile | ||
| README.md | ||
| docker-compose.yml | ||
| invoice_logic.py | ||
| main.py | ||
| requirements.txt | ||
| sRGB.icc | ||
README.md
README
Description
Dieses Tool konvertiert Rechnungen im PDF-Format über eine Weboberfläche in die offiziellen E-Rechnungsformate XRechnung (UBL 3.0) und ZUGFeRD 2.4 (hybride PDF mit eingebettetem CII-XML). Die Datenextraktion erfolgt über ein LLM, das intern im Firmennetzwerk läuft – sensible Finanzdaten verlassen das lokale Netzwerk nicht.
Zugriff
Die Anwendung läuft als Docker-Container und ist im lokalen Firmennetzwerk erreichbar unter:
Aufbau
Das System besteht aus zwei Komponenten:
- Web-Oberfläche (
main.py, Streamlit): PDF-Upload, Datenvalidierung, Export - vLLM-Backend: separat betriebener Inferenz-Server (Standard:
gemma431b), der die strukturierten Metadaten aus dem Rechnungstext extrahiert
Installation (Docker)
1. Repository holen
git clone https://gitea.scitech-gmbh.de:8443/dfuhrmann/E-Rechnung.git
cd E-Rechnung
2. Umgebungsvariablen prüfen
In docker-compose.yml sind das vLLM-Backend und Modell hinterlegt:
environment:
- VLLM_URL=http://10.192.0.140:8002
- LLM_MODEL=gemma431b
Bei Bedarf hier anpassen (z.B. anderes Modell oder Backend-Host).
3. Container bauen und starten
docker compose up -d --build
Die Anwendung ist danach unter http://localhost:8040 (bzw. im Firmennetz unter http://erechnung) erreichbar.
Use
Der Konversionsprozess gliedert sich in folgende Schritte:
- Dokumenten-Upload: Laden Sie die Rechnungs-PDF über die Weboberfläche hoch. Die PDF wird direkt zur Kontrolle angezeigt.
- Extraktion: Starten Sie die Analyse über den Button "Daten extrahieren".
- Validierung: Prüfen Sie die extrahierten Kopfdaten und die Positionstabelle in der Benutzeroberfläche. Da alle Felder editierbar sind, können Korrekturen direkt vorgenommen werden. Pflichtfelder sind mit :red[*] markiert; der Export wird blockiert, solange Pflichtangaben fehlen.
- Export: Wählen Sie das gewünschte Format (XRechnung-XML oder ZUGFeRD-PDF) und starten Sie den Download.
Notes
Human-in-the-Loop
Das Tool dient als Automations-Assistent. Vor dem finalen Export ist eine visuelle Endkontrolle der extrahierten Daten (insbesondere Rechnungsnummer und Empfängeradresse) durch den Sachbearbeiter zwingend erforderlich, um KI-Fehlinterpretationen auszuschließen.
GoBD-Konformität
Das Tool generiert ausschließlich das strukturierte XML- bzw. hybride PDF-Format. Für die Einhaltung der GoBD-Richtlinien (u. a. die revisionssichere Archivierung der Original-PDF sowie der generierten E-Rechnung über den gesetzlichen Zeitraum von 10 Jahren) ist der Betreiber der Software selbst verantwortlich.