6 min Lesezeit

Monitoring im EDI - Wo sind meine Nachrichten?

Wir wollen wissen, was mit unseren Nachrichten passiert…

Was wir im privaten Bereich an Diensten wie WhatsApp schätzen, ist aus dem EDI-Bereich schon längst nicht mehr wegzudenken — die gesicherte und verlässliche Zustellung von Nachrichten. Denn während der fehlgeschlagene Versand einer SMS — die beispielsweise unsere Verabredung zum Abendessen über eine Verspätung informieren soll — noch relativ glimpflich ausgehen kann, ist die Nachvollziehbarkeit und gesicherte Zustellung von EDI-Nachrichten essentiell. Verlorengegangene INVOIC-Nachrichten oder ZUGFeRD-Rechnungen können schön äußerst ärgerlich sein. Nicht auszudenken allerdings wenn wir uns über den Verbleib von Bewegungsdaten wie z.B. ORDERS (Bestellungen) nicht sicher sein können: was am Vormittag bestellt wird, muss in manchen Branchen und Lieferketten bereits am Nachmittag ausgeliefert werden. Werden DESADV (Lieferscheine) nicht erhalten, steht womöglich niemand zum Abladen am Cross-Docking Lager bereit, wenn der LKW mit der Lieferung eintrifft.

Damit derartige Szenarien vermieden werden können und wir im Falle von Problemen bei der Zustellung von EDI-Nachrichten entsprechend gegensteuern können, wird der Erhalt (und teilweise auch die Verarbeitung) von EDI-Nachrichten üblicherweise bestätigt. Denn ohne Bestätigungen kann auch kein durchgehendes Monitoring im EDI ermöglicht werden.


Empfangsbestätigung im EDI-Bereich
Empfangsbestätigung im EDI-Bereich

Dabei können wir generell nach zwei verschiedenen Ebenen von Bestätigungen (engl.: Acknowledgments) unterscheiden: (i) Jene auf Protokollebene und (ii) jene auf Nachrichten- oder auch Prozessebene.

Monitoring auf Protokollebene

Bestätigungen auf dieser Ebene sind Bestandteil des verwendeten Standards/Protokolls zum Nachrichtenaustausch. Dabei erfolgt die Bestätigung zumeist direkt von der jeweiligen Messaging-Komponente des Empfängers, sobald die Nachricht technisch einwandfrei empfangen wurde und noch bevor sie ins Warenwirtschaftssystem importiert wurde. Im EDI-Bereich trifft man vor allem auf zwei Protokolle, die sich wegen ihrer Sicherheit und ihrer Nachvollziehbarkeit bislang etabliert haben.

AS2

AS2 (Applicability Statement 2) ist ein Protokoll zur sicheren und zuverlässigen Übertragung von Nachrichten zwischen zwei Partnern (Punkt-zu-Punkt Prinzip) auf Basis des HTTP-Protokolls. Erhaltene Nachrichten werden standardmäßig durch einen MDN (Message Disposition Notification) quittiert. Der MDN kann dabei entweder synchron oder asynchron vom Sender angefordert werden.


Empfangsbestätigung bei AS2
Empfangsbestätigung bei AS2

Im ersten Fall wird der MDN direkt nach der Übertragung der Nachricht vom Sender zum Empfänger — und zwar im Rahmen der gleichen HTTP-Verbindung — vom Empfänger der Nachricht an den Sender übermittelt.

Im zweiten Fall wird der MDN in einer separaten HTTP-Verbindung an den Sender der eigentlichen Nachricht übertragen. Synchrone MDNs sind heute oftmals beliebter, da die Antwort „schneller“ erhalten wird. Bei höheren Volumina bzw. großen Nachrichten empfiehlt sich jedenfalls die Verwendung von asynchronen MDNs. Konnte die Nachricht nicht einwandfrei empfangen werden (z.B. weil sie aufgrund fehlerhaft konfigurierter Zertifikate nicht entschlüsselt werden konnte), wird ein „negativer MDN“ retourniert.

X.400

