- SAP Managed Tags:
Pricing in Business Transactions
Pricing is used to describe the calculation of prices and costs in a business transaction. Pricing enables to determine relevant price information in all types of business transactions such as sales or service orders, contracts, quotations or campaigns.
Different kinds of condition groups – for example, prices, discounts, surcharges, freight or taxes – can be determined. The system uses the condition technique for pricing, to determine relevant pricing information from condition records for a business transaction. Using condition technique the system answers the search queries of different applications by searching in existing condition records for valid results using certain search criteria.
SAP Pricing Fundamentals
ConditionTechnique in Pricing
The condition technique refers to the method by which the system determines prices from information stored in condition records. The various elements used in the condition technique are set up and controlled in customizing. During the processing of a business transaction, the system uses the condition technique to determine a variety of important pricing information.
For example, the system automatically determines which gross price the customer should be charged and which discounts and surcharges are relevant given the conditions that apply.
Elements in the condition technique
- Condition Types: Define condition types different components that make up a price of a product (base price, discounts, and surcharges)
- Condition Tables: To store and retrieve condition records for each of the different condition types
- Access sequences: Strategy to enable the system to find valid condition records
- Pricing Procedure: Grouping of condition types in a particular sequence
Process Flow for condition determination
- The determination of pricing procedure is determined based on the data in the application.
- The pricing procedure has several condition types in sequence; the system reads the first condition type of the search procedure and determines the access sequence.
- The access sequence is read with the condition tables which are also read in a sequence. The condition tables determine the condition records. The condition tables have key field combinations based on which the system determines the condition records.
- As soon as the system has found a valid condition record for a condition table, it makes the result value for a results field available to the application.
- When the determination procedure condition more than one condition type, the system repeats the search for condition records for each condition type.
Condition Types
In order to translate the receipt below in CRM, the system uses “condition types” to differentiate between different price components. Condition types may be defined for base price, freight charges, taxes, discounts, net price, etc. The calculation can be based on the amount or weight or volume of the product. It can be based on a number or can be “%” based or can vary depending on a scale.
Access sequences
Pricing depends on a host of factors. For example, a discount may be applied only may only on a particular
customer or the customer group. It may depend on the region or the product being or it may be applicable for only certain duration. There are many such complex scenarios in real world and in order to determine the prices according
to these conditions, the system makes use of access sequences.
Access sequence is a search strategy used in pricing to determine the best value that meets the required conditions in an iterative manner. For example, if a certain tax % should be waived off particular customer group for a sales office, then the system searches for this combination via access sequence. The access sequence contains
a list of condition tables having condition records which are accessed in aniterative fashion to get the best possible match.
Condition Tables & Condition Records
A condition table defines the combination of fields that identifies a unique condition record. Specific data about the conditions is stored in the condition tables as condition records. For example, condition records can be used to maintain a product price or special discount for privileged customer or a special price is applicable for a certain period.
Values in condition records can also be scale based.
Note : The fundamental pricing concepts explained above are
applicable equally for SAP CRM as SAP SD.
Pricing in CRM
Pricing in CRM is also governed by condition types which in turn forms a sequence in pricing procedure. The
pricing procedure in CRM is determined based on the following factors:
pricing procedure in CRM is determined based on the following factors:
- Sales Organization
- Distribution Channel
- Document Pricing Procedure (can be assigned to a
sales transaction, on the third level) - Customer Pricing Procedure (assignment in business
partner master)
Path in customizing
SAP Customizing Implementation Guide->Customer Relationship Management->Basic Functions->Pricing->Pricing in the Business Transaction->Determine Pricing Procedures
The customizing data for the condition technique and pricing is first downloaded from R/3 into the CRM
system. This is done via initial load in CRM via transaction R3AS.
system. This is done via initial load in CRM via transaction R3AS.
In the standard system there are the following objects for transferring:
- DNL_CUST_CNDALL (all data for condition
technique and pricing) - DNL_CUST_CND (condition technique data without
the cross-client data) - DNL_CUST_PRC (Pricing data)
Internet Pricing and Configurator (IPC)
The Internet Pricing and Configurator is the pricing and configuration tool for CRM Online and CRM Internet Sales. SAP
CRM uses IPC (Internet Pricing and Configurator) to determine pricing information when creating a business transaction, such as a quotation, sales order, service process or a contract in a web based environment. It allows to configure price and products in a web environment, using master data that is downloaded from SAP R/3 system. It combines the functions of the Sales Configuration Engine (SCE) and the Sales Pricing Engine (SPE) with a standardized Web interface.
CRM uses IPC (Internet Pricing and Configurator) to determine pricing information when creating a business transaction, such as a quotation, sales order, service process or a contract in a web based environment. It allows to configure price and products in a web environment, using master data that is downloaded from SAP R/3 system. It combines the functions of the Sales Configuration Engine (SCE) and the Sales Pricing Engine (SPE) with a standardized Web interface.
IPC is the core part of pricing in CRM. The IPC ensures integrated price calculation, regardless of whether prices are calculated for a business transaction in CRM Enterprise, in Telesales, or in SAP E-Commerce. It is a Java-based client-server package. It provides R/3 pricing and R/3 product configuration outside of an R/3 system. It can access both the customizing data as well as the condition records. It does not need an online R/3 system whilst still maintaining pricing and configuration data in one place.
Pricing Routines
Routines for pricing are maintained in R/3 system using transaction VOFM. These are then entered in the pricing procedure or the condition type. The standard routines in R/3 are mapped to IPC user exits in CRM. The pricing routines or user-exits in IPC are developed in Java.
In an SAP R/3-CRM set-up, where the pricing related customization can be downloaded from the source, R/3 to CRM, the standard pricing runs fine on CRM. However, in cases where we have custom pricing routines developed in R/3, they will not get downloaded to CRM as the translation between ABAP and Java is not automatically performed. Hence, in order to maintain consistency between the custom routines in R/3 and CRM, they should be coded in IPC. In case of a vice versa arrangement where the source of the pricing routine is CRM, the same routine needs to be implemented in ABAP in R/3. In the next sections we will see how these user exits are developed.
Pricing Communication Structure in CRM
The CRM applications communicate with IPC using pricing communication structure for data transfer. This communication structure is called the pricing communication structure or the field catalog. All the fields in the access sequence will be maintained in the field catalog.
Path in customizing
SAP Customizing Implementation Guide->Customer Relationship Management->Basic Functions->Pricing->
Define Settings for Pricing->Define Settings for Pricing
Define Settings for Pricing->Define Settings for Pricing
More often than not, we have a requirement to customize the pricing, for example, to determine pricing based on some custom fields on the business transaction. In order to do so, we need to add these custom fields during pricing process. For example, we need to determine price according to product hierarchy which is not contained in the standard communication structure. In this case, we need to do some enhancement to pass custom field to the communication structure.
Pricing Business Add-in (BADI)
Any custom fields that need to be accessed to determine pricing should be present in this pricing communication structure. The structure will hold the value in run time via a pricing related BADI. In order to process the custom fields in pricing communication structure and to pass it back to the communication structure, SAP provides a BADI
CRM_COND_COM_BADI.
CRM_COND_COM_BADI.
If any field is added at header level of the field catalog, that will available in the changing parameter of the method
HEADER_COMMUNICATION_STRUCTURE.
HEADER_COMMUNICATION_STRUCTURE.
If any field is added at item level of the field catalog, that will available in the changing parameter of the
method ITEM_COMMUNICATION_STRUCTURE.
method ITEM_COMMUNICATION_STRUCTURE.
Development Environment
The pricing user-exits will be compiled with the J2SE 1.4.x or a compatible java compiler of version 1.4.x. Also the used libraries must be compatible with J2SE 1.4.x. An IDE like Eclipse, 3.1 and above is recommended for
development of the routines.
development of the routines.
Note: It is important that the compiled class files are compatible to a JDK 1.4 version as well as the standard library used isonly JDK 1.4. The VMC java environment of SAP BASIS 7.00 does only support 1.4 class files and libraries.
Important related SAP notes
Development Steps of Pricing Routine
In order to implement a routine in IPC, we first import an existing project into workspace. We take this existing
project from a zip file attached in an SAP provided note, 809820, for this purpose. This helps is accelerating the development.
project from a zip file attached in an SAP provided note, 809820, for this purpose. This helps is accelerating the development.
Here are the steps.
- Download and unzip the ZIP file attached in SAP Note 809820 into a directory, say C:\DEV. This folder is the workspace folder for eclipse.
- Enter into transaction /n/SAPCND/UE_DEV. API JAR files and some source JARs from the system will be downloaded in a subfolder in the above directory upon executing the transaction as shown in screenshot below.
The development of the pricing routine will be done in an IDE, say eclipse. Hereprepare an eclipse project using the folder in step 1 which will act as a workspace in eclipse.
Customer implementations will be created in the src directory. After implementing the customer exits, the user exit
classes need to be uploaded back into the system. For this, the java sources and the compiled classes must be error free. Then prepare a JAR file from the SAP delivered configuration file ‘create_PRC_UE_CUSTOMER_jar.jardesc’ in the SAP note.
classes need to be uploaded back into the system. For this, the java sources and the compiled classes must be error free. Then prepare a JAR file from the SAP delivered configuration file ‘create_PRC_UE_CUSTOMER_jar.jardesc’ in the SAP note.
We will see shortly how the user exit accesses the application data and determine the pricing.
- The developed user exit will then be uploaded into the system using the same transaction /n/SAPCND/UE_DEV. For one ABAP package, only one JAR file can be used. Uploading will over-write an existing JAR file if present, however the new coding is not taken automatically. We need to reset the VMC in transaction SM52.
Uploaded user exits
The uploaded user exits can be seen in transaction SM53.
The transaction SM53 contains also a browser to see the installed and uploaded java modules along with the user exit files.
- Select in the Navigation tree the element Application.
- Browse the Installation tree down to the shown level 0/SAP/IPC -> Modules.
- All modules ending with _SAPCND_UE are customer uploaded modules equals jar files.
- Select the folder for /0CUST/ZSD_DEV_SAPCND_UE and we can see the uploaded jar files.
Configuration of uploaded user-exits
Theuploaded java routine is configured in transaction /n/SAPCND/UEASS.
Give application as CRM.
Enter usage as Pricing, PR, and execute.
The next screen the various types of standard user exits.
Register a user-exit
In order to create a custom implementation, it first needs to be registered under the appropriate user exit type.
Registering a user-exit is a cross client customizing and can be done by creating a new entry. Provide a user-exit name which is a symbolic or short description of the functionality. The customer namespace starts with Y or Z.
As an example below, user exit type “VAL” has two custom implementations registered under it. Select
the “Implementations” folder in the left pane of the transaction as shown in the screenshot below after having selected the appropriate user exit type in the above screenshot.
the “Implementations” folder in the left pane of the transaction as shown in the screenshot below after having selected the appropriate user exit type in the above screenshot.
Double-click on the implementation name and then enter the name of the implementation class compiled for this routine. There is no restriction on the name but it should be different from com.sap*. Give a description to the exit.
Attributes in exits
If the user exit needs access to some attributes on the application data, then these attributes should be defined in the
“Attributes” section of the user exit. This attribute is only a symbolic name which will be mapped later to a field from the pricing communication structure. This name of the attribute will be referenced in the user exit implementation.
“Attributes” section of the user exit. This attribute is only a symbolic name which will be mapped later to a field from the pricing communication structure. This name of the attribute will be referenced in the user exit implementation.
As shown in example below, the user-exit Z1156 has three attributes maintained against it.
- ZDENOMINATOR
- ZNUMERATOR
- ZSOLDCAPACITY
Formula number assignment
The next step is to assign a formula number to the implementation. This formula number will be assigned to the
relevant condition type in pricing.
relevant condition type in pricing.
Number range of formulas
Allowed number range for different types of user exits can be seen in transaction /n/SAPCND/UERNG.
For exit of type VAL, the customer number range is within 600-999.
1Double–click on the “Formulas” folder in the left panel of the transaction and create a new formula number, say, 900, configured for Z1156, our custom user-exit.
Select “Attributes” double click on it
Now, these characteristics that appear in the column “Field Name” of this screenshot are required to be maintained in the pricing communication structure.
These fields in the pricing communication structure will be populated via the pricing BADI, by implementing either of the header or the item methods, depending on which level this pricing is maintained and required for.
The custom fields may be present on the application data or may be derived via some other attributes on the application data. In our case, these attributes are linked to configuration characteristics at item level for a product on a business transaction.
The last step within CRM after registration and assignment of the user-exit formula must be to upload before it can be assigned to any pricing.procedure or other configuration. As the configuration is buffered for one day (default setting) the changes will only become immediately active with a restart of the VMC or the application server.
Note: While testing different configuration in a test or development system also the function module, IPC_DET_CLEAR_CUST_BUFFER can be executed.
Virtual Machine Container
The VirtualMachine Container (in short VM Container or VMC) is a component integrated into the SAP Web AS ABAP that enables Java functions that comply with the Java Standard J2SE 1.4 to be executed in AS ABAP. The VMC is optimized for applications that use functions implemented in ABAP as well as in Java, and that have to communicate quickly and reliably with one another.
Logs in Virtual Machine Container
In the transaction SM53, on the left side we can see Log Administration, in that we also see the Log Configuration. We can specify the various severity levels like at the package or class level.
- Info
- Warning
- Error
- Fatal
- Debug
Logs can now be viewed in SM53 itself. Theycan also be filtered by different criteria such as severity, log name,or user.
The creation of the logs will be required to be done in the user exit itself. The class com.sap.spe.base.logging.UserexitLogger implements two methods for logging debug messages or error messages.
An example coding is shown below from a sample user exit in the note.
Classes to be inherited for different types of user exits
Related Content
- http://help.sap.com
- http://scn.sap.com
- http://service.sap.com
( For reference to SAP notes)
36 Comments
