Ansicht
Dokumentation

CRM_SRV_MI_DOCU - Beschreibung manueller Belegprüfungen

CPI1466 during Backup   BAL Application Log Documentation  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Durch die automatische Ausführung von Geschäftsregeln (AAG) ist es möglich Positionen in Reklamationen, Retouren und Gebrauchtteilretouren, wie z.B. vom Kunden angelegte Rechnungskorrekturanforderungen oder Retourenanforderungen ohne manuelle Eingriffe automatisch zu genehmigen oder abzulehnen.

Ist die Sachlage anhand definierter Kriterien (z.B. Positionstyp, Produkt, Wert, Kundenstatus) nicht eindeutig oder soll für definierte Kriterien keine automatische Entscheidung erfolgen, wird die Position in den Workflow der manuellen Belegprüfung (MB) überführt, um dort von Mitarbeitern bearbeitet und am Ende manuell genehmigt oder abgelehnt zu werden.

Zum Starten der MB muss der Systemstatus I2212 Manuelle Prüfung erforderlich aktiviert werden.
Dieser Status startet den Workflow der MB. Das bedeutet, dass Workitems für bestimmte Mitarbeiter erzeugt werden. Beim Ausführen der Workitems startet die Bearbeitungstransaktion der MB. Diese Transaktion ermöglicht dem Mitarbeiter alle relevanten Belegdaten einzusehen und die erforderliche Statusentscheidung zu treffen.

Die ABAP-Klasse CL_CRM_MI_TOOLS stellt Methoden zur Verfügung, mit denen eine automatische Ablehnung oder Genehmigung oder das Anstoßen des Workflows der MB durchgeführt wird.

Lebenszyklusstatus und neue Systemstatus für die MB

Am Ende des Genehmigungsprozesses wird einer der folgenden Lebenszyklusstatus gesetzt:

• I1004 - Freigegeben
  Dieser Status wird gesetzt wenn der Kundenforderung automatisch oder manuell stattgegeben wird. Dadurch werden Folgeprozesse angestoßen, an wie z.B. das Anlegen einer Retourengenehmigung oder Gutschrift.

• I1005 - Erledigt
  Dieser Status wird gesetzt, wenn die Kundenforderung endgültig abgelehnt wird. Es werden keine Folgeprozesse angestoßen.
  Der AAG steht dieser Status nicht zur Verfügung. Er wird entweder durch den Kunden gesetzt, wenn dieser die Ablehnung einer Position akzeptiert, oder durch einen Mitarbeiter innerhalb der MB. Dort steht er allerdings erst nach einer wiederholten Wiedervorlage zur Verfügung.

Zusätzlich zu den Lebenszyklusstatus der Standardauslieferung gibt es weitere Systemstatus, die Aufschluss darüber geben, wo sich eine Position im Prozess von AAG und MB befindet, bzw. wie sie in diesem Prozess entschieden wurde:

• I2216 - Manuell genehmigt
  I2218 - Automatisch genehmigt

Beim Setzen dieser beiden Status wird zusätzlich der Lebenszyklusstatus Freigegeben gesetzt. Der Lebenszyklusstatus stößt die Folgeprozesse wie z.B. Anlegen der Retourengenehmigungsposition oder der Rechnungskorrekturposition an. Nach einer automatischen oder manuellen Genehmigung ist der Prozess der AAG und MB beendet.

• I2211 - Manuell abgelehnt
  I2214 - Automatisch abgelehnt

Beim Setzen dieser beiden Status wird nicht der zusätzlicher Lebenszyklusstatus Erledigtgesetzt, damit der Kunde die Möglichkeit hat, der Ablehnung in Form einer Wiedervorlage der Position zu widersprechen. Der Prozess der AAG und MB ist also noch nicht beendet.

• I2213 - Wiedervorlage
  I2215 - Wiedervorgelegt

Wird eine Ablehnung vom Kunden nicht akzeptiert, kann er eine Wiedervorlage starten. Durch die Wiedervorlage wird die Position - gegebenenfalls mit geänderten Daten (z.B. Mengen) - wieder in den Verarbeitungsprozess eingestellt. Das Ergebnis ist eine weitere Statusentscheidung.

