Ansicht
Dokumentation

Änderungen im SAP Business Workflow (Enterprise Buyer 5.0) ( RELNEBP_50_WORKFLOW )

CL_GUI_FRONTEND_SERVICES - Frontend Services   CL_GUI_FRONTEND_SERVICES - Frontend Services  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Kurztext

Änderungen im SAP Business Workflow (Enterprise Buyer 5.0)

Verwendung

Folgende Änderungen zum SAP Business Workflow werden im Release Enterprise Buyer (EBP) 5.0/ Supplier Relationship Management (SRM)4.0 realisiert:

• WS14500001 - Auto-Übernahme der BAW-Daten

• WS14500007 - Benachrichtigung bei Abweichung zw. PO und BAW

• WS14500015 - Positionsbasierte Genehmigung (HauptWF)

• WS14500017 - Überwachung Eingang BAW (Alert-Workflow)

• WS14500019 - Bestellantwort-Daten in PO übernehmen

• WS14500020 - Fehlerhafte Rechnung korrigieren

• WS14500021 - Benachrichtigung, wenn BP gesperrt ist

Benachrichtigungsworkflow nach Sperrung eines Lieferenten

Ein Einkäufer im EBP-System hat die Möglichkeit (ausreichende Berechtigung vorausgesetzt), einen SUS-Lieferanten zu sperren. Dann wird am Business-Objekt BUS1006200 (Geschäftspartner BBP) das Ereignis locked (Geschäftspartner wurde gesperrt) ausgelöst und der Workflow WS14500021 gestartet. Über die Methode GetPurchListFromOrg werden alle Einkäufer der Einkaufsorganisation, zu der der Lieferant gehörte, ermittelt und per Mail von der Sperrung benachrichtigt.

Alle weiteren Prozesse laufen unabhängig vom Workflow ab.

(Der gesperrte Lieferant erhält die Information über seine Sperrung auf dem Anmeldebild im SUS-System.)

Korrekturworkflow: Ausnahmebehandlung von fehlerhaften XML-Rechnungen (XML-IV)

Eine fehlerhafteLieferantenrechnung, die per XML im EBP-System ankommt, wird nicht mehr wie zu EBP 4.0 (oder früher) automatisch zurückgeschickt, sondern kann vom zuständigen Bearbeiter mit Korrekturen und Notizen versehen werden, bevor sie gebucht, gelöscht oder gemerkt wird.

Der Benutzer erhält beim Eingang einer fehlerhaften XML-IV ein Workitem per Korrekturworkflow WS14500020 (Fehlerhafte Rechnung korrigieren) und kann diese dann über einen Link ggf. direkt korrigieren oder löschen.

Beim Speichern einer fehlerhaften XML-IV wird (abhängig vom Fehlertyp) am Business-Objekt BUS2205 (Eingangsrechnung EC) das Ereignis ErrorInvoiceToBeProcessed (Fehlerhafte Rechnung korrigieren) ausgelöst, was den Kurrekturworkflow startet.

Der zuständige Bearbeiter (wird mittels BAdI BBP_WFL_ADMIN_APPROV ermittelt oder, falls diese Liste keine Genehmigenden enthält, per Bearbeiterzuordnung der Standardaufgabe TS10407925) kann die IV inklusive Fehlerquelle begutachten und entsprechend korrigieren.

Anmerkung

Im Gegensatz zu den IV-Genehmigungsworkflows, kann der Bearbeiter nach Absprung vom Link in der Benachrichtigung dieses Korrekturworkflows fast alle Felder der IV bearbeiten.

Datenübernahme der Daten einer Bestellantwort (BAW) in die Bestellung (PO)

Eine BAW kann als Reaktion auf die zugrundeliegende PO

1. aus einer XML-Nachricht des Lieferanten im EBP-System erzeugt werden oder aber auch
2. manuell von einem Desktopbenutzer (z.B. einer Sekretärein) oder einem Einkäufer (Professioneller Benutzer) angelegt werden.

In beiden Fällen wird eine BAW (Businessobjekt BUS2209) angelegt - die zugehörigen Startbedingungen (vordefiniert und ausgeliefert) werden ausgewertet, was das Starten verschiedener Workflows bewirkt:

• Automatische Datenübernahme (WS14500001)

Dieser Workflow wird gestartet, wenn

• die BAW die erste zur PO ist,

• sich die Daten innerhalb der (im Customizing hinterlegten) Toleranzen befinden,

• außer Änderungen von Preis, Menge und Lieferdatum keine weiteren Belegänderungen existieren,

