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

Nach erfolgreicher Anlage werden die Belegdokumente angehängt und die Zuordnung zwischen Mail-ID und ERP-Belegnummer gespeichert.

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.