X.400 (siehe auch unseren früheren Beitrag) ist ein auf dem Mailbox-Prinzip basierendes Protokoll, wobei die Kommunikation über dedizierte Netzwerke getrennt vom Internet erfolgt. X.400 kennt prinzipiell zwei Typen von Bestätigungen: Delivery Notifications (DN) und Receipt Notifications (RN).


Empfangsbestätigung bei X.400
Empfangsbestätigung bei X.400

Delivery Notifications werden vom Mailserver des Empfängers generiert, wenn dieser die Nachricht an die Mailbox des Empfängers zustellt. Das negative Pendant zur DN ist die sogenannte Non-delivery Notification (NDN) und wird im Fehlerfall an den Sender übermittelt.

Receipt Notifications können von der Clientsoftware des Empfängers generiert werden – in der Praxis wird die RN in der automatisierten Übertragung kaum angefordert bzw. unterstützt, sodass üblicherweise mit dem Erhalt einer DN davon ausgegangen wird, dass der Empfänger die Nachricht erhalten hat (und auch verarbeiten kann). Das negative Pendant zur RN ist die Non-receipt notification (NRN).

Interessanterweise kennt auch unser bekanntes Internet Email (d.h. das darunterliegende SMTP-Protokoll), diese beiden Typen von Bestätigungen. Der Sender eines Emails kann vom Mailserver des Empfängers eine sogenannte Delivery Status Notification (DSN) anfordern — was das Pendant zur Delivery Notification (DN) bei X.400 ist. Im Fehlerfall werden in der Praxis automatisiert negative DSNs bei Zustellungsproblemen vom Mailserver an den User zurückgemeldet (z.B. der Empfänger ist unbekannt).

Ebenso kann der Sender vom Empfänger eine Message Disposition Notification (MDN) anfordern, die vom Empfänger über das E-Mail Programm auf Nachfrage versandt werden kann. In der Praxis haben sich Lesebestätigungen bei Internet E-Mail kaum durchgesetzt bzw. werden Anforderungen für Lesebestätigungen oft ignoriert.

Monitoring auf Nachrichten­ebene

Bestätigungen auf Nachrichtenebene sind „reguläre“ Geschäftsdokumente, die — aufgrund eines definierten Prozesses — bei Erhalt des eigentlichen Geschäftsdokumentes vom Empfänger retourniert werden. Ein gängiges Beispiel in der EDIFACT-Welt ist, dass eingehende ORDERS-Nachrichten mit einer CONTRL-Nachricht beantwortet werden. Die CONTRL-Nachricht bestätigt dabei, dass der EDIFACT-Interchange importiert und syntaktisch korrekt verarbeitet werden konnte. Neben der CONTRL-Nachricht, die eigentlich auf die syntaktische Verarbeitung fokussiert, kann mittels APERAK-Nachrichten der Status der fachlichen Verarbeitung einer eingehenden Nachricht rückgemeldet werden und einzelne Positionen der eingehenden Nachrichten akzeptiert bzw. abgelehnt werden.

Je nach Branche und lokaler Gegebenheit variiert die Verwendung von Bestätigungen auf Nachrichtenebene. Zumeist verlässt man sich auf die Bestätigungen auf Protokollebene — d.h. konkret auf X.400 Delivery Notifications (DN) oder AS2 MDNs. In den Niederlanden ist es jedoch beispielsweise auch üblich, dass Bestellprozesse eine ORDERS-Nachricht mittels APERAK-Nachricht bestätigen. Auch in Deutschland beginnen einige Unternehmen im Lebensmittelhandel damit, sich den Nachrichtenerhalt mittels CONTRL-Nachrichten bestätigen zu lassen. Besonders detailliert ist die Verwendung von CONTRL und APERAK-Nachrichten für die Energiebranche in Deutschland definiert. Hier sehen Austauschbeziehungen (z.B. bei Wechsel des Stromlieferanten) einen zweistufigen Bestätigungsprozess vor, indem nach erfolgter Syntaxprüfung zuerst eine CONTRL-Nachricht und nach erfolgter fachlicher Prüfung eine APERAK-Nachricht retourniert wird.

