Kontakt

Ansicht
Dokumentation

Configuration Delta Pricing with Multi-Factors ( RELNGG_30D_CFG_DELTAPRIC )

Configuration Delta Pricing with Multi-Factors ( RELNGG_30D_CFG_DELTAPRIC )

CL_GUI_FRONTEND_SERVICES - Frontend Services   General Data in Customer Master  
This documentation is copyright by SAP AG.
SAP E-Book

Short text

Configuration Delta Pricing with Multi-Factors

Description

IS-SW has reengineered the software pricing process by allowing the user to select parameters that influence prices and by reducing these parameters to a factor that can be used to calculate the price of the license. This factor-based pricing can be used for new licenses, license bumps and version changes.

Note: The license bump process depends upon this method of pricing.

To calculate the price of a license bump, the billing method of the document and the properties of the billing plan must be considered. If the license bump is to be invoiced one time, the price of a license bump is always the delta of the factor of the old license and the factor created from the selection of the new characteristic values. Therefore, the factor of the old license parameters must be stored before you can use, charge, or change the supply parameters. The determination of the factor resulting from the new selection of characteristic values is processed through the normal variant configuration logic, but before multiplying it by the base value of the software product, the old license factor must be subtracted.

If the license bump is billed on a recurring basis, the price calculation is similar to the new pricing logic described in the Release Note Process: Create New License.

Some software products are priced with a one-time charge and have the price of a bump calculated as the price of the changed configuration less the current price of the old configuration. In practical terms, this means:

Bump price = (new factor - old factor) x base value

This requires the ability to have the old (or previous) factor, new factor, and the delta factor in the configuration. To be able to calculate the bump price, you must copy the value of 'new factor' into the 'old factor' at the start of the bump process, before changing the configuration.

Current R/3 dependency functionality makes it possible to easily copy the value of one characteristic to another. For bump price copying, however, we only want to copy for bump events. We also only want to do it once, when the configuration is retrieved from the IBASE. Two function modules have been developed so that copying can be done as required. Both function modules are available so they can be used by variant configuration functions and thus be called from dependencies in the configuration.

Installation

The function module OG_SAVE_OLD_FACTOR stores the value of the old factor into program memory for further processing by the function module OG_COPY_FACTOR. Function module OG_COPY_FACTOR is what actually performs the copying of the new factor into the old factor. The copying is done only once during bump processing.

A variant configuration function must be created for each of these two function modules. For more information about this task, please use the IMG path: Logistics->Central Functions->Variant Configuration->Tools-> Function->Create.

The variant configuration function OG_SAVE_OLD_FACTOR must be placed in a configuration dependency so it is executed as early as possible after the bump configuration is copied. The variant configuration function OG_COPY_FACTOR must be placed in another dependency which is run immediately after the one that contains the OG_SAVE_OLD_FACTOR.

Note: Both dependencies must be of type 'Procedure.' It is recommended that you place them in the configuration profile, so that they are run immediately after any procedure that is updating a new factor.

The first procedure passes the current value of old factor and a string with the name of the old factor characteristic. It should look like this:
000010 PFUNCTION og_save_old_factor
000020 (gg_old_factor = $self.gg_old_factor,
000030 gg_charname = 'GG_OLD_FACTOR').

The second procedure passes the current value of new factor and a string with the name of the old factor characteristic and should look like this:
000010 PFUNCTION og_copy_factor
000020 (gg_new_factor = $self.gg_new_factor,
000030 gg_charname = 'GG_OLD_FACTOR').

The characteristic names on the left side of the '=' are the formal parameters defined in the variant configuration functions. The ones on the right side are the actual parameters.
The following restrictions apply:

  • The function names must be 'OG_SAVE_OLD_FACTOR' and 'OG_COPY_FACTOR' (R/3 requires that a function and corresponding function module have the same name).
  • Both parameters in both functions must be marked as input in the variant configuration function maintenance transaction.
  • The function modules do not require specific names of parameters or characteristics.
  • The characteristic containing the old factor and the formal parameter holding the old factor (in this example, both are 'GG_OLD_FACTOR') must both use the 'NUM' data type.
  • The characteristic containing the old factor must have a default value (e.g., 0).
  • The characteristic containing the new factor and the formal parameter holding the new factor must also both use the 'NUM' data type.
  • The formal parameter passing the name of the old factor (in this example 'gg_charname') must have a data type of 'CHAR' and length 30.





RFUMSV00 - Advance Return for Tax on Sales/Purchases   rdisp/max_wprun_time - Maximum work process run time  
This documentation is copyright by SAP AG.

Length: 5896 Date: 20240520 Time: 212036     sap01-206 ( 116 ms )