In diesem Abschnitt wird erläutert, wie die Validierung eingehender Kreditorenrechnungen konfiguriert wird.

Warum Prüfung

Um Kreditor-Rechnungen einzureichen, können Marktpartner Nachrichten an andere Marktpartner schicken. Diese Nachrichten folgen einer strikten Definition. Der sendende Marktpartner ist für die Inhalte verantwortlich. Um Fehler des Marktpartners zu identifizieren, kann der Inhalt der Nachrichten mit Hilfe dieser Prüfungen geprüft werden. Somit kann verhindert werden, dass falsch gestellte Rechnungen automatisch bezahlt werden.

Grundlagen der Prüfung

Grundlage der Prüfungen sind die vom Marktpartner gesendeten Nachrichten. Diese werden im System eingelesen, und die Prüfungen erfolgen auf Basis der Nachricht. Die Inhalte der Nachricht werden zum Teil mit Daten in MBS verglichen, um zu einem Ergebnis zu kommen.

Verhalten

  • Eine Prüfung besteht aus mehreren Schritten
    1. Entgegennahme der relevanten Parameter
    2. Prüfung, ob die übergebenen Parameter vorhanden sind
    3. Prüfung, ob sie für die entsprechende INVOIC zuständig ist
    4. Ausführung der Prüflogik
    5. Speicherung des Prüfergebnisses
  • Zu jeder Prüfung wird entweder eine Erfolgsmeldung oder eine Fehlermeldung hinterlegt
    • Es kann immer nur eine Meldung pro Prüfung als Ergebnis gespeichert werden
    • Pro Prüfung können verschiedene Meldungen (Erfolge oder Fehler) gespeichert werden
  • Pro Prüfung ist genau ein Antwortqualifier für die REMADV hinterlegt
  • Es kann eine Folgeaktion für den Fehlschlag einer Prüfung definiert werden. Was diese bedeuten, finden Sie in Prüfung auswerten
    • INVOIC ablehnen: INVOIC ohne Sachbearbeiter-Aufgabe
    • INVOIC ablehnen: INVOIC ohne Prüfung durch Sachbearbeiter + Aufgabe zur Information erzeugen
    • INVOIC blockieren und Aufgabe zur manuellen Prüfung erzeugen
    • INVOIC blockieren
  • Es ist festgelegt, welche Prüfung für welche Belegart angewendet wird

Status einer INVOIC

Folgende Status kann eine INVOIC in MBS besitzen, die von dem Prozess und der Nutzerinteraktion abhängig sind:

Beschreibung der Status und Statusübergänge der INVOIC

Prozess in MBS

Übergeordneter Prozess

Zwei Teilprozesse sorgen für die Abarbeitung von eingehenden Kreditorenrechnungen in mBS.

  • Ein Prozess liest die Daten ein und prüft diese
  • Der zweite Prozess reagiert auf die Nachrichten, führt notwendige Aktionen durch und beantwortet die Nachrichten
  • Die hier beschriebenen Prüfungen finden im ersten Prozess statt. Die groben Schritte dieses Prozesses sind:
    • Die Nachricht parsen (einlesen)
    • Die Prüfungen werden aus der Konfiguration geladen
    • Die einzelnen Prüfungen werden angestoßen
    • Die Ergebnisse der Prüfungen werden ausgewertet

In der folgenden Abbildung sind beide Prozesse dargestellt.

Kreditor-Rechnung verbuchen

In diesem Schritt der Verarbeitung werden für die Rechnung Buchungen oder Gegenbuchungen (Storno) erzeugt (auf den Stack gelegt). Die Buchungen werden an dieser Stelle noch nicht aktiviert. Dies geschieht erst zum Zeitpunkt des versenden einer positiven REMADV. Für den Storno-Fall gilt folgendes:

  • Ist die Originalrechnung bereits positiv beantwortet
    • Es werden Gegenbuchungen zur Originalrechnung erzeugt
    • Die Summe der Stornopositionen wird in der REMADV ausgewiesen
  • Ist die Originalrechnung noch nicht beantwortet
    • Es werden die Buchungen für die Originalrechnung erzeugt
    • Es werden Gegenbuchungen zur Originalrechnung erzeugt
    • Für die in der REMADV ausgewiesene Summe gilt, die Originalrechnung und die Storno heben sich gegenseitig auf

Der Ablauf ist in der folgenden Abbildung noch einmal skizziert.

Kreditor-Rechnung prüfen

Die Prüfungen werden entsprechend ihrer konfigurierten Reihenfolge ausgeführt. Folgende Schritte werden dann für jede Prüfung durchgeführt:

  • Bestimmen, ob die Prüfung für die Belegart Anwendung findet
  • Die Prüfschritte durchführen
  • Sollte die Prüfung keinen Fehler ergeben:
    • Positives Ergebnis schreiben
  • Sollte die Prüfung negativ ausfallen
    • Fehlermeldung schreiben
    • Den Ablehnungsqualifier merken