Monitoring und Nachvoll­ziehbar­keit bei ecosio

Die Nachvollziehbarkeit der Austauschbeziehungen hat bei ecosio höchste Priorität. ecosio aggregiert die unterschiedlichen Bestätigungstypen auf Protokoll- sowie Nachrichtenebene zu einem einheitlichen Schema und ermöglicht die komplette Nachvollziehbarkeit des Statusverlaufs. Dieses „Ende-zu-Ende“-Monitoring können Benutzer entweder über den komfortablen ecosio.Monitor mittels Web-Browser einsehen oder auch über eine einheitliche und einfache API direkt in die Warenwirtschafts- bzw. Inhousesysteme einbinden.

Für einige ERP-Systeme wie z.B. Mesonic, BMD aber auch SAP existieren bereits vorgefertigte Lösungen. Wir beraten Sie gerne dazu.

© 2020. SAP SE oder ein SAP-Konzernunternehmen. Alle Rechte vorbehalten. Mit Genehmigung der SAP SE verwendet.

Meistgelesen

Weiterlesen

5 min Lesezeit

e-Rechnung in Spanien

Welche Vorschriften gibt es für die e-Rechnung in Spanien? Finden Sie heraus, was erforderlich ist und welche Änderungen in Zukunft zu erwarten sind.

6 min Lesezeit

e-Rechnung in Frankreich

Ist die e-Rechnung in Frankreich Pflicht? Lesen Sie unseren Artikel, wie Sie die aktuellen und bevorstehenden Regelungen in Frankreich erfüllen können.

4 min Lesezeit

WebEDI - Was, warum und wie?

Dieser Artikel ist ein Auszug aus unserem White Paper “Welchen Einfluss hat WebEDI auf meine Lieferkette” und zeigt Ihnen, was WebEDI ist, warum es verwendet wird und wie es funktioniert.

3 min Lesezeit

Drei Herausforderungen für jede WebEDI-Lösung

Welche drei Herausforderungen muss jede WebEDI-Lösung bewältigen? Darüber lesen Sie in diesem Exzerpt aus unserem White Paper "Welchen Einfluss hat WebEDI auf meine Lieferkette?".

6 min Lesezeit

Vorteile der e-Rechnung nutzen

Die Einführung der elektronischen Rechnungslegung (e-Rechnung) bringt eine Reihe von Vorteilen mit sich. Welche das genau sind, stellen wir vor.

6 min Lesezeit

Wie setze ich EDI mit SAP® Cloud Platform Integration um?

EDI mit SAP Cloud Platform Integration: intern selbst übernehmen oder einen Fully Managed EDI-Dienstleister beauftragen? Wir helfen Ihnen bei der Entscheidung.

4 min Lesezeit

Supply Chain Automatisierung via EDI - Die vier Herausforderungen

Standards, Technologie, Prozesse und gesetzliche Anforderungen - über die großen vier Hürden der Supply Chain Automatisierung.

7 min Lesezeit

XML-Checker in das ERP-System integrieren – warum und wie?

Welche Vorteile bringt die Integration eines XML-Checkers direkt in das ERP-System des Unternehmens? Das und wie die Umsetzung funktioniert lesen Sie in diesem Artikel.

2 min Lesezeit

Wie kann ich einen SAP-Transaktionscode anlegen?

Wie kann ich für ein bestehendes ABAP-Programm einen SAP-Transaktionscode anlegen, damit ich das Programm einfach aufrufen kann? Wir stellen im Folgenden eine kurze Anleitung vor.

10 min Lesezeit

EDI-Onboarding von Lieferanten in 7 Schritten

Das EDI-Onboarding von Lieferanten muss nicht kompliziert sein. In diesem Artikel zeigen wir Ihnen 7 Schritte zur erfolgreichen Lieferantenanbindung.

Wir verwenden Cookies, um ein optimales Website-Erlebnis zu bieten. Sie entscheiden, welche Sie zulassen möchten. Je nach Einstellung stehen Ihnen aber womöglich nicht alle Funktionalitäten zur Verfügung. Datenschutzhinweise & Impressum.