Wenn der Kunde die Wiedervorlage startet, ändert das System den Status von Manuell abgelehntoder Automatisch abgelehnt auf Wiedervorlage, bis die erforderliche Statusentscheidung getroffen wird.

Nach der Statusentscheidung wird der Status Wiedervorlage durch den Status Wiedervorgelegt ersetzt. Wiedervorgelegt wird danach nicht wieder zurückgenommen sondern bleibt bis zum Ende des Gesamtprozesses aktiv, damit man erkennt, ob es sich um die erste oder schon um eine wiederholte Wiedervorlage der Position handelt.

• I2217 - Manuelle Prüfung aktiv

Dieser Status wird gesetzt, sobald zu einer Position ein Workflow-Item für die MB angelegt wird.

Er kann genutzt werden, um bestimmte Aktionen oder automatische Regeln zu blockieren, die bei laufender MB nicht ausgeführt werden dürfen (z.B. Anstoßen der MB, Identifizierung von verantwortlichen Bearbeitern im Workflow).
Dieser Status wird gelöscht, sobald in der MB eine Statusentscheidung getroffen wurde.

Der Workflow der MB

Der Prüfungs- und Entscheidungsprozess der MB wird über einen SAP Business Workflow abgebildet.

Innerhalb dieses Prozesses kann die Position drei unterschiedlichen Ebenen von Bearbeitern vorgelegt werden, die über jeweils eigene Zuständigkeiten verfügen:

• Beurteilung:

Diese Bearbeitungsebene ist obligatorisch. Der Mitarbeiter dieser Ebene ist der Hauptverantwortliche im Prozess. Er schließt seine Bearbeitung mit einer Statusentscheidung für die Position ab.
Falls er diese Entscheidung aufgrund einer unvollständigen Informationslage nicht sofort treffen kann, kann er die Position an Bearbeiter der Ebene Klärung schicken. Von dort erhält er die Position, mit den angeforderten Informationen, zurück und kann eine abschließende Entscheidung treffen.

• Klärung:

Diese Bearbeitungsebene ist optional. Mitarbeiter dieser Ebene können durch den Beurteilenden beauftragt werden, Informationen zu beschaffen, der Beurteilende kann aber auch eine Entscheidung treffen ohne zuvor die Klärung zu befragen.
Mitarbeiter der Ebene Klärung können keine Statusentscheidungen treffen. Zwar trifft auch der Klärende zum Abschluss seiner Bearbeitung eine Entscheidung. Diese verändert jedoch nicht den Systemstatus der Position. Sie ist als Vorschlag anzusehen, wie die Statusentscheidung des Beurteilenden aus Sicht der Klärung ausfallen sollte.

Da auf Ebene der Klärung keine Statusentscheidung getroffen werden kann, geht die Position nach Abschluss der Klärung immer an die Beurteilung zurück.

• Genehmigung:

Diese Bearbeitungsebene ist optional. Mitarbeiter dieser Ebene werden hinzugezogen, wenn die Entscheidung des Beurteilenden nach dem Vier-Augen-Prinzip überprüft werden soll.
Dies kann zum Beispiel der Fall sein, wenn der Wert der Position einen bestimmten Betrag überschreitet oder es sich um eine besonders sensible Geschäftspartnerbeziehung handelt.
Dabei ist es durchaus möglich, dass der Genehmigende sich anders als sein Vorgänger entscheidet.
Die Funktion Klärende hinzuziehensteht der Genehmigung nicht zur Verfügung, weil davon ausgegangen wird, dass mit der Entscheidung des Beurteilenden auch der betriebswirtschaftliche Klärungsprozess abgeschlossen ist.
Die Konfigurationsmöglichkeiten der MB lassen es auch zu, die Entscheidung eines Mitarbeiters der Ebene Genehmigung durch einen weiteren Mitarbeiter derselben Ebene überprüfen zu lassen.

Bearbeiterfindung im Workflow der MB

Der Zweck der Bearbeiterfindung ist es, Empfänger für die Workitems zu ermitteln. Im Workflow der MB findet die Bearbeiterfindung über die Ausführung einer Regelstatt. Die Regel ist vom Typ Bearbeiterfindung: Auszuführende Funktion.Über den an der Geschäftsregel hängenden Funktionsbaustein CRM_MIWF_AD_BADI wird das BAdI CRM_MI_PROC_DET aufgerufen, in dem Sie eigene Logik zur Ermittlung der Empfänger implementieren können. Ausgangspunkt der Bearbeiterfindung ist die Bearbeitergruppe.