• die zugrundeliegende PO keine Änderungsversion besitzt und

• die BAW nicht komplett vom Lieferanten abgelehnt wurde.

Die BAW-Daten werden ohne weiteres manuelle Eingreifen in die PO übernommen.

• Manuelle Datenübernahme durch Einkäufer (WS14500019)

Dieser Workflow startet, wenn vor der Datenübernahme ein manuelles Eingreifen durch den Einkäufer nötig wird, d.h., wenn eine der oben aufgeführten Bedingungen für WS14500001 nicht erfüllt wurde.

Anmerkung

BAWs, die aus XML-Daten erzeugt wurden, durchlaufen immer einen der beiden o.g. Workflows (Automatische oder Manuelle Datenübernahme).

Manuell angelegte BAWs werden in Abhängigkeit der Rolle des anlegenden Benutzers (Anlegers) - Desktopbenutzer oder Einkäufer - weiterverarbeitet:

• Im Falle des Desktopbenutzers durchläuft die BAW immer einen der o.g. Workflows (wie XML-BAW).

• Im Falle des Einkäufers hängt die weitere Verarbeitung vom Überschreiten der Toleranzen ab. Werden die Toleranzen nicht überschritten, startet der Standardworkflow mit automatischer Datenübernahme (WS14500001). Werden die Toleranzen überschritten, erfolgt ein Absprung direkt auf die manuelle Übernahmetransaktion, wo der Einkäufer die einzelnen Wertüberschreitungen direkt ablehnen oder genehmigen kann.
  

• Benachrichtigungsmail an Einkäufer (WS14500007)

Dieser Workflow startet unter exakt denselben Bedingungen wie WS14500019 (Manuelle Datenübernahme), jedoch informiert er den Einkäufer lediglich über das Eintreffen einer BAW und über die Notwendigkeit, manuell nachzubearbeiten.
Dieser Workflow ist als Alternative zum WS14500019 gedacht.

Eine PO kann vor dem Bestellen mit dem Kennzeichen Bestellantwort erwartet versehen werden, was dem Lieferanten anzeigt, dass als Reaktion auf die PO vom EBP-System obligatorisch der Eingang einer BAW erwartet wird. Für solche POs ist es notwendig, die Bestätigung aller Positionen zu überwachen:

Wird eine PO bestellt, so wird am Business-Objekt BUS2201 das Ereigenis Submitted (zum Lieferanten übermittelt) ausgelöst, was den Alert-Workflow WS14500017 startet. Dieser Workflow wartet dann auf das Ereignis Confirmed (vollständig bestätigt), was nur dann eintritt, wenn alle Positionen der PO innerhalb der Toleranzen vom Lieferanten zurückgemeldet werden. Dieses Ereignis muss innerhalb einer festgelegten Zeitgrenze erfolgen. Anderenfalls, wenn die Zeitgrenze ohne vollständige Rückmeldung überschritten wird, erhält der Einkäufer (*) ein Benachrichtigungsmail.

(*): Standardmäßig wird die Benachrichtigung von der Überschreitung der Zeitgrenze an den Anleger der Bestellung gesendet. Handelt es sich dabei um den technischen System-Benutzer WF-BATCH (dies ist z.B. dann der Fall, wenn die Bestellung automatisch aus einem Einkaufswagen erzeugt wurde), so wird die Alert-Mail an alle Einkäufer der Einkäufergruppe gesendet.

Hinweis

Der Überwachungszeitraum wird direkt in der Workflow-Definition eingestellt:
Im Schritt Default Frist für Bestellantwort setzen (Typ Containeroperation) ist der Zeitraum standardmäßig auf fünf Kalendertage eingestellt, kann jedoch in der Methode DeadLineDate von Business-Objekt BUS2201 (Bestellung EC) korrigiert werden. Die ist u.U. dann sinnvoll, wenn die Bestellungen früher als in fünf Kalendertagen geliefert werden sollen.

Siehe zum Thema Bestellantwort auch:
Release-Information Bearbeitung von Bestellantworten!

Positionsbasierter Genehmigungsprozess (WS145000015)

Scenariobeschreibung

In vorausgehenden Releases hatten Genehmigende stets den gesamten Einkaufswagen (SC) zu genehmigen/ abzulehnen, obwohl sie u.U. nur für bestimmte Positionen zuständig waren. Ab SRM 4.0 kann der Genehmigende in diesem Scenario aber nur die Positionen ändern und genehmigen/ ablehnen, für die er zuständig ist.

