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
- Entgegennahme der relevanten Parameter
- Prüfung, ob die übergebenen Parameter vorhanden sind
- Prüfung, ob sie für die entsprechende INVOIC zuständig ist
- Ausführung der Prüflogik
- 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:
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
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
- Existieren fehlerhafte Prüfergebnisse mit der Folgeaktion “NoInfo”
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 |
| 380 | Z43 | Rechnung für Sperren und Wiederinbetriebnahme | 380-Z43 |
| 380 | Z44 | Verzugskostenrechnung | 380-Z44 |
Ü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 |
| ALWAYS_FAIL | Rechnung mit dem Prüfi 31011 müssen immer von einem Sachbearbeiter geprüft werden. | 380-[Z43,Z44] |
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:
-
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. -
Falls die stornierte Nachricht schon positiv beantwortet wurde, wird die Storno auf akzeptieren gesetzt und beide Nachrichten sind nach Beantwortung der Storno gebucht.
-
Falls die stornierte Nachricht schon negativ beantwortet wurde, wird auch die Storno auf ablehnen gesetzt. (Prüfung ST2)
-
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.