Bearbeitergruppen

Eine Bearbeitergruppe beschreibt einen Personenkreis, der eine genau umrissene Verantwortlichkeit im Prozess der MB hat. Sie können innerhalb der zuvor beschriebenen Bearbeitungsebenen eine oder mehrere Bearbeitergruppen definieren. Die Definition mehrer Bearbeitergruppen auf der selben Ebene ist sinnvoll, wenn jede Gruppe für die Bearbeitung unterschiedlicher Problemstellungen eingesetzt wird.

Festlegung der zuständigen Bearbeitergruppe für die Bearbeiterfindung

Die Logik der Bearbeiterfindung benötigt als Eingangsparameter eine konkrete Bearbeitergruppe. Innerhalb dieser Gruppe werden die in Frage kommenden Empfänger der Workitems ermittelt. Die Bearbeitergruppe muss demnach schon bekannt sein, bevor die eigentliche Bearbeiterfindung diejenigen Personen innerhalb dieser Gruppe ermittelt, denen das Workitem zugestellt wird.

Das Festlegen der zuständigen Bearbeitergruppe erfolgt in Abhängigkeit von der Bearbeitungsebene unterschiedlich:

• Beurteilung

Die Bearbeitergruppe der Ebene Beurteilung wird dem Workflow schon von außen übergeben, d.h. sie muss schon vor dem Anstoßen der MB ermittelt werden.

Dies geschieht durch die AAG, da diese auch die Problemstellung kennt, die zum Aufruf der manuellen Prüfung führt.

• Klärung

Die Ebene Klärung wird durch den Beurteilenden aufgerufen; die empfangenden Bearbeitergruppen werden durch den Beurteilenden manuell festgelegt.

In der Klärungsebene können mehrere unterschiedliche Bearbeitergruppen gleichzeitig angesprochen werden. In der Bearbeitungstransaktion gibt es eine Tabelle, in der der Beurteilende angeben kann welche Bearbeitergruppen als Klärende hinzugezogen werden sollen.

• Genehmigung

Im Gegensatz zu den Ebenen Klärung und Beurteilung kann die zuständige Bearbeitergruppe der Ebene Genehmigung nicht durch die AAG oder den Beurteilenden vorab festgelegt werden. Sie muss im Bedarfsfall dynamisch ermittelt werden

Hierfür wird das BAdI CRM_MI_APPROVER aufgerufen, das zwei Funktionen hat:

• Es muss die soeben erfolgte Statusentscheidung anhand von z.B. Positionsdaten, Benutzerkennung, der Entscheidungsfunktion selbst, usw. auswerten und dann feststellen ob eine Genehmigung der Entscheidung erforderlich ist.

• Wenn eine Genehmigung erforderlich ist, muss das BAdI festlegen, welche Bearbeitergruppe für diese Genehmigung verantwortlich ist.

Danach wird das Workitem für den Mitarbeiter der Ebene Genehmigung erzeugt, dessen Bearbeiterfindung anhand der nunmehr bekannten Bearbeitergruppe die Empfänger bestimmen kann.

Innerhalb der Logik des BAdI wäre es beispielsweise denkbar, über entsprechende Auswertungswege des Organisationsmanagements den Vorgesetzten des ausführenden Benutzers Beurteilungzu ermitteln. Alternativ wäre es möglich eine kundeneigene Genehmigungs-Hierarchie einzurichten und hier auszuwerten.

Ermittlung der Workitem-Empfänger innerhalb der zuständigen Bearbeitergruppe

Zur Ermittlung der Workitem-Empfänger steht Ihnen ein BAdI zur Verfügung. Lesen Sie hierzu die Dokumentation zu den BAdIs im Knoten Business Add-Ins für Bearbeiterfindung im Workflow.

In allen Workitems zum Workflow der MB (Workflow-Kennung: WS15100038, enthalten im Paket CRM_MI_WF) wird die Empfängerermittlung auf gleiche Art und Weise durchgeführt: Dem Workiflow-Schritt ist eine Standardregel vom Typ Bearbeiterfindung: Auszuführende Funktion zugeordnet.
Für die Ebenen Beurteilung und Klärung ist dies die Regel AC15100147 mit den Containerelementen GUID der CRM-Geschäftsvorgangsposition und Ausführende Bearbeitergruppe.
Für die Ebene Klärung ist es die Regel AC15100146, die ein weiteres Containerelement, nämlich Workitem-Empfänger, Ebene 1 (Klärung) enthält.

Der auszuführende Funktionsbaustein ist in allen Fällen der Baustein CRM_MI_AD_BADI. Dieser ermittelt lediglich, welcher Bearbeitungsebene die zuständige Bearbeitergruppe angehört, und verwendet dann die gefundene Bearbeitungsebene als Filterwert für den Aufruf des BAdI CRM_MI_PROC_DET. Dieses bekommt den Aufgabencontainer als Import-Parameter durchgereicht und kann dessen Inhalt zum Ausführen der Ermittlungslogik nutzen:

• Anhand der Elemente GUID der CRM-Geschäftsvorgangsposition und Ausführende Bearbeitergruppe können alle Daten zum Beleg ermittelt werden.

• Anhand des Elementes Ausführende Bearbeitergruppe kann eine Auswahl von Benutzern ermittelt werden die das Workitem erhalten sollen.

• Auf Ebene Klärung kann zusätzlich auch die Tabelle Workitem-Empfänger, Ebene 1 (Klärung) ausgewertet werden, in der der Beurteilende schon vorab festlegen kann, welche konkreten Benutzer er innerhalb einer bestimmten Bearbeitergruppe ansprechen möchte.

Zuordnung von Personen zu Bearbeitergruppen

Da der Business Workflow darauf abgestimmt ist, mit Daten und Einstellungen des Organisationsmanagements zu operieren, bietet es sich an, die Zuordnung von Personen zu Bearbeitergruppen über das Organisationsmanagement vorzunehmen. Verwenden Sie hierfür die IMG-Aktivität Planstellen zu Bearbeitergruppen zuordnen.

Sie müssen jedoch das Organisationsmodell für die Zuordnung nicht zwingend nutzen, sondern können auch eine vollkommen kundeneigene Zuordnung schaffen.

Customizing-Aktivitäten der MB

Codes und Kataloge

Codes werden überwiegend als Platzhalter für bestimmte ständig wiederkehrende Texte eingesetzt, die ansonsten immer wieder neu geschrieben werden müssten. In der MB können sie auch eingesetzt werden um zu dokumentieren, dass eine bestimmte Bearbeitergruppe für die Bearbeitung einer Position zuständig ist.

Die unterschiedlichen Verwendungen der Codes sind in der MB durch den Codetyp gekennzeichnet:

• Identifizierung von verantwortlichen Bearbeitergruppen:

Beim Anstoßen der MB durch die AAG wird dem Workflow bereits die Information mitgegeben, welche Bearbeitergruppe für die Beurteilung zuständig sein soll. Dies geschieht mit einem Code vom Typ Identifizierung der Bearbeitergruppen.

• Dokumentierung einer Entscheidung:

Auch getroffene Entscheidungen wie die Ablehnung oder Genehmigung einer Position, sowie auch die Wiedervorlage durch den Kunden oder das Anstoßen der MB durch die AAG werden in Form von Codes festgehalten. In der Dialogtransaktion der MB ist ein Protokoll aller getroffenen Entscheidungen enthalten. Für Entscheidungscodes existieren die Codetypen

• Automatische Entscheidung

• Kundenentscheidung (Portal)

• Manuelle Entscheidung

• Ursache der manuellen Prüfung:

Mit Hilfe des Codetyps Ursache der Manuellen Prüfung wird dokumentiert, warum der Workflow der MB durch die AAG gestartet wurde.

• Grund der Ablehnung:

Abgelehnte Positionen werden dem Kunden im Portal angezeigt, wo er dann die Möglichkeit hat, sie entweder noch einmal vorzulegen oder aber die Ablehnung anzuerkennen. Zum Status Abgelehnt gehört in diesem Zusammenhang auch die Information warum die Position abgelehnt wurde. Auch der Ablehnungsgrund wird in Form eines Codes abgelegt. Da die Ablehnung entweder durch die AAG oder durch die MB erfolgen kann, gibt es hierfür die beiden Codetypen

• Grund der automatischen Ablehnung

• Grund der manuellen Ablehnung

Unter dem Knoten Codes und Kataloge schaffen Sie die Voraussetzungen dafür, dass Sie in der manuellen Belegprüfung Codes nutzen und zuordnen können: Sie legen Kataloge an, Sie legen Codegruppen und Codes an und fassen Codegruppen zu Codegruppenprofilen zusammen. Sie schaffen ein eigenes Sachverhaltsprofil für die MB und ordnen diesem die benötigten Codegruppenprofile zu. Schließlich registrieren Sie das Sachverhaltsprofil für die Nutzung in der MB und geben den Codegruppen, die Sie definiert haben, ihre eigentliche Bedeutung indem Sie sie den unterschiedlichen Codetypen zuweisen.

Einstellungen für Texte

IMG-Aktivität Textobjekte und Textarten festlegen

Über diese Aktivität definieren Sie die Textarten die sie in der MB verwenden möchten.

Die Texte werden im normalen Textspeicher der CRM-Geschäftsvorgangsposition abgelegt. Dies bedeutet, dass alle Textarten der MB unter dem Textobjekt CRM_ORDERI anzulegen sind.

Sie benötigen mindestens eine Textart unter der die Texte eingegeben werden und genau eine Textart die zum Anzeigen des Protokolls dient.

Um zu erreichen dass einmal eingegebene und gesicherte Texte nachträglich nicht mehr änderbar sind, müssen Sie für die betreffenden Textarten in der Definition des Textschemas das Änderungskennzeichen P (Protokollieren) auswählen.

Zusätzlich zu diesen Eingabe-Textarten müssen Sie eine Textart definieren, die nur dazu dient, die protokollierten Texte wieder anzuzeigen. Bei dieser Textart müssen Sie für die Textarten in der Definition des Textschema das Änderungskennzeichen R (Protokoll anzeigen) auswählen.

Bei den auf diese Weise eingestellten Textarten wird ein Text, sobald er gesichert wurde, mit einem Zeitstempel und der Kennung des eingebenden Benutzers versehen und kann daraufhin nur noch über das Protokoll angezeigt, aber nicht mehr verändert werden. Außerdem erhalten alle in das Protokoll eingestellten Texteinträge auch eine Beschriftung in Form eines Kurztextes. Dieser Kurztext entspricht dem Inhalt des Feldes Bedeutung mit dem die betreffende Textart im Textobjekt definiert ist.

Es ist sinnvoll aber nicht unbedingt erforderlich, für jede Bearbeitergruppe die Sie definieren auch eine eigene Textart anzulegen. Sie könnten auch mehreren Bearbeitergruppen die gleiche Textart zuweisen.

Unbedingt zu beachten ist folgender Sachverhalt: Um den Aufwand zu verringern sieht das Customizing der MB lediglich vor, dass Sie eine Zuordnung zwischen Bearbeitergruppe und Textart hinterlegen.

Der Zugriff auf eine Textart ist damit nicht vollständig spezifiziert. Die fehlenden Schlüsselbestandteile Textobjekt und Textschema ergeben sich aus dem verwendeten Positionstyp, da das Textschema (und damit das Textobjekt) dem Positionstyp zugeordnet ist.

Damit es beim Zugriff auf die Textarten nicht zu Laufzeitfehlern kommt, überprüft die Bearbeitungstransaktion, ob die Textart die der ausführenden Bearbeitergruppe zugeordnet ist, auch im Textschema der zu prüfenden Position enthalten ist.

Definition Bearbeitergruppen

Alle Bearbeitergruppen in der MB müssen einem Bearbeitergruppentyp zugeordnet werden. Es gibt die Bearbeitergruppentypen

Automatische Verarbeitung, Dialogbenutzer (Workflow)und Kunde (Portal).

Selbst anlegen können Sie nur Bearbeitergruppen vom Typ Dialog, d.h. solche die als Bearbeiter von Workitems in Frage kommen.

Bearbeitergruppen der beiden anderen Bearbeitergruppentypen werden ebenfalls benötigt, diese befinden sich in der Standardauslieferung. Der Grund hierfür liegt darin dass diese Bearbeitergruppen genau festgelegte Schlüsselbezeichnungen haben müssen, auf die die Programmlogik zugreift.

Die Aktivität zur Definition eigener Bearbeitergruppen beinhaltet auch das Zuweisen eines identifizierenden Codes. Über diesen identifizierenden Code wird eine Bearbeitergruppe als verantwortlich für die Bearbeitung einer Belegposition gekennzeichnet. Dies geschieht gleichzeitig mit dem Anstoßen der MB durch die AAG.

Unbedingt erforderlich ist die Zuweisung eines Identifizierungscodes bei Bearbeitergruppen der Ebene Beurteilung.

Optional ist sie für die Ebene Klärung -die Bearbeitergruppen der Ebene Klärung können, müssen aber nicht schon durch die AAG festgelegt werden - und überhaupt nicht erforderlich ist sie für die Ebene Genehmigung.

Zuweisen von Textarten für die Bearbeitergruppen

In der IMG-Aktivität Textarten für die Bearbeitungstransaktion zuordnen weisen Sie jeder von Ihnen definierten Bearbeitergruppe die Textart zu, unter der sie ihre Texteinträge erfassen soll.

Zuweisen von Entscheidungsfunktionen und Entscheidungscodes

In der IMG-Aktivität Entscheidungsfunktionen und -codes zuordnen ordnen Sie den Bearbeitergruppen Entscheidungsfunktionen und diesen wiederum Entscheidungscodes zu. Über den Typ der Bearbeitergruppen ist festgelegt, welche Entscheidungsfunktionen zur Verfügung stehen. Zu jeder zugeordneten Entscheidungsfunktion muss auch der entsprechende Code angegeben werden, mit dem diese Entscheidung im Protokoll der getroffenen Entscheidungen gespeichert wird.

Einschränkung der Sichtbarkeit von Ursachencodes

In der Bearbeitungstransaktion der MB findet sich außer dem Protokoll aller getroffenen Entscheidungen auch ein Protokoll der Ursachen, die zum Anstoßen der MB geführt haben. Dieser Code wird mit jedem Anstoßen der MB neu gesetzt.

Die Ursachencodes sind auf den Bearbeitungsebenen Beurteilung und Genehmigung uneingeschränkt sichtbar.

Für die Bearbeiter der Ebene Klärung können Sie die Sichtbarkeit der Ursachencodes über das Anlegen und Zuweisen von Sichtbarkeitsprofilen einschränken. Der Bearbeitern der Ebene Klärung bekommt dann nur diejenigen Ursachencodes angezeigt, die Sie ausdrücklich über die Zuweisung entsprechender Profile erlauben.
Nutzen Sie hierfür die die IMG-Aktivität Aktivierung der eingeschränkten Sichtbarkeit.

Über die IMG-Aktivität Sichtbarkeitsprofile anlegen und zuordnen definieren Sie Sichtbarkeitsprofile, ordnen diesen Sichtbarkeitsprofilen die entsprechenden Codegruppen zu, und weisen schließlich die Profile den Bearbeitergruppen der Ebene Klärung zu.

Wenn das Kennzeichen Sichtbarkeitsprofile aktiv nicht ausgewählt ist, können Sie die IMG-Aktivität Sichtbarkeitsprofile anlegen und zuordnen überspringen.

Einstellungen zum Workflow

In diesem Knoten wird der Workflow der MB eingehend beschrieben.

Sie können einen Schalter setzen, der bewirkt dass im Prüfungsprozess - unter entsprechenden Bedingungen - nicht der Beurteilende, sondern die Ebene Klärung das erste Workitem erhält. Der Beurteilende wird dann erst nach der Klärung angesprochen, wodurch sich sein Arbeitsaufwand verringert.

In der IMG-Aktivität Aufgabencustomizing können Sie die Zuordnung der möglichen Bearbeiter vornehmen und die Ereigniskopplung aktivieren.

Business Add-Ins für Bearbeiterfindung im Workflow

Um eine größtmögliche Flexibilität zu garantieren wird die Bearbeiterfindung vollständig in Form von Kundenlogik abgebildet.

Dieser Knoten erläutert eingehend den Ablauf der Bearbeiterfindung und verweist auch auf Beispielimplementierungen, in denen der Einsatz bereitgestellter Methoden demonstriert wird.

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 29040 Date: 20240601 Time: 224709     sap01-206 ( 469 ms )