Kontakt

Ansicht
Dokumentation

Änderungen im SAP Business Workflow (Enterprise Buyer 4.0) ( RELNEBP_40_WORKFLOW )

Änderungen im SAP Business Workflow (Enterprise Buyer 4.0) ( RELNEBP_40_WORKFLOW )

CPI1466 during Backup   CL_GUI_FRONTEND_SERVICES - Frontend Services  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Kurztext

Änderungen im SAP Business Workflow (Enterprise Buyer 4.0)

Verwendung

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

  • WS14000030 - Einstufige Genehmigung beim Anlegen eines Lieferanten
  • WS14000043 - Workflow ohne Genehmigung beim Anlegen eines Lieferanten
  • WS14000044 - Vervollständigung des Einkaufswagens durch Einkäufer
  • WS14000045 - Löschen Position nach Anwendungsfehler
  • WS14000075 - Workflow ohne Genehmigung für Bestellung
  • WS14000086 - Workflow ohne Genehmigung für Kontrakt
  • WS14000088 - Einstufige Genehmigung Kontrakt
  • WS14000089 - Einstufige Genehmigung Bestellung
  • WS14000091 - Altertworkflow für eine externe Auktion
  • WS14000109 - Genehmigung Einkaufswagen n-stufig über Wertgrenze
  • WS14000133 - Genehmigung Einkaufswagen n-stufig (BAdI)
  • WS14000148 - Genehmigung Kontrakt n-stufig (BAdI)

  • WS14000032 - Subworkflow zum Mailversenden beim Anlegen eines Lieferanten
  • WS14000076 - Auf BUS2202-Ereignisse (Bestellung) während Genehmigung warten
  • WS14000077 - Bestellung nach Genehmigung/ Ablehnung aktualisieren
  • WS14000080 - Subworkflow zum Mailversenden bei Genehmigung einer Bestellung
  • WS14000083 - Subworkflow zum Mailversenden bei Genehmigung eines Kontrakts
  • WS14000084 - Kontrakt nach Genehmigung/ Ablehnung aktualisieren
  • WS14000085 - Auf BUS2000113-Ereignisse (Kontrakt) während Genehmigung warten
  • WS14000108 - Subworkflow zur Genehmigung Einkaufswagen n-stufig über Wertgrenze
  • WS14000134 - Subworkflow für n-stufige Genehmigung Einkaufswagen (BAdI)
  • WS14000147 - Subworkflow für n-stufige Genehmigung Kontrakt (BAdI)

WFL zum Anlegen/ Ändern von Kontrakt (CTR) und Bestellung (PO)

An freigegebenen CTRs (Status freigegeben) sowie an bestellten POs (Status bestellt) können in Enterprise Buyer (EBP) ab Release 4.0 Änderungen, z.B. Einfügen und/ oder Löschen von Positionen, vorgenommen werden.
(Siehe Release-Information: Versionen von Einkaufsbelegen)

Diese Änderungen werden in Änderungsversionen der Originalbelege gespeichert, durchlaufen u.U. auch einen 0-stufigen Genehmigungsprozess, bevor die Änderungen, die sie enthalten, bei Genehmigung in den aktiven Beleg übernommen werden.

Der Änderungsworkflow startet durch Bestellen der Änderungsversion (Ereignis ChangeVersionSaved am Business-Objekt BUS2000113[CRT] bzw. am BUS2201[PO]). Durch erneutes Ändern der Änderungsversion wird diese aus dem Genehmigungsprozess genommen.
Per Workitem gelangt der Genehmigende in den Versionsvergleich zwischen Änderungs- und Originalversion.
Er kann die Änderungen nur komplett genehmigen/ ablehnen - positionsweise ist dies nicht möglich. Änderungen an der Änderungsversion kann er nicht vornehmen.

Beim Genehmigen der Änderungsversion prüft das System, ob die Übernahme aller Änderungen in den aktiven Beleg möglich ist, ohne dass Inkonsistenzen zu Folgebelegen auftreten (z.B. könnte u.U. in einer PO die bestätigte Menge größer als die in Genehmigung befindliche sein). Im Fehlerfall wird dem Genehmigenden eine Fehlermeldung angezeigt - er kann die Änderungen dann nur noch ablehnen.