Die Prüfungen können zusätzlich zu MBS auch auf Daten aus dem Altsystem zugreifen, dies wird in den Grundeinstellungen mit INVOIC_VALIDATION_USE_SAP_HISTORY gesteuert.

Der Ablauf ist in der folgenden Abbildung noch einmal skizziert.

Prüfungen auswerten

Das wesentliche Ziel der Prüfungen ist es, die eingehenden Kreditorenrechnungen gemäß der Prüflogiken zu validieren und das Ergebnis festzuhalten. Der der Validierung der Kreditorenrechnungen nachgelagerte Prozess wertet die zuvor festgehaltenen Ergebnisse aus und führt die entsprechenden Folgeaktionen aus.

Dabei werden die Prüfergebnisse der aktuellen Kreditorenrechnung geladen und nach folgendem Schema ausgewertet:

  • Existieren keine fehlerhaften Prüfergebnisse
    • die Kreditorenrechnung wird akzeptiert
  • Existieren fehlerhafte Prüfergebnisse
    • Existieren fehlerhafte Prüfergebnisse mit der Folgeaktion “NoInfo”
      • die Kreditorenrechnung wird abgelehnt
    • Existieren fehlerhafte Prüfergebnisse mit der Folgeaktion “Info”
      • die Kreditorenrechnung wird abgelehnt
      • es wird eine Aufgabe für Sachbearbeiter mit der an der entsprechenden Prüfungskonfiguration angegebenen Rolle erzeugt
    • Existieren fehlerhafte Prüfergebnisse mit der Folgeaktion “Block”
      • die Kreditorenrechnung wird in den Status “In Klärung” versetzt
      • es wird eine Aufgabe für Sachbearbeiter mit der an der entsprechenden Prüfungskonfiguration angegebenen Rolle erzeugt
    • Existieren fehlerhafte Prüfergebnisse mit der Folgeaktion “BlockNoInfo”
      • die Kreditorenrechnung wird in den Status “In Klärung” versetzt

Im Folgenden ist der zuvor beschriebene Ablauf nochmals skizziert:

Wird aufgrund von fehlerhaften Prüfergebnissen eine Kreditorenrechnung automatisch abgelehnt, wird immer der Ablehnungsgrund für die Beantwortung der Kreditorenrechnung verwendet, der an der entsprechenden Konfiguration (des relevanten Prüfergebnisses) mit der niedrigsten Sortierungszahl hinterlegt ist.

Sachbearbeiteraufgaben (Feature für die Zukunft)

Zu jeder Prüfung kann eine Rolle hinterlegt werden. Ist die Prüfung so konfiguriert, dass eine Sachbearbeiteraufgabe erzeugt wird, wird in der Aufgabe die Rolle hinterlegt. Siehe Aufgaben

Datenbanksicht (Diese Erläuterung wird entfernt, sobald die Administration in der UI fertig ist)

Name der Datenbank fl_creditinvoicvalidaconfig Felder:

  • id_ –> interne Datenbank ID
  • name_ –> Name
  • description_ –> Beschreibung
  • role_ –> Rolle
  • active_ –> Status
  • order_ –> Ausführungsreihenfolge
  • invvalacttyp_errorcluster_ –> Folgeaktion

Übersicht Belegarten

Die Belegart definiert sich über 2 Elemente der Nachricht:

  • BGM-Segment
  • IMD-Segment

Die folgende Tabelle stellt alle in MBS relevanten Belegarten dar.

BGM IMD Belegbezeichnung MBS-Belegart
380 ABR Abschlussrechnung 380-ABR
380 JVR Turnusrechnung 380-JVR
380 MVR Monatsrechnung 380-MVR
380 ZVR Zwischenrechnung 380-ZVR
380 13I Integrierte 13.Rechnung 380-13I
380 13R 13.Rechnung 380-13R
457 ABR Abschlussrechnung (Storno) 457-ABR
457 JVR Turnusrechnung (Storno) 457-JVR
457 MVR Monatsrechnung (Storno) 457-MVR
457 ZVR Zwischenrechnung (Storno) 457-ZVR
457 13I Integrierte 13.Rechnung (Storno) 457-13I
457 13R 13.Rechnung (Storno) 457-13R
380 ABS Abschlagsrechnung (ABS) 380-ABS
457 ABS Abschlagsrechnung (Storno) 457-ABS
380 MMM Mehr- und Mindermengenrechnung (MMM) 380-MMM
389 MMM Selbst ausgestellte Mehr- und Mindermengenrechnung 389-MMM
457 MMM Storno Mehr- und Mindermengenrechnung 457-MMM
Z25 MMM Storno selbst ausgestellte Mehr- und Mindermengenrechnung Z25-MMM
380 MSB Rechnung für Messstellenbetrieb 380-MSB
457 MSB Rechnung für Messstellenbetrieb (Storno) 457-MSB
380 WIM Rechnung für WiM 380-WIM

Übersicht der Prüfungen