Die Zuständigkeit eines Genehmigenden kann nach verschiedenen Kriterien festgelegt werden, z.B. nach der Kostenstellenverantwortung eines Managers oder nach der Produktkategorie, für die der Leiter einer bestimmten Fachabteilung zuständig ist. So könne bspw. Genehmigende mit Zuständigkeit für eine Kostenstelle, nur die Positionen genehmigen, für die sie die Kostenstellenverantwortung tragen.

Erst nachdem alle Einzelpositionen eines SC von den jeweiligen Genehmigenden genehmigt wurden, erfolgt der nächste Genehmigungsschritt, bis nach dem letzten der gesamte SC freigegeben wird und bestellt werden kann.

(Positionen, für die keine Genehmigung erforderlich ist, werden nicht sofort separat nach Speichern des SC transferiert, sondern warten solange, bis alle Positionen genehmigt wurden, weil nur der gesamte SC transferiert wird.)

Eigenschaften

• Der Anleger des SC kann sowohl vor als auch während des Genehmigungsprozesses Positionen hinzufügen, den SC ändern oder löschen.
  Weiterhin hat er die Möglichkeit zur Genehmigungsvorschau (kann für die einzelnen Positionen unterschiedlich aussehen) sowie zum Hinzufügen/ Ändern von weiteren Genehmigenden auf Positions- bzw. Reviewern auf Einkaufswagenebene.

• Nach dem Speichern des SC bekommen die ermittelten Genehmigenden der einzelnen Positionen ein Workitem in seinen Eingang mit einem Überblick über alle Positionen und einer Kurzbeschreibung. Nach Anwählen des Links Details erfolgt der Absprung auf das SC-Genehmigungsbild, wo eine Übersicht über alle SC-Positionen erscheint. Der Genehmigende kann aber nur die Positionen ändern/ genehmigen, für die er zuständig ist.
  Anmerkung:
  Mit der Implementierung des BAdIs BBP_WFL_APPROV_BADI kann gesteuert werden, ob nach dem Detailabsprung für den Genehmigenden alle Positionen zu sehen sind (auch die, für die er nicht zuständig ist) oder alternativ nur die Positionen, für die er zuständig ist. (In beiden Fällen sind aber nur die relevanten Positionen zu ändern bzw. zu genehmigen.)

• Bisher hing ein Neustart des Workflows von der Berechtigungsstufe des Genehmigenden bzw. des Anlegers ab. In diesem Scenario erfolgt in keinem Fall ein Neustart des Workflows.
  In diesem Scenario dient die Berechtigungsstufe nur der Festlegung, ob ein SC während der Genehmigung änderbar ist oder nicht.

Genehmigungsvorschau

Weil die Genehmigung positionsbasiert abläuft, zeigt auch die Genehmigungsvorschau, welche Position von wem genehmigt werden soll.
Nach Anwahl der Genehmigungsvorschau erfolgt die Darstellung der einzelnen Genehmigungsschritte mit dem dazugehörigen Genehmigenden, nur werden für positionsbasierte Schritte nicht sofort alle Genehmigenden dargestellt. Erst nach erfolgter Anwahl des Genehmigungsschrittes werden die einzelnen Positionen mit den verantwortlichen Genehmigenden im Detail dargestellt.
Die Änderung eines Genehmigenden erfolgt durch Kennzeichnen der jeweiligen Position plus dem Link Genehmigenden ändern wie gewohnt. Beim Einfügen eines neuen Genehmigenden kann ausgewählt werden, für welche Position(en) er zuständig sein soll.

BAdI BBP_WFL_APPROV_BADI

Die Implementierung dieses BAdIs ist Voraussetzung für die Nutzung dieses Genehmigungsszenarios.
Die von SAP ausgelieferte Implementierung dient nur als Beispiel und muss vom Kunden unbedingt geändert werden.

Nähere Information zur positionsbasierten Genehmigung finden Sie im SAP-Hinweis 731637.

Auswirkungen auf den Datenbestand

Auswirkungen auf die Datenübernahme

Auswirkungen auf die Systemverwaltung

Auswirkungen auf das Customizing

• BBP_CHNG_AGNT_ALLOW
  ( Zulassen der Änderung von Genehmigenden)

• BBP_CHNG_AGNT_GET
  ( Benutzerauswahl bei Hinzufügen/ Ändern von Genehmigenden)

• BBP_WFL_APPROV_BADI
  (Ermittlung v. Genehmigenden für n-stufigen dynamischen Genehmigungsworkflow)

Weitere Informationen

rdisp/max_wprun_time - Maximum work process run time   ABAP Short Reference  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 15903 Date: 20240523 Time: 154458     sap01-206 ( 245 ms )