Ansicht
Dokumentation

Änderung im SAP Business Workflow ( RELNEBP_55_WORKFLOW )

TXBHW - Original Tax Base Amount in Local Currency   General Material Data  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Kurztext

Änderung im SAP Business Workflow

Verwendung

Back & forth-Bearbeitung im n-stufigen dynamischen Genehmigungs-Workflow für Kontrakte

Wie für den n-stufigen Genehmigungs-Workflows für Bestellungen (WS14000145) ist nun auch für den n-stufigen Genehmigungs-Workflow für Kontrakte (WS14000148) back & forth-Bearbeitung möglich. Das heißt, dass der Genehmigende während der Genehmigung die Möglichkeit hat, den Kontrakt (per Drucktaste Zurück an Einkäufer) mit der Aufforderung zur Änderung an den Anleger zurückzuschicken. Nach erfolgter Änderung kann dieser den Kontrakt wieder (per Drucktaste Zurück an Manager) zum aktuellen Genehmigenden zurückleiten, wo die Genehmigung ohne Neustart des Workflows fortgeführt wird.

Die Berechtigungen zum Zurücksenden und zum Vornehmen von Belegänderungen für den Genehmigenden und den Anleger werden wie bei den bereits bekannten n-stufigen Workflows über die Ausprägungen des Personalisierungsobjektes BBP_WFL_SECURITY bestimmt.
(Siehe hierzu im Knowledge Warehouse: mySAP Supplier Relationship Management-> Architektur und Technologie-> Administration-> SRM Business Workflow-> Genehmigungs-Workflows für Belege und Objekte-> Workflows für Bestellungen-> Genehmigungs-Workflows für Bestellung und Änderungsversion-> Autorisation)

Neue Funktion Zurücklegen für back & forth-Bearbeitung

Die neue Funktion/ Drucktaste Zurücklegen für alle back & forth-fähigen Genehmigungs-Workflows bewirkt ein "Zwischenspeichern" des in Genehmigung befindlichen Beleges durch den Genehmigenden zur späteren Weiterbearbeitung. Das Workitem verbleibt dabei im Eingang des Genehmigenden. Die vorgenommenen Änderungen werden im Beleg gespeichert. Das Zwischenspeichern bewirkt keine Statusänderung des Beleges - der Beleg wird nicht gesperrt.
(Werden zwischengespeicherte Belege z.B. vom Einkäufer geändert, so startet der Workflow-Prozess neu.)

Hinweis:

Im Gegensatz zum Merken während der Änderung von in Genehmigung befindlichen Belegen durch den Einkäufer wird der Workflow-Prozess beim Zurücklegen nicht unterbrochen - der Beleg verbleibt in der Genehmigung.

Neue Genehmigungs-Workflows für Ausschreibung

Vor dem Veröffentlichen von Ausschreibungen (BUS2200) und Änderungsversionen von Ausschreibungen, können drei Genehmigungs-Workflows genutzt werden, die durch Auswertung der Startbedingungen nach dem Speichern der Belege gestartet werden:

• Ohne Genehmigung: WS14500026

• 1-stufige Genehmigung: WS14500027
  (Manager der EkOrg genehmigt)

• n-stufige Genehmigung mit BAdI inklusive back & forth-Bearbeitung: WS14500028
  (setzt die Implementierung des BAdIs BBP_WFL_APPROV_BADI voraus, anderenfalls wird der Manager der Einkaufsorganisation als Genehmigender ermittelt)

Genehmigungs-Workflows für Kontrakte und Angebote unterstützen Hinzufügen/ Entfernen von Genehmigenden/ Reviewern

Die Genehmigungs-Workflows für Kontrakte (WS14000086 [ohne Genehmigung]), (WS14000088 [1-stufige Genehmigung]) und WS14000148 [n-stufige Genehmigung]) unterstützen ab sofort das Hinzufügen/ Entfernen von Genehmigenden/ Reviewern während der Genehmigungsvorschau.

Dies gilt ebenso für den 1-stufigen Genehmigungs-Workflow für akzeptierte Angebote (Angebote, die den Zuschlag erhalten haben), WS79000002.

Neuer n-stufiger Genehmigungs-Workflows für Angebote

Für Angebote (BUS2202) gibt es ab sofort einen n-stufigen Genehmigungs-Workflows, der durch Auswertung der Startbedingungen nach dem Akzeptieren (Zuschlagen) von Angeboten gestartet werden kann:

