Skip to Content

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.
                    /wp-content/uploads/2013/04/1_209864.png

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.

                    /wp-content/uploads/2013/04/2_209868.png

            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.

                    /wp-content/uploads/2013/04/3_209869.png

            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.
/wp-content/uploads/2013/04/5_209877.gif/wp-content/uploads/2013/04/4_209876.gif
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:
      • 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)
/wp-content/uploads/2013/04/1_209864.png

            Path in customizing
SAP Customizing Implementation Guide->Customer Relationship Management->Basic Functions->Pricing->Pricing in the Business Transaction->Determine Pricing Procedures
/wp-content/uploads/2013/04/1_209864.png
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.
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.
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
/wp-content/uploads/2013/04/1_209864.png

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.

/wp-content/uploads/2013/04/1_209864.png

     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.
     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.

            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.
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

               /wp-content/uploads/2013/04/1_209864.png

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.
Here are the steps.
      1. 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.
      2. 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.

/wp-content/uploads/2013/04/1_209864.png

                    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.

/wp-content/uploads/2013/04/1_209864.png
                   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.
                    We will see shortly how the user exit accesses the application data and determine the pricing.
        1. 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.

/wp-content/uploads/2013/04/1_209864.png

            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.
        1. Select in the Navigation tree the element Application.
        2. Browse the Installation tree down to the shown level 0/SAP/IPC -> Modules.
        3. All modules ending with _SAPCND_UE are customer uploaded modules equals jar files.
        4. Select the folder for /0CUST/ZSD_DEV_SAPCND_UE and we can see the uploaded jar files.

/wp-content/uploads/2013/04/1_209864.png

            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.
/wp-content/uploads/2013/04/1_209864.png
                     The next screen the various types of standard user exits.

/wp-content/uploads/2013/04/2_209868.png

            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.

/wp-content/uploads/2013/04/1_209864.png

                    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.
/wp-content/uploads/2013/04/1_209864.png

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.
          As shown in example below, the user-exit Z1156 has three attributes maintained against it.
        • ZDENOMINATOR
        • ZNUMERATOR
        • ZSOLDCAPACITY

/wp-content/uploads/2013/04/1_209864.png

             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.
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.

/wp-content/uploads/2013/04/1_209864.png1

Double–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.

/wp-content/uploads/2013/04/1_209864.png

Select “Attributes” double click on it

/wp-content/uploads/2013/04/1_209864.png

               Now, these characteristics that appear in the column “Field Name” of this screenshot are required to be                maintained in the pricing communication structure.

/wp-content/uploads/2013/04/1_209864.png

                         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.
        1. Info
        2. Warning
        3. Error
        4. Fatal
        5. Debug
          Logs can now be viewed in SM53 itself. Theycan also be filtered by different criteria such as severity, log name,or user.

/wp-content/uploads/2013/04/1_209864.png

          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.

/wp-content/uploads/2013/04/1_209864.png

Classes to be inherited for different types of user exits


               /wp-content/uploads/2013/04/1_209864.png

Related Content

  1. http://help.sap.com
  2. http://scn.sap.com
  3. http://service.sap.com
    ( For reference to SAP notes)



To report this post you need to login first.

34 Comments

