bacf1798f9
Die Lieferadresse (BG-15) wird jetzt erfasst und exportiert - aber nur, wenn sie von der Rechnungsadresse ABWEICHT (sonst wäre sie reine Dopplung; die Rechnungsadresse ist meist auch der Lieferort). - extract_delivery_address: parst den 'Lieferadresse:'-Block (Name/Straße/PLZ/Ort), E-Mail-Zeilen ignoriert. Block-Zerlegung mit extract_recipient_address geteilt. - delivery_address_differs: umbruch-/schreibweisenrobuster Vergleich (Str.=Straße, ß=ss) - so gilt z.B. ein mehrzeilig umbrochener Straßenname nicht fälschlich als Abweichung. - Header-Extraktor: delivery_* nur vorbelegt, wenn abweichend; sonst leer. - Generatoren: UBL cac:Delivery/DeliveryLocation/Address + DeliveryParty (BT-70/ 75/77/78/80), CII ShipToTradeParty (vor dem Lieferdatum). Nur wenn Name+Ort gesetzt sind. - UI: eingeklappter Bereich 'Abweichende Lieferadresse (BG-15)' im Reiter Adressen - klappt automatisch auf und ist vorbefüllt, wenn eine Abweichung erkannt wurde; sonst unsichtbar. Editierbar/leerbar. Verifiziert: Stadtwerke (Neuendorfstr. abweichend) und Gemeinde (EDV) -> BG-15; BIM/degewo/ZenIT (gleiche Adresse) -> keine BG-15. ZUGFeRD-PDF mit check_xsd=True (ShipToTradeParty-Reihenfolge korrekt). Alle 7 Beispielrechnungen 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.