Ansicht
Dokumentation

Delta-Preisfindung mit Mehrfachbelegungsfaktoren konfigurieren ( RELNGG_30D_CFG_DELTAPRIC )

BAL Application Log Documentation   PERFORM Short Reference  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Kurztext

Delta-Preisfindung mit Mehrfachbelegungsfaktoren konfigurieren

Beschreibung

In der Branchenkomponente Software (IS-SW) wurde der Prozeß der Preisfindung so gestaltet, daß der Benutzer über eine Parameterauswahl die Preise beeinflussen und die ausgewählten Parameter auf einen Faktor reduzieren kann, der dann zur Ermittlung des Lizenzpreises herangezogen wird. Diese Faktorpreisfindung kann bei neuen Lizenzen, geänderten Lizenzen (Bumps) und Versionswechsel eingesetzt werden.

Hinweis: Der Prozeß der Lizenz-Bumps beruht auf dieser Art der Preisfindung.

Zur Errechnung des Preises für einen Lizenz-Bump muß der entsprechende Fakturierungsplan benutzt werden. Soll für den Lizenz-Bump Einmalzahlung gelten, ergibt sich der Preis immer aus dem Delta des Faktors der alten Lizenz und dem Faktor, der aufgrund der neuen Merkmalswerte ermittelt wird. Der Faktor der alten Lizenz muß daher abgelegt sein, bevor die Parameter für Verwendung, Zahlung und Lieferung geändert werden. Der aus den neuen Merkmalswerten resultierende Faktor wird über die normale Variantenkonfigurationslogik ermittelt; bevor er mit dem Basiswert des Software-Produkts multipliziert wird, wird der Faktor der alten Lizenz subtrahiert.

Gilt für den Lizenz-Bump periodische Zahlung, läuft die Preisfindung ähnlich wie bei der unter Prozeß: Software-Lizenz anlegen beschriebenen Logik ab.

Für manche Software-Produkte gilt Einmalzahlung, wobei der Preis des Bumps über den Preis der geänderten Konfiguration minus dem aktuellen Preis der alten Konfiguration errechnet wird. Praktisch bedeutet das:

Bump-Preis = (neuer Faktor minus alter Faktor) x Basiswert.

Dazu muß der alte (oder vorige) Faktor, der neue Faktor und der Delta-Faktor in der Konfiguration verfügbsr sein. Besonders muß man jedoch zu Beginn des Bump-Prozesses den Wert des 'neuen Faktors' zum 'alten Faktor' kopieren können, also bevor der Benutzer die Konfiguration ändert.

Mit der aktuellen R/3-Beziehungsfunktionalität ist es einfach, den Wert eines Merkmals zu einem anderen zu kopieren. Beim Kopieren von Bump-Faktoren möchten wir jedoch nur den Kopiervorgang in einem Bump-Szenario durchführen, und zwar einmalig, wenn die Konfiguration aus der IBASE abgerufen wird. Für den erforderlichen Kopiervorgang wurden dazu zwei Funktionsbausteine entwickelt. Beide Funktionsbausteine können von Funktionen der Variantenkonfiguration verwendet werden und daher auch von Beziehungen in der Konfiguration aufgerufen werden.

Besonderheiten bei der Installation

Der Funktionsbaustein OG_SAVE_OLD_FACTOR legt den Wert des alten Faktors zur weiteren Bearbeitung durch den Funktionsbaustein OG_COPY_FACTOR im Programmhauptspeicher ab; OG_COPY_FACTOR führt den eigentlichen Kopiervorgang vom neuen zum alten Faktor durch. Der Kopiervorgang wird einmal ausgeführt, und zwar nur während des Prozesses Lizenz-Bump anlegen.

Für jeden der beiden Funktionsbausteine muß eine Variantenkonfigurationsfunktion angelegt werden. Nähere Informationen hierzu können Sie im IMG über Logistik -> Zentrale Funktionen -> Variantenkonfiguration -> Werkzeuge -> Funktion -> Anlegen anzeigen.

Die Funktion OG_SAVE_FACTOR muß in eine Konfigurationsbeziehung gestellt werden, damit sie so früh wie möglich nach dem Kopieren der Konfiguration in einem Bump-Szenario ausgeführt wird. Die Funktion OG_COPY_FACTOR muß in eine andere Beziehung gestellt werden, die direkt nach der mit OG_SAVE_OLD_FACTOR laufen muß.

Hinweis: Beide Beziehungen müssen vom Typ Prozedur sein. SAP empfiehlt, sie in das Konfigurationsprofil zu stellen, damit sie direkt nach einer Prozedur ausgeführt werden, die den neuen Faktor aktualisiert.

Die erste Prozedur übergibt den Wert des alten Faktors und eine Zeichenkette mit dem Namen des alten Faktormerkmals. Sie sollte so aussehen:
000010 PFUNCTION og_save_old_factor
000020 (gg_old_factor = $self.gg_old_factor,
000030 gg_charname = 'GG_OLD_FACTOR').

Die zweite Prozedur übergibt den aktuellen Wert des neuen Faktors und eine Zeichenkette mit dem Namen des alten Faktormerkmals. Sie sollte so aussehen:
000010 PFUNCTION og_copy_factor
000020 (gg_new_factor = $self.gg_new_factor,
000030 gg_charname = 'GG_OLD_FACTOR').

Bei den Merkmalsnamen auf der linken Seite vom '=' handelt es sich um die in den Variantenkonfigurationsfunktionen definierten Formalparameter. Bei den Namen rechts handelt es sich um die Aktualparameter.
Es gelten folgende Einschränkungen:

• Die Funktionsnamen müssen 'OG_SAVE_OLD_FACTOR' und 'OG_COPY_FACTOR' heißen (im R/3-System muß eine Funktion und der entsprechende Funktionsname identische Namen haben).

• Beide Parameter in beiden Funktionen müssen bei der Pflege der Variantenkonfigurationsfunktion als Eingabe markiert sein.

• Für die Parameter oder Merkmale der Funktionsbausteine sind keine spezifische Namen erforderlich.

• Das Merkmal und der Formalparameter, die den alten Faktor enthalten, (in diesem Fall ist das immer gg_old_factor) müssen beide vom Datentyp NUM sein.

• Das Merkmal, das den alten faktor enthält, muß einen Vorschlagswert haben (z.B. 0).

• Das Merkmal und der Formalparameter, die den neuen Faktor enthalten (in diesem Fall ist das immer gg_new_factor) müssen beide vom Datentyp NUM sein.

• Der Formalparameter, der den Namen des alten Faktors (in diesem Fall gg_charname) übergibt, muß vom Datentyp CHAR sein und die Länge 30 haben.
  
  

Auswirkungen auf die Systemverwaltung

Auswirkungen auf das Customizing

Auswirkungen auf Batch-Input

Änderungen an der Oberfläche

Änderungen in der Vorgehensweise

Aktionen zum Beheben von Fehlern am Datenbestand

Abhängige Funktionen

Planungen

Weitere Hinweise

ABAP Short Reference   TXBHW - Original Tax Base Amount in Local Currency  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 7025 Date: 20240523 Time: 153810     sap01-206 ( 127 ms )