N-stufige Genehmigung mit BAdI inklusive back & forth-Bearbeitung: WS14500044
(setzt die Implementierung des BAdIs BBP_WFL_APPROV_BADI voraus, anderenfalls wird der Manager der Einkaufsorganisation als Genehmigender ermittelt)

Überwachungs-Workflow für Ausschreibungen

Ist die Abgabefrist einer veröffentlichten Ausschreibung abgelaufen, bekommt deren Anleger eine Benachrichtigung per E-Mail, die ihn darauf hinweist. Dies gilt ebenso für veröffentlichte Änderungsversionen von Ausschreibungen.

Der zugrunde liegende Workflow (WS14500035) wird direkt beim Veröffentlichen der Ausschreibung bzw. einer Änderungsversion gestartet (also wenn ein SRM-Beleg von Business-Objekt BUS2200den Status veröffentlichterhält).
Wird eine Ausschreibung vor Ablauf der Abgabefrist geschlossen (Status abgeschlossen), so wird vom System das Ereignis BidInvMonitoringEndausgelöst, was diesen Workflow beendet und somit sicherstellt, dass zu dieser abgebrochenen Ausschreibungen keine Benachrichtigung erfolgt.
Dasselbe gilt auch, wenn inzwischen eine veröffentlichte Änderungsversion zur Ausschreibung existiert. In diesem Falle wird der gestartete Überwachungs-Workflow ebenfalls beendet.

Generischer Alert-Workflow für das Einhalten der Genehmigungs-Deadline

Dieser Workflow (WS14500051) dient dem Auslösen von Alerts und/oder Nachrichten (je nach Customizing im SRM Alert Management) durch das Alert-Ereignis APPROVAL_NOT_PROCESSED.
Haben Sie dieses Alert-Ereignis durch Angabe einer Ereignisfrist aktiviert (siehe IMG-Aktivität Ereignisschema definieren), wird dieser Workflow mit dem Generieren von Genehmigungs-Workitems zum jeweiligen Objekttyp gestartet und überwacht die Einhaltung der angegebenen Ereignisfrist. Bei fristgerechter Bearbeitung des Workitems wird der Workflow beendet, ansonsten löst er einen Alert bzw. eine Benachrichtigung aus.

Erweiterung der Funktionalität zur Offline-Genehmigung

Siehe hierzu die Release-Information Erweiterung der Funktionalität zur Offline-Genehmigung (geändert).

Digital signierte Version des Java-Applets zur Genehmigungsvorschau und Anzeige der Beleghistorie

Ab SRM 5.0 steht für die Funktionen Genehmigungsvorschau und Folgebelege (Beleghistorie) neben der bisher bereits verwendeten nicht signierten zusätzlich auch eine digital signierte Version des Java-Applets zur Verfügung.
Die digitale Signatur bestätigt lediglich, dass dieses Applet tatsächlich von SAP stammt - einen funktionalen Unterschied gibt es nicht. Der Benutzer muss jedoch vor dem Ausführen auf einem Popup bestätigen (Akzeptieren), dass er das (von SAP stammende) Applet ausführen möchte. Über die Drucktaste Immer akzeptieren kann die wiederkehrende Anzeige des Popups allerdings abgestellt werden.

Per Customizing können Sie festlegen, welche Applet-Version ausgeführt werden soll. Siehe dazu auch im IMG: Supplier Relationship Management → SRM Server → Anwendungsübergreifende Grundeinstellungen → SAP Business Workflow → Signiertes Java-Applet für Genehmigungsvorschau u. Beleghistorie

Auswirkungen auf den Datenbestand

Auswirkungen auf die Datenübernahme

Auswirkungen auf die Systemverwaltung

Auswirkungen auf das Customizing

Um die n-stufigen Workflows nutzen zu können, muss der BAdI BBP_WFL_APPROV_BADI implementiert sein:
IMG: Supplier Relationship Management -> SRM Server -> Business Add-Ins (BAdIs) -> SAP Business Workflow ->
Ermittlung v. Genehmigenden für n-stufigen dynamischen Genehmigungsworkflow

Neues BAdI BBP_OFFLINE_APP_BADI für Offline-Genehmigung:
IMG: Supplier Relationship Management -> SRM Server -> Business Add-Ins (BAdIs) -> SAP Business Workflow -> Kundenspezifische Anpassung der Offline-Genehmigung

Weitere Informationen

PERFORM Short Reference   BAL_S_LOG - Application Log: Log header data  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 11320 Date: 20240606 Time: 040518     sap01-206 ( 171 ms )