Lehnt der Genehmigende die Änderungen ab, erhält die Änderungsversion den Status gemerkt, woraufhin diese wieder geändert oder verworfen werden kann.

Je nach IMG-Einstellung (Empfänger von Benachrichtigungen festlegen) wird der letzte Bearbeiter der Änderungsversion und/ oder alle Genehmigende über die Genehmigung/ Ablehnung der Änderungen informiert.

Hinweis:
Die Workflow-Muster für die Änderungsworkflows von CTR und PO sind identisch mit denen für die Erstellungsworkflows [WS14000086(WFL ohne Genehmigung für CTR), WS14000088(Einstufige Genehmigung CTR), WS14000075(WFL ohne Genehmigung für PO), WS14000089(Einstufige Genehmigung PO)]. Unterschiedlich sind nur die Startbedingungen, die entweder durch das Ereignis Saved(Speichern der Originalversion) oder aber ChangeVersionSaved (Speichern der Änderungsversion) gezogen werden. Die Startbedingungen für den Änderungsworkflow allerdings werten spezifische Attribute aus, die nur im Änderungsfall sinnvoll zu verwenden sind (z.B. Differenz des aktuellen Gesamtwertes zum Originalund Liste der geänderten Felder).
(Das System erkennt anhand der Beleg-GUID aus dem Workitem, ob es sich um einen Originalbeleg oder um eine Änderungsversion handelt.)

Siehe auch Release-Information: Genehmigung von Änderungen an aktiven Einkaufsbelegen

Offline-Genehmigung für Bestätigung und Rechnung

Neben der Offline-Genehmigung für Einkaufswagen (siehe Release-Information Offline-Genehmigung (EBP 3.0A)) ist diese Funktionalität ab Enterprise Buyer 4.0 auch für zu genehmigende Belege des Typs Bestätigung und Rechnung verfügbar.
Die Funktionsweise entspricht der bereits integrierten Offline-Genehmigung für Einkaufswagen (Report RSWUWFMLEC). Als Erweiterung dazu werden die Entscheidungsbuttons Genehmigen bzw. Ablehnen aber nur nach erfolgreicher Prüfung der Belege auf Vollständigkeit hin in der E-Mail eingeblendet. (Bei Unvollständigkeit hat der Genehmigende nur die Möglichkeit, über den Link ins EBP-System zu springen und die Belege online zu genehmigen/ abzulehnen.)

Vervollständigungsworkflow (Einkäufer-Workflow)

Über die Startbedingungen können Sie ab Enterprise Buyer 4.0 das Scenario für den Vervollständigungsworkflow einbinden:

Gibt ein Mitarbeiter einen unvollständigen Einkaufswagen (SC) (durch Bestellen) frei, wird nicht sofort ein entsprechender Genehmigungsworkflow gestartet. Statt dessen wird anhand von Attributen des Business Objektes Einkaufswagen (BUS2121) geprüft, ob der SC vor der Genehmigung per Workflow zur Vervollständigung an den zuständigen Operativen Einkäufer* geschickt werden soll. Ist dies der Fall, vervollständigt dieser den SC und gibt ihn anschließend wieder frei. (Falls nicht, geht der SC in die Genehmigung.)
Daraufhin wird der SC erneut dem ursprünglichen Mitarbeiter zugestellt, wobei ihm die vom Einkäufer vorgenommen Änderungen (gelöschte, ersetzte oder geänderte Positionen) explizit angezeigt werden - eine erneute Bearbeitung des SC kann wieder vorgenommen werden. Nur bei Vollständigkeit geht der SC dann nach Bestellen in den Genehmigungsprozess bzw. bei Unvollständigkeit erneut an den Einkäufer. (Evtl. mehrfacher schleifenförmiger Durchlauf.)
Die neuen Attribute (die in den Startbedingungen ausgewertet werden) sind:

  • ExistFreeTextLineItem - Existiert eine Position aus einer freien Eingabe
    (Enthält der SC eine Position mit Freitext-Eingabe, ist einer Position also kein Produkt zugeordnet?)

  • ExistNoPriceLineItem - Existiert eine Position ohne Preis
    (Konnte für eine Position kein Preis ermittelt werden?)

  • ExistNoVendorLineItem - Existiert eine Position ohne Lieferant
    (Konnte für eine Position kein Lieferant ermittelt werden?)