Name Kurzbeschreibung Ablehnungsqualifier Belegarten Link
NNA 1 Identifikation der Abnahmestelle 14 380-*, 457-*, 389-MMM, Z25-MMM Link
NNA 2 Sender und Empfänger 28 380-* (ohne MSB), 457-* (ohne MSB), 389-MMM, Z25-MMM Link
NNA 3 Vertragszeitraumprüfung 9 380-* (ohne MSB), 457-* (ohne MSB) Link
NNA 4 Rechnungszeitraum 9 380-[ABR,JVR,ZVR] Link
NNA 5 Artikelnummern Z06 380-* (ohne MSB), 457-* (ohne MSB), 389-MMM, Z25-MMM Link
NNA 6 Rechnerische Prüfung 5 380-*, 389-MMM Link
NNA 7 Doppelte Belege 53 380-*, 457-*, 389-MMM, Z25-MMM Link
NNA 8 Steuersatz Z45 380-*, 389-MMM Link
NNA 9 Fälligkeit 28 380-*, 457-*, 389-MMM, Z25-MMM Link
AB 1 Plausibilisierung des Abschlagsbetrages Z03 380-ABS Link
AB 2 Prüfung der Abschlagsbeträge gegen die Preiskomponenten des Tarifs Z03 380-ABS Link
ST 1 Prüfung auf vorhandene Originalrechnung 28 457-* (ohne WIM), Z25-MMM Link
ST 2 Prüfung auf Status der Originalrechnung 28 457-* (ohne WIM), Z25-MMM Link
MM 1 Zeitraumprüfung (Prüfung Bilanzierungs-zeitraum) Z35 380-MMM, 389-MMM Link
MM 2 Preisprüfung 5 380-MMM, 389-MMM Link
MM 3 Mengenprüfung Z37, Z42, 28 380-MMM, 389-MMM Link
MM 4 Erlaubnisscheine Z45 380-MMM, 389-MMM Link
MM 5 Reverse-Charge Z45 380-MMM, 389-MMM, 457-MMM, Z25-MMM Link
MM 6 Steuernummern 28 380-MMM, 389-MMM Link
MS 1 Prüfung auf vorhandene QUOTES Z52 380-MSB Link
MS 2 Prüfung auf doppelte Abrechnung Positionen 28 380-MSB Link
MS 3 Abgleich Positionen Rechnung und QUOTES 5 380-MSB Link
MS 4 Preisprüfung 5 380-MSB Link
NNR 1 Prüfung auf geleistete Anzahlungen Z04 380-[ABR,JVR,ZVR] Link
NNR 2 Prüfung auf empfangene Zählwerte Z07, 28, Z10, Z33 380-[ABR,JVR,ZVR] Link
NNR 3 Prüfung MSB-Entgelte 5 380-[ABR,JVR,ZVR] Link
NNR 4 Prüfung e'net-Preise 5 380-[ABR,JVR,ZVR] Link

Behandlung von Storno Nachrichten

Das System stellt sicher, das eine Storno und deren stornierte Nachricht automatisiert immer beide akzeptiert oder abgelehnt werden.

Es werden die folgenden Fälle behandelt:

  1. Sobald eine Storno eingeht und die stornierte Nachricht noch nicht beantwortet ist, wird die Storno auf akzeptieren und die stornierte Nachricht auf stornieren gesetzt.
    Storno und stornierte Nachricht werden zusammen in einer Remadv bestätigt. Gebucht werden die Nachrichten nicht.
    Den Status der stornierten Nachricht kann man nicht ändern, solange die Storno auf akzeptieren bleibt. Wenn man die Storno über die Oberfläche auf ablehnen setzt, wird die stornierte Nachricht automatisch neu plausibilisiert. Wenn die Storno nachträglich wieder auf akzeptieren gesetzt wird, wird die stornierte Nachricht wieder auf stornieren gesetzt.

  2. Falls die stornierte Nachricht schon positiv beantwortet wurde, wird die Storno auf akzeptieren gesetzt und beide Nachrichten sind nach Beantwortung der Storno gebucht.

  3. Falls die stornierte Nachricht schon negativ beantwortet wurde, wird auch die Storno auf ablehnen gesetzt. (Prüfung ST2)

  4. Es wird keine stornierte Nachricht gefunden. Dann wird die Storno auf “zu prüfen” gesetzt. Jeden Abend um 19:30 Uhr werden automatisch alle Nachrichten im Status “zu prüfen” neu plausibilisiert. Wenn in der Zwischenzeit die stornierte Nachricht eingegangen ist, wird die Storno automatisch zugeordnet und beide Nachrichten werden wie in 1. beschrieben behandelt.

Damit das Vorgehen funktioniert, dürfen die Prüfungen ST1 und ST2 für Stornos nicht deaktiviert werden. Außerdem muss ST1 auf “Aufgabe zur manuellen Prüfung erzeugen” oder “manuelle Prüfung erforderlich, ohne Aufgabe” stehen, ansonsten werden die Stornos nicht jeden Abend neu plausibilisiert.