Kontakt

Ansicht
Dokumentation

RVPOTCUS - Report zum Einrichten der Potentialpflege für Release 3.0

RVPOTCUS - Report zum Einrichten der Potentialpflege für Release 3.0

General Data in Customer Master   CPI1466 during Backup  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Beschreibung

Dokumentation der Potentialdatenpflege für die Pilotkundenauslieferung

1.,,,,Allgemeine Beschreibung
1.1,,,,Ziele der Potentialplanung
1.2,,,,Freigabe der Potentialplanung im Release 3.0
1.3,,,,Funktionsbeschreibung
1.3.1,,Allgemeines
1.3.2,,Aufruf der Potentialplanung
1.3.2.1,,Aus Kontakt
1.3.2.2,,Aus CO-PA
1.3.3,,Auswertung der Potentialdaten
2.,,,,Einrichten CO-PA
3.,,,,Anpassen der Programm-Routinen

1. Allgemeine Beschreibung

1.1 Ziele der Potentialplanung

Ziel der Potentialplanung ist es, auf unterschiedlichsten Objektebenen festzuhalten, welches Potential(Absatz, Umsatz) diesbezüglich vorliegt.
Objektebenen sind dabei typischerweise:

  • Kunde
Verkaufsorganisation
Wettbewerber
  • Kunde
Verkaufsorganisation
Produkthierarchie-Stufe 1
Produkthierarchie-Stufe 2
Wettbewerber
  • Kunde
Verkaufsorganisation
Produkthierarchie-Stufe 1
Produkthierarchie-Stufe 2
Produkthierarchie-Stufe 3
Wettbewerber
  • Kunde
Verkaufsorganisation
Produkthierarchie-Stufe 1
Produkthierarchie-Stufe 2
Produkthierarchie-Stufe 3
Wettbewerber
Wettbewerbermaterial

Diese Information dient zur Schätzung der Absatz- und Umsatzziele der Folgeperiode. Zur Erreichung dieser Ziele sind u.U. Verkaufs- und Vertriebsaktivitäten notwendig, bei deren Planung die Kosten-Nutzen-Relation beachtet werden muß. Potentialdaten stellen bei diesem Vorgang die Basis der Analyse dar. Zu Rel. 3.0 wird es im Standard keine Analyse geben, sondern Augenmerk wird auf die Erarbeitung einer effizienten Erfassung von Potentialdaten gelegt.

1.2 Freigabe der Potentialplanung im Release 3.0

Zu Release 3.0 darf die Potentialplanung nur von ausgewählten Pilotkunden genutzt werden. Die Nutzung darf auch nicht produktiv erfolgen. Ziel der Pilotauslieferung ist es, die Diskussion des Themas mit den Pilotkunden anhand von Beispielen zu beleben.

1.3 Funktionsbeschreibung

1.3.1 Allgemeines

Die Potentialplanung ist eng mit der Absatz- und Ergebnisplanung des CO-PA verbunden. Es werden dazu eigene Planversionen im entsprechenden Ergebnisbereich des CO-PA benutzt.

1.3.2 Aufruf der Potentialplanung

1.3.2.1 Aus Kontakt

Der Aufruf der Potentialplanung erfolgt in 'Ändern Kontakt' via Menu 'SPRINGEN'. Man verzweigt in die Plandatenerfassung des CO-PA. Für die Erfassung wird eine Zeilen-/Spaltenstruktur vorgeschlagen, mittels der nun die Potentialdaten erfasst werden. Das Sichern der Potentialdaten erfolgt auf dem Bild der Plandatenerfassung.

Bemerkung:
Es kann sein, daß bestimmte Funktionen der Potentialdatenerfassung dazu führen, daß das Verlassen der Potentialdatenerfassung nicht das Zurück in den Kontakt bewirkt. In dieser Pilotierung erfolgt keine Sicherheitsabfrage.

1.3.2.2 Aus CO-PA

Hier erfolgt die Erfassung in dem jeweiligen Ergebnisbereich, der ggf. manuell gesetzt werden muß, mittels der im Ergebnisbereich definierten Zeilen-/Spaltenstrukturen.

1.3.3 Auswertung der Potentialdaten

Die Potentialdaten werden mit der Einzelpostenanzeige des CO-PA ausgewertet (Report RKEB0601). Wenn bei der Auswertung die Nummer des Referenzbeleges angegeben wird, werden alle aus diesem Kontakt erfassten Potentialdaten angelistet.

2. Einrichten CO-PA

2.1 Einrichten Ergebnisbereich

Falls die Anwendung CO-PA (Ergebnisrechnung) genutzt wird, müssen für die Potentialplanung nur Änderungen im Ergebnisbereich durchgeführt werden. Andernfalls ist ein Ergebnisbereich für die Potentialplanung neu einzurichten.
Im folgenden werden die erforderlichen Aktionen nur stichwortartig beschrieben. Ausführliche Informationen finden sich in der Dokumentation zur Ergebnisrechnung.