Soll dieser Workflow genutzt werden, ist das Workflow-MusterWS14000044 zu aktivieren; die Attribute können wie in den Voreinstellungen implementiert oder je nach Bedarf in den Startbedingungen als Prüfkriterien verwendet werden.

* Alle Operativen Einkäufer der zugehörigen Einkäufergruppe des SC erhalten ein Workitem. Nachdem der erste Einkäufer den SC freigegeben hat, werden auch die Workitems aus den Eingängen (Genehmigung) der anderen Einkäufer dieser Einkäufergruppe entfernt.

Open Partner Interface (OPI)-Workflow

Per OPI werden Geschäftpartnerdaten aus externen Quellen übernommen.
(Siehe auch: Release-Information Open Partner Interface)

Wird ein Geschäftspartner (Lieferant) via OPI generiert, wird am Business-Objekt BUS1006200 (Geschäftspartner BBP) das Ereignis BusinessPartnerBBP.Create ausgelöst, woraufhin ein Genehmigungsworkflow startet.
Je nach Transaktionsberechtigung (Geschäftspartner verwalten [BBPMAININT]) des zuständigen Einkäufers wird entweder ein einstufiger (WS14000030) oder ein Genehmigungsworkflow ohne Genehmigung (WS14000043) ausgeführt.

Anmerkung:
Diese Genehmigungsworkflows werden nicht durch Startbedingungen ausgelöst!
WS14000030 wird durch das Ereignis ToBeReleased (Zur Genehmigung vorsehen) ausgelöst - der Anleger ist nicht ausreichend berechtigt, den Lieferanten zu vervollständigen.
WS14000043 wird durch das Ereignis Completed (Geschäftspartner wurde fertiggestellt) ausgelöst - der Anleger hat die Berechtigung, den Geschäftspartner vollständig anzulegen.

  • Nullstufiger Genehmigungsworkflow
  • Der Genehmigungsstatus des Lieferanten wird auf freigegebengesetzt.

  • Ein Benachrichtigungsworkflow (Genehmigung des Lieferanten) informiert die unter IMG-Aktivität Empfänger von Benachrichtigungen festlegen (Szenario: Lieferant genehmigen) festgelegten Empfänger (Benutzerrollen: Initiator, Genehmiger, Einkäufer der Einkaufsorganisation) über die Genehmigung.

  • Einstufiger Genehmigungsworkflow
  • Der Manager der betroffenen Einkaufsorganisation wird via Organisationsmodell als Standard-Genehmigender bestimmt.

  • Der/ die Genehmigende/n erhält/ erhalten ein Workitem mit Absprung zur Geschäftspartnerpflege des zu genehmigenden Lieferanten.

  • Wird der Lieferant abgelehnt, erhält er den Status abgelehnt, wird als Geschäftspartner gelöscht und ein Benachrichtigungsworkflow (Ablehung des Lieferanten) informiert die unter IMG-Aktivität Empfänger von Benachrichtigungen festlegen (Szenario: Lieferant genehmigen) festgelegten Empfänger (Benutzerrollen: Initiator, Genehmiger, Einkäufer der Einkaufsorganisation) über die Ablehnung.

  • Wird der Lieferant genehmigt, erhält er den Status freigegebenund ein Benachrichtigungsworkflow (Genehmigung des Lieferanten) informiert die unter IMG-Aktivität Empfänger von Benachrichtigungen festlegen (Szenario: Lieferant genehmigen) festgelegten Empfänger (Benutzerrollen: Initiator, Genehmiger, Einkäufer der Einkaufsorganisation) über die Genehmigung.

Admin-Workflow für Sammelrechnung

Ab Enterprise Buyer 4.0 können sogenannte Sammelrechnungen, also Rechnungen mit Bezug zu mehreren Bestellungen, angelegt werden (Siehe hiezu: Release-Information Sammelrechnung).

