Best Practices - logische Rückmeldeprozesse (CONTRL, APERAK, REMADV, UTILMD,..) Dr. Stefan Klose

Rückmeldeprozesse: Worum geht es? Im Datenaustausch werden neben den logischen Antwortnachrichten (z.B. REMADV und UTILMD) Eingangsprüfungen durch eine CONTRL (Empfangsbestätigung und Syntaxprüfung) und ggfs. eine APERAK Nachricht (Modellfehlermeldung) ausgetauscht. Denkbare Verarbeitungsfehlermeldungen und Anerkennungsmeldungen werden derzeit nicht gefordert. Die Anforderungen an die Rückmeldeprozesse können lückenlos mit B2B by Practice im Standard abgebildet werden. Dies beinhaltet ein komfortables Customizing und Monitoring der Rückmeldenachrichten, ein Fristenmanagement und die Verknüpfung mit den Backendbelegen. Architektonisch ist es nur auf B2B by Practice möglich, systemübergreifend (SAP, nonSAP) alle Rückmeldugen zentral zu monitoren.

Rückmeldeprozesse Beispiel: eingehende Nachrichten B2B Lastgänge nonSAP B2B Lastgänge nonSAP APERAK CONTRL TL CONTRL TL TL TL MSCONS MSCONS VL Zählerstände SAP VL VL CONTRL CONTRL 4711 4711 Zählerstände SAP 4712 4712 APERAK 4713 4713 Variante A SAP Status (IDOC, ….) Variante B Das NON SAP System hat ein eigenes CONTRL und APERAK Handling. B2B greift hier nicht ein, sondern routet diese Nachrichten weiter. Dadurch wird die 1:1 Kommunikation gewährleistet, die Vorgänge sind im systemübergreifenden B2B Monitoring incl der Volltextsuche verfügbar. Rückantworten können dem richtigen System zugeordnet werden. Das SAP System (in dem speziellen Beispiel) kann MSCONS Nachrichten mit mehreren Turnusablesungen nicht automatisch verarbeiten. Deshalb werden diese Nachrichten auf B2B gesplittet, um auf SAP Seite mehrere IDOCs zu erzeugen, die automatisch verarbeitet werden können. Für das SAP System wird das Contrl und Aperak Handling von B2B genutzt. (Das kann man natürlich auch für jedes NON SAP System nutzen). Variante A: Wenn keine Fehler vorliegen, werden die IDOCs in SAP angelegt. Der Status (pos Contrl gesendet) wird an diesen IDOCs gesetzt. Der SAP Verarbeitungsstatus wird in das B2B Monitoring (inkl. z.B. IDOC Nr) übertragen. Variante B: Im Fehlerfall (auf Basis Syntax- oder Modellfehlerprüfung) wird das SAP System nicht mit fehlerhaften IDOCs „belastet“. Im B2B Monitoring werden alle Contrls / Aperaks mit direktem Bezug zu den eingehenden Nachrichten angezeigt. Die Backendbelege werden ebenfalls im B2B Monitoring incl. Verarbeitungsstatus dazu angezeigt (z.B Angabe der IDOC Nummern und SAP Status) VL 4711 4712 4713 4711 4712 4713

Rückmeldeprozesse Eingehende Nachrichten: Regelverarbeitung mit SAP Status 2380405 16156902

Rückmeldeprozesse Eingehende Nachrichten: Modellfehler (pos Contrl, APERAK) pos Contrl auf Aperak

Rückmeldeprozesse Eingehende Nachrichten: Ablehnung mit neg. Contrl Im Contrl wird dem Marktpartner detalliert der Ablehnungsgrund mitgeteilt

Rückmeldeprozesse ausgehende Nachrichten: Modellfehlerhandling (pos Contrl, APERAK)

Rückmeldeprozesse ausgehende Nachrichten: Modellfehlerhandling (pos Contrl, APERAK) interne Eskalation kann individuell gesteuert werden

Rückmeldeprozesse Fristenmanagement Die Fristen werden über Scheduler und den „Werkskalender“ von B2B überwacht

Rückmeldeprozesse Zusammenfassung Auf B2B by Practice wird implizit auf Basis der BDEW/DVGW Spezifikationen eine Syntax- und Modellfehlerprüfung vorgenommen. Diese ist auch individuell einstellbar Es müssen keine Prüfungen in den Backendsystemen vorgenommen werden. Für alle Systeme gibt es dann ein zentrales Rückmeldungshandling Der Status des Rückmeldungshandlungs wird z.B in SAP Systeme übertragen. Wenn dies doch gewünscht ist, kann die Prüfung für diese Systeme auf B2B deaktiviert werden B2B by Practice ist die einzige Stelle, die über alle Systeme / Mandanten hinweg ein zentrales Monitoring erlaubt. Dies spricht für das Rückmeldungshandling auf B2B Durch den tiefen Statusabgleich mit z.B SAP ist B2B by Practice auch in der Lage Verarbeitungsfehlermeldungen und Annerkennungsmeldungen zentral zu erzeugen, wenn diese künftig einmal gefordert werden sollten

Kontakt