Business Use Case
In vielen Unternehmen werden Kundenaufträge automatisiert per IDoc in das SAP-System eingespielt – etwa durch EDI-Schnittstellen mit Großkunden. Was zunächst wie ein effizienter Prozess klingt, birgt jedoch Risiken: Falsch befüllte Daten, unvollständige Informationen oder fehlerhafte Preisfindungen können zu Problemen in der weiteren Auftragsabwicklung führen. Ohne eine manuelle Kontrolle schleichen sich solche Fehler leicht unbemerkt ins System ein. Besonders in komplexen Vertriebsprozessen oder bei sensiblen Kundenbeziehungen ist es daher sinnvoll, eine Qualitätssicherung vorzuschalten. Hier kommen SAP-Workflows ins Spiel: Sie ermöglichen es, eingehende Aufträge automatisiert an definierte Bearbeiter zur Prüfung und Freigabe weiterzuleiten. So lassen sich Fehler frühzeitig erkennen und beheben – bevor sie kostspielige Auswirkungen haben. Der Workflow kann dabei flexibel an verschiedene Prüfregeln und Verantwortlichkeiten angepasst werden. In diesem Blogbeitrag zeige ich, wie ein solcher Prozess in SAP umgesetzt werden kann.
Lösungsansatz
Kundenaufträge, die aus IDocs entstehen, werden mit einer entsprechenden Fakturasperre – in unserem Fall 02 („Rückmeldung fehlt“), es können auch neue Sperren für diesen Fall definiert werden. Diese Fakturasperre kann im Kunden bereits gesetzt oder – was aus prozessualer Sicht empfohlen wird – in einer Middleware oder bei der IDoc-Eingangsverarbeitung im ERP-System gesetzt werden. Beim Anlegen eines Kundenauftrags wird automatisch ein Workflow gestartet, der die Prüfung und weitere Bearbeitung des Auftrags regelt. Die Erkennung von Aufträgen aus IDocs ist über die o. g. Fakturasperre (Kennzeichen) möglich.
Nach Prüfung und Erkennung der Sperre wird der Kundenauftrag als Workitem der*dem zuständigen Mitarbeiter*in zur Weiterverarbeitung zugewiesen. Dazu erfolgt eine Benachrichtigung per Expressnachricht (SAP Business Workplace). Die Annahme und Bearbeitung des Workitems führt zu einem Absprung in die Auftragsbearbeitung (VA02). Dort prüft die*der Anwender*in die Auftragsdaten, führt gegebenenfalls Korrekturen durch und entfernt schließlich die Fakturasperre. Damit ist der Auftrag zur weiteren Bearbeitung freigegeben.
Mit dem Sichern wird die Bearbeitungs-Aktivität abgeschlossen und der Workflow beendet.
Umsetzung
Um Kundenaufträge per Workflow bearbeiten zu können, wurde dem Workflow-Container ein Element vom Business-Objekttyp „BUS2032“ zugewiesen. Dieser Objekttyp beinhaltet bereits sämtliche Attribute, Ereignisse und Methoden, die für die Analyse und Bearbeitung von Kundenaufträgen nötig sind, soweit es das hier dargestellte Szenario betrifft. Sollten doch weitere benötigt werden, ließen diese sich auf Basis dieses Objekttyps anlegen, ohne bei Null anfangen zu müssen.
Schritt 1:
Prüfen der oben definierten Bedingung, ob eine Bearbeitung des Kundenauftrags notwendig ist, bevor er freigegeben werden kann. Hierzu wird ein Schritt vom Typ „Bedingung“ angelegt.
Wie bereits angesprochen, wurde für dieses Beispiel das Vorhandensein einer Fakturasperre als Bedingung gewählt. Da der Fall, dass die Bedingung nicht erfüllt ist, keine weiteren Schritte beinhaltet, wird dieser hier auch nicht weiter dargestellt.
Schritt 2:
Es wird dem Bearbeiter (üblicherweise bestimmt über eine Organisationseinheit) eine Nachricht geschickt (Schritttyp „Mail versenden“), um ihn über das Vorhandensein des Auftrags sowie die Notwendigkeit der Bearbeitung zu informieren. Diese Nachricht erhält der Mitarbeiter als Express System-Nachricht im System.
Schritt 3:
Der Auftrag wird dem Bearbeiter als Workitem zugewiesen und eine Möglichkeit geboten, direkt in die Bearbeitung des Auftrags abzuspringen. Hierfür wird ein Schritt vom Typ „Aktivität“ verwendet, der eine Aufgabe mit Verweis auf die „Change“-Methode des verwendeten Objekttyps beinhaltet.
Schritt 4:
Nachdem der Bearbeiter die Transaktion VA02 wieder verlassen hat, wird der Workflow beendet. Für den Umfang des Beispiel-Szenarios wurden keine weiteren Prüfungen/Aktivitäten nachgeschaltet. Inwieweit diese evtl. noch notwendig wären, hängt natürlich vom konkreten Anwendungsfall ab.