Gelangt eine solche Sammelrechnung in die Genehmigung, wird geprüft, ob die einzelnen Positionen von verschiedenen Anforderern stammen.
Falls ja, wird der Administrator als Genehmigender ermittelt. *
Falls alle Positionen von einem Anforderer stammen, erfolgt die Genehmigung standardmäßig je nach Customizing-Einstellungen (bspw. genehmigt der Anforderer selbst bei einstufiger Genehmigung).

*,,Die Ermittlung des Genehmigenden erfolgt entweder über das BAdI
,,BBP_WFL_ADMIN_APPROV ( Ermittlung des [Administrator-]Genehmigenden)
,,oder aber via Standardaufgabe TS10407925.

Einkaufsbudget-Workflow

Dieses Workflow-gesteuerte Scenario findet dann Verwendung, wenn die Genehmigung von Einkaufswagen (SC) nicht über den Wert das aktuell zu bestellenden Einkaufswagens erfolgen soll, sondern durch Über- bzw. Unterschreiten eines Budgets, welches einem Mitarbeiter zum Einkaufen im Enterprise Buyer zur Verfügung stehen kann.

Anmerkung:
Dieses Budget wird im Enterprise Buyer-System festgelegt und entspricht nicht dem Budgets aus dem FI-CO!

Das Einkaufsbudget wird bei jedem Einkauf mit der bis dato in der laufenden Periode angefallenen Gesamtsumme aller Einkäufe (AmountSpent) verglichen. (In der Datenbanktabelle BBP_USRBDGT werden im Feld AmountSpent alle SC-Werte eines Benutzers summiert fortgeschrieben.)

Das Einkaufsbudget

  • kann benutzerbezogen sein (für jeden Benutzer wird ein Budget festgelegt),
  • ist für eine bestimmte Periode gültig (monatlich, quartalsweit, jährlich) und
  • wird periodisch erneuert (nach Ablauf einer Periode werden die Budgetbelastungen zurückgesetzt, d.h., dass der Wert für AmountSpent beim ersten Einkauf in der neuen Periode initialisiert wird).

Das Einkaufsbudget kann an verschiedenen Objekten im System hinterlegt werden und wird in der Priorität absteigendvom System erkannt:

  1. Benutzer
    In der Benutzerpflege (Transaktion SU01) wird im Register Personalisierungder Betrag, den ein Mitarbeiter zur Verfügung hat am Personalisierungsobjekt BBP_USER_BUDGET hinterlegt.
    Dieser Eintrag besitzt die höchste Priorität.
  2. Rolle
    In der Rollenpflege (Transaktion PFCG) kann wie in der Benutzerpflege das Einkaufsbudget mit nachgestellter Priorität hinterlegt werden.
  3. Organisationsmanagement
    (Transaktion PPOMA_BBP)
    An dieser Stelle kann das Einkaufsbudget einer Struktur (mit dem Vorteil der Vererbung auf die untergeordneten Strukturknoten) zugewiesen werden.
    Dieser Eintrag besitzt die gleiche Priorität wie der in der Rollenpflege.
Sind für Rolleund für die Organisationseinheit Einkaufsbudgets definiert und ist ein Mitarbeit beiden zugeordnet, so ist das jeweils höchste ausschlaggebend. (Beide werden ignoriert, wenn dem Benutzer ein Budget zugeordnet ist.)

Ablauf
Beim Speichern eines SC wird das benutzerbezogene Einkaufsbudget überprüft.
Ist der Betrag von AmountSpent größer als der Wert des Einkaufsbudgets, erscheint ein Dialogfenster, was auf die überschrittene Differenz und eine nachfolgende Genehmigung hinweist.
Der Benutzer kann einerseits bestätigen (OK), wodurch AmountSpent fortgeschrieben und ein einstufiger Genehmigungsworkflow gestartet wird.
Lehnt der Benutzer andererseits ab (Cancel), gelangt er in die Bearbeitung das aktuellen SC zurück und kann ggf. den Einkaufswagenwert verringern.
Ist der Betrag von AmountSpent kleiner als der Wert des Einkaufsbudgets, startet ein Workflow ohne Genehmigungund der SC erhält den Status genehmigt.

Aktualisierung von AmountSpent
Der Wert des Datenbank-Feldes AmountSpent wird aktualisiert, wenn:
  • der SC bestellt wird,
  • der Mitarbeiter löscht oder ändert und
  • der Manager den SC bzw. einzelne Positionen ablehnt.

Eigene Methode zur Bestimmung des SC-Wertes

Mit dem BAdI BBP_SC_VALUE_GET steht Ihnen eine Methode zur Verfügung, die eine eigene Bestimmung des SC-Wertes zur Fortschreibung von AmountSpent erlaubt.
Siehe: BAdI-Dokumentation Ermittlung des Einkaufswagenswertes für Benutzerbudget

Workfloweinstellungen für die stochastische Belegprüfung

Die stochastische Belegprüfung für Rechnung (IV) und Bestätigung (CF) in Enterprise Buyer 4.0 bietet ein hohes Maß an Flexibilität bzgl. der Verwendung unterschiedlicher Genehmigungsworkflows in Abhängigkeit vom Typ des zu prüfenden Beleges, dessen Ausprägung (Subtyp) und vom Beleg-Bruttowert.

Grundsätzlich übersteuern die Einträge in der Customizing-Tabelle der IMG-Aktivität Stochastische Prüfung von Dokumenten festlegen die in den Wokflow-Startbedingungen getroffenen Einstellungen. (Nähere Informationen dazu finden Sie in der Dokumentation zur IMG-Aktivität Supplier Relationship Management → SRM Server → Anwendungsübergreifende Grundeinstellungen → SAP Business Workflow → Stochastische Prüfung von Dokumenten festlegen.)
Diese Einträge ermitteln für jeden spezifischen Fall eine stochastische Wahrscheinlichkeit, mit welcher der in den Startbedingungen ermittelte Workflow durch einen alternativen ersetzt wird.

Wiederum übersteuert werden können diese Resultate durch die vom BAdI BBP_STOCH_CUST_BADI ermittelten. (Siehe hierzu die BAdI-Dokumentation Workflowsteuerung für stochastische Dokumentenprüfung.)

Alertworkflow für externe Ausschreibungen (SAP Bidding Engine)

Mittels der SAP-Bidding Enginehat der Initiator einer Ausschreibung die Möglichkeit, diese Ausschreibung an externe Auktionstools weiterzuleiten, wo sie als Auktion weiterverarbeitet wird.
Beim Versenden startet dieser Alertworkflow und wartet "standby" auf eine Rückmeldung des externen Auktionstools und informiert den letzten Bearbeiter auf Bidding Engine-Seite (i.d.R. ist dies der Initiator) dem Ergebnis der Ausschreibung entsprechend.

Der Workflow (WS14000091) startet, wenn das Ereignis BidInvitationEC.ExternalAuctionStarted (Externe Auktion wurde gestartet) am Business-Objekttyp BUS2200 (Ausschreibung EC) ausgelöst wurde.

Drei Ereignisse führen zum Benachrichtigen des Initiators:
  1. Die Frist der Auktion ist abgelaufen -TS14007971(Externe Auktion abgelaufen)
    Der Initiator wird per Mail (im Enterprise Buyer-Eingang) informiert, dass die Auktion erfolglos ausgelaufen ist.
    (BOR-Ereignis: BidInvitationEC.ExternalAuctionCompleted)
  2. Endergebnis der Auktion ist eingetroffen -TS14007973(Externe Auktion erfolgreich)
    Der Initiator wird per Mail informiert, dass die Auktion erfolgreich verlief.
    (BOR-Ereignis: BidInvitationEC.ExternalAuctionCompleted)
  3. Fehlermeldung von externem Auktionstool -TS14007972(Ext. Auktion: Fehlerfall)
    Der Initiator wird per Mail informiert, dass die Auktion fehlerhaft verlief; die Fehlermeldung wird ausgegeben.
    (BOR-Ereignis: BidInvitationEC.ExternalAuctionError)

Auswirkungen auf den Datenbestand

Auswirkungen auf die Datenübernahme

Auswirkungen auf die Systemverwaltung

Auswirkungen auf das Customizing

Weitere Informationen






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

Length: 27195 Date: 20240523 Time: 151723     sap01-206 ( 350 ms )