Zielgruppe & Rolle

Rolle: Technik / Entwickler & Support | Schritt: 5 von 5 der Verarbeitungspipeline

Audit und ERP-Anlage

In diesem Schritt werden die Ergebnisse aus der Belegprüfung in eine konkrete ERP-Anlage überführt. Das umfasst Vorprüfungen, Audit-Entscheidung und die technische Übergabe nach microtech.

Ziel des Schritts

Aus einem geprüften Beleg wird ein sauber angelegter ERP-Beleg – direkt oder mit Sperrkennzeichen für die Nachbearbeitung.

ERP-nahe Vorprüfungen

Vor dem Schreiben in microtech werden die zentralen Felder geprüft und als Marker vorbereitet.

Prüffeld	Prüfung	Auswirkung
Projektnummer	Abgleich gegen aktive und archivierte Projekte	Ungültige Werte werden als Risiko markiert
Lieferant	Prüfung der VendorNo im ERP	Bei Bedarf Fallback-Kreditor
Dublettenhinweis	Suche über Belegnummer + Kreditor + Belegart	Markierung für Audit oder manuelle Prüfung
Positionen	Kontrolle auf fehlende Artikelnummern	Marker für Sperrentscheidung
Validierung	Status aus E-Rechnungs-/UStG-Prüfung	Marker für Sperrkennzeichen

Diese Marker fließen in die Anlagefelder (z. B. Sperrkennzeichen) ein.

Audit bei Diskrepanzen

Wenn Abweichungen vorliegen, bewertet der AuditService die Plausibilität und liefert ein strukturiertes Ergebnis.

Audit-Ergebnis

• Approved: direkte ERP-Anlage.
• Manual Review: ERP-Anlage mit Sperrkennzeichen (fldGspKz: true).

Zusätzlich kann unabhängig vom Audit eine Sperre gesetzt werden, z. B. bei Fallback-Kreditor, fehlendem Positions-Matching oder ungültiger Validierung.

ERP-Anlage und Verknüpfung

Beim Schreiben des Belegs in microtech werden alle auf der Rechnung vorhandenen Bestellreferenzen (BT-13, BT-132) und Lieferscheinreferenzen (BT-16) dedupliziert in das Selektionsfeld fldSel30310 übernommen. Nach erfolgreicher Anlage werden die Belegdokumente angehängt und die Zuordnung zwischen Mail-ID und ERP-Belegnummer gespeichert. Dies bildet die Grundlage für den nachgelagerten automatisierten Belegvergleich (InvoiceCompareService).

Automatisierter Belegvergleich (InvoiceCompareService)

Direkt im Anschluss an die erfolgreiche ERP-Anlage führt invoice-go den automatisierten Belegvergleich durch:

1. Prüfungsanstoß: Sind im Feld fldSel30310 Belegnummern hinterlegt, startet performRuleBasedComparison.
2. 4-Stufen-Vergleich:
   • Prüfung 1 (Quellen): Löst alle Referenzen in tblTransactions und tblTransactionsArchive auf, bewertet den Lieferstatus anhand des Entscheidungsbaums (GELIEFERT, OFFEN, STORNIERT) und prüft auf nicht gefundene Belege (MISSING_ORDER).
   • Prüfung 2 (Kopfdaten): Gleicht Kreditor-Adressnummer (fldAdrNr), Belegwährung (fldWaehr), IBAN und Gesamtbruttobetrag ab.
   • Prüfung 3 (Anlageprüfungen): Prüft auf ignorierte Artikel, Fallback-Kreditor, fehlende Artikelnummern, Schematron-Validierung, strikte UStG-Anforderungen und Beleg-Duplikate.
   • Prüfung 4 (Positionsvergleich): Führt einen detaillierten Mengen-, Preis-, Rabatt-, Zuschlags-, Einheiten- (via UnitService) und Kontierungsabgleich je Artikelposition durch.
3. Offene Posten: Ermittelt offene Restmengen (OpenPositions) aus aktiven Bestellungen.
4. Sperr- und Reportsteuerung:
   • Bei Abweichungen oder fehlenden Bezugsbelegen wird der Beleg im ERP gesperrt (fldGspKz: true) und der vollständige strukturierte Prüfbericht in fldGspInfo geschrieben.
   • Über den Endpoint POST /api/invoice/v1/compare (z. B. aus microtech heraus) kann der Beleg nach manueller Korrektur erneut geprüft werden. Sind alle Prüfungen fehlerfrei, wird die Sperre im ERP automatisch aufgehoben (fldGspKz: false).

Technische Nachläufe

Dieser Abschnitt beschreibt technische Fehlerfälle bei der ERP-Anlage und deren Nachbehandlung.

Prozess	Verhalten
Retry-Zähler	Bei Fehlern während der ERP-Anlage wird pro Fall ein Counter geführt; nach 5 Fehlversuchen endet der Fall in DeadLetter.
Mail-Benachrichtigung	Der mail-go Service pollt auf DeadLetter Fälle, aktualisiert die Outlook-Mail mit einem Rejection-Hint (Grund aus S3 Metadaten) und verschiebt diese in den Rejected-Ordner.
Bereinigung	Erfolgreich benachrichtigte Fälle werden in S3 nach RejectedFinal überführt.

Der Recovery-Lauf bleibt idempotent und führt inkonsistente Marker kontrolliert in den vorgesehenen Fehlerpfad.

---

Nächster technischer Schritt

Detaillierte Übersicht über alle möglichen Sperrursachen und deren Behebung: Sperrgründe & Locks