2.2 Aufnehmen Merkmale

Im CO-PA müssen in dem Ergebnisbereich, in dem die Potentialplanung durchgeführt werden soll, die Merkmale aufgenommen werden, deren Kombination die Objektebenen der Potentialplanung bilden.

  • Wettbewerber
Dazu ist das Feld KUNNR aus der Tabelle MARA zu übernehmen.
  • Produkthierarchiestufen.
Für jede Stufe der Produkthierarchie ist ein eigenes Merkmal anzulegen.

Die Merkmale Verkaufsorganisation (VKORG), Kunde (KNDNR) und Material (ARTNR) sind standardmäßig im Ergebnisbereich enthalten.

2.3 Aufnehmen Werfelder

Im Normalfall sollten die Wertfelder der Ergebnisrechnung auch für die Potentialplanung nutzbar sein. Falls erforderlich, können auch zusätzliche Wertfelder für die Potentialplanung angelegt werden.
Nach der Aufnahme neuer Merkmale oder Wertfelder ist der Ergebnisbereich zu generieren.

2.4 Anlegen Zeilen-/Spaltenstruktur

Beachten Sie hierbei folgendes:

  • Verkaufsorganisation
Da sich aus der Verkaufsorganisation die Wettbewerbernummer für die eigene Firma ableitet, kann eine diesbezügliche Prüfung nicht erfolgen, wenn die Verkaufsorganisation nicht als Merkmal in der Zeilen-/Spaltenstruktur auftritt. Die Verkaufsorganisation sollte daher in der Zeilen-/Spaltenstruktur enthalten sein.
  • Produkthierarchie
Die Produkthierarchie ist mittels einer DDIC-Struktur (PRODHS) in Stufen/Level unterteilt. Die Stufe I darf ohne die Stufe I-1 kein Element der Zeilen-/Spaltenstruktur sein.

Beisp.: Die Produkthierarchie sei folgendermaßen unterteilt

,,,,Stufe 1: PRODH1 --> Länge 5
,,,,Stufe 2: PRODH2 --> Länge 5
,,,,Stufe 3: PRODH3 --> Länge 8

Soll PRODH2 Element der Zeilen-/Spaltenstruktur sein, so muß auch PRODH1 Element der Zeilen-/Spaltenstruktur sein (Stichwort: Merkmalsklammerung).

2.5 Anlegen Planversion

Legen Sie eine Planversionen für die Potentialplanung an.

3. Programmanpassungen

Die Programme RKEPLPT1/RKEPLPT2 enthalten speziell Routinen der Potentialdatenerfassung. Diese Routinen müssen jeweils kundenkontextspezifisch angepasst werden. Die Stellen, an denen Anpassungen erfolgen müssen, sind in den Programmen gekennzeichnet.
Folgende Anpassungen sind notwendig:

  1. Anpassung: Struktur Produkthierarchie
Diese Anpassung ist markiert mit dem Label MODPRODH1.
Die Anpassung ist notwendig, wenn
  • die Struktur der Produkthierarchie geändert wurde.

  • die Produkthierarchiefelder im Ergebnisbereich nicht PRDH1, PRDH2 bzw. PRDH3 heißen.

  1. Anpassung: F4 für Produkthierarchie
Diese Anpassung ist markiert mit dem Label MODPRODH2.
Die Anpassung ist notwendig für die F4-Hilfe bzgl. Feldern der Produkthierarchie auf den Erfassungsbildern der Zeilen-/Spaltenstruktur.
  1. Anpassung: Name des Ergebnisbereichs
Diese Anpassung ist markiert mit dem Label MODPRODH3.
Die Anpassung ist notwendig, um den Namen des Ergebnisbereiches, in dem die Potentialplanung durchgeführt wird, zu ändern.
  1. Anpassung: Vorschlag für Zeilen-/Spaltenstruktur
Die Anpassung ist notwendig um kontaktartenabhängig einen Vorschlag für die Potentialdatenerfassung zu setzten. Hierfür ist die Routine POTENTIAL_PROP_SET im Include RKEPLPT2 anzupassen.
  1. Anpassung: Aktivierung der Potentialdatenerfassung
Zunächst muß im Report RKEPLPT1 das INCLUDE-Member RKEPLPT2 includiert werden (das Statement wird ausgesternt ausgeliefert).
Die Aktivierung der Potentialdatenerfassung in den Kontakten wird mittels der Routine POTENTIAL_ACTIVFLAG_GET im Report RKEPLPT1 gesteuert.





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

Length: 9012 Date: 20240531 Time: 061949     sap01-206 ( 115 ms )