You must be Logged on to comment or reply to a post.

  1. Kavindra Joshi

    Hi ,

     

    I found this document extremely useful for somebody who is new to IPC and is looking to ramp up on IPC. Also if just want to debug in ABAP stack , this document is extremely useful as you now know that CRM_COND_COM_BADI BADI is the place where the debug points could be put.

     

    ~Kavindra

    (0) 
  2. Fahrettin Kerem Bozbiyik

    So useful Pricing Fundamentals & IPC core function article.

     

    thanks,

     

    Fahrettin

    (0) 
  3. Fahrettin Kerem Bozbiyik

    So useful Pricing Fundamentals & IPC core function article.

     

    thanks,

     

    Fahrettin

    (0) 
  4. Krishnendu Laha

    Hello Mamta,

     

    Very Nice document…

     

    I have found one typo mistake:

     

    If any field is added at header level of the field catalog, that will available in the changing parameter of the

         method ITEM_COMMUNICATION_STRUCTURE.”

     

    ~ Here Header should be replaced with Item, please check.

     

    Thanks

    Krish

    (0) 
  5. Sanjukta Dey

    Hello Mamta,

    Thanks for this document .It was of great help.I have a doubt in 2 scenarios.Can anyone please help me out to solve this:

    1.Suppose we need two search criteria to display a single field,can it be possible using the following way:

    create 2 condition table for the 2 search criteria field and then assign both the condition table as access under access sequence.Then while creating the condition record I am getting both the search criteria fields and putting the required values in those fields for which I need to display that particular condition type.

    Did I follow the correct path?? But I am nt getting my desired output..

    2.Suppose for a condition type I had auto populated its value through Code.But then I need to set access sequence against this particular condition type.I need to make it available only for a particular criteria.So I had done the required configuration and made condition record with the particular search criteria for that condition type.But after that the auto-populated value is not coming.”0.00″ is getting populated against that condition type as in the condition record the value to be populated is getting automatically set to “0.00”. What should I do???

    (0) 
  6. Vinay Rao

    Thank you Mamta for this excellent document.

     

    I have implemented given solution and this is working for ECC billing scenarios, However for CRM billing scenarios it is not.

    Do we need to perform any additional configurations/ABAP coding for CRM billing scenarios ?

     

    Thanks in advance.

     

    Regards,

    Vinay.

    (0) 
  7. Kiran Endreddy

    Hi Mamta,

     

    Thanks for a very good article on IPC. I have a question on number of times each custom user exit is getting executed.

     

    When i see the debug log i can see that the Value user exits executes more than once during calculation. Can you please help me in understanding on why the user exits executes more than once for a given item.

     

    In the below table PresentValue caculation is done 3 times for item 100. Cant we just restrict to do only one time for each time.

     

    Can you please help me in this

     

    Thanks,

    kiran

     

    2014-05-19T14:55:07:139-08:00 INFO Effective severity set to ‘Debug’ (100)
    2014-05-19T14:55:32:619-08:00 DEBUG Start Presentvalue.overwriteConditionValue() for item: 0000000100
    2014-05-19T14:55:32:620-08:00 DEBUG . Item Category ZDLE
    2014-05-19T14:55:32:620-08:00 DEBUG . in the if condition ZDLE
    2014-05-19T14:55:32:620-08:00 DEBUG .     ZZTERM:                                                60
    2014-05-19T14:55:32:620-08:00 DEBUG .     N Value (Term) is: 60
    2014-05-19T14:55:32:620-08:00 DEBUG Fair Value is zero so no calculation of  i
    2014-05-19T14:55:32:620-08:00 DEBUG End fvintrate.overwriteConditionValue()
    2014-05-19T14:55:32:687-08:00 DEBUG Start Presentvalue.overwriteConditionValue() for item: 0000000100
    2014-05-19T14:55:32:687-08:00 DEBUG . Item Category ZDLE
    2014-05-19T14:55:32:687-08:00 DEBUG . in the if condition ZDLE
    2014-05-19T14:55:32:688-08:00 DEBUG .     ZZTERM:                                                60
    2014-05-19T14:55:32:688-08:00 DEBUG .     N Value (Term) is: 60
    2014-05-19T14:55:32:688-08:00 DEBUG Fair Value is zero so no calculation of  i
    2014-05-19T14:55:32:688-08:00 DEBUG End fvintrate.overwriteConditionValue()
    2014-05-19T14:55:33:445-08:00 DEBUG Start Presentvalue.overwriteConditionValue() for item: 0000000100
    2014-05-19T14:55:33:445-08:00 DEBUG . Item Category ZDLE
    2014-05-19T14:55:33:445-08:00 DEBUG . in the if condition ZDLE
    2014-05-19T14:55:33:449-08:00 DEBUG .     ZZTERM:                                                60
    2014-05-19T14:55:33:449-08:00 DEBUG .     N Value (Term) is: 60
    2014-05-19T14:55:33:449-08:00 DEBUG Fair Value is zero so no calculation of  i
    2014-05-19T14:55:33:449-08:00 DEBUG End fvintrate.overwriteConditionValue()
    (0) 
  8. Pradeep Singhal

    Hello,

    Mamta, Many thanks for this Information, it’s very helpful.

    Can anybody please help me, In CRM_COND_COM_BADI BADI,

    I wanted to read all the Condition Type applicable for a particular Item/Header Guid ?

    My scenario was to enable a certain condition based on another condition in the list.

    Like : MWST is present enable “ZWST” else not.

    How I can achieve this in IPC ?

    (0) 
    1. Kavindra Joshi

      hi Pradeep ,

       

      You don’t implement CRM_COND_COM_BADI for a particular condition type but for a routine to be created. If you want to read this information , then there are FMs available. Let me get back to you on this.

       

      ~Kavindra

      (0) 
  9. Joao Sousa

    CRM still uses IPC?….. In CRM 4.0 this was one of the worst bits of technology I’d ever seen, another Java monster to stand next to the same exact functionality in ABAP….

     

    Implement the exit in ABAP for SD, implement the same exit in Java for IPC. Awesome design.

    (0) 
      1. Kavindra Joshi

        Actual people confuse IPC is only used for pricing but the bigger use case of IPC is TTE & SCE. There used to be a JAVA PME which was used to support Variant Configuration. Writing routines could be just one use case.

         

        ~Kavindra

        (0) 
  10. Jerry Wang

    Hello Mamta,

     

    Thanks a lot for your awesome document! Jsut would like to contribute some tips from my part: In my daily life, the user parameter listed below makes my life easier when trying to debug IPC related code in CRM backend

     

    /wp-content/uploads/2015/04/clipboard1_691866.png

    Best regards,

    Jerry

    (0) 
  11. James Barnhart

    Hello Mamta, Great Blog you have shared. This is very nice document with complete CRM pricing tricks. This is very rare info which you have discussed. As many of them confused with IPC Certification for electronics also.

    (0) 

Leave a Reply