Transcript from recent Q&A on pricing configuration with the co-author of “Effective Pricing in SAP ERP”
Pricing rules are getting more complex, so how do you configure automated pricing processes that meet unique business requirements and conditions – but without excessive customization? SCM Expert author Rajen Iyer recently took questions in the SCM Forum here on Insider Learning Network on the topic on pricing for SD and MM. In addition to his tips and articles for SCM Expert he is also the coauthor of the SAP PRESS book Effective Pricing in SAP ERP.
Rajen offered tips on pricing and customer hierarchies, performance tips, and retroactive pricing with STOs.
For the full Q&A, you can view the questions and Rajen’s responses in the SCM Forum, or read excerpts from the transcript of the Q&A below.
AJ Whalen (moderator): Welcome to today’s SCM Forum on enhancing your pricing techniques in SD and MM.
Rajen Iyer is coauthor of Effective Pricing in SAP ERP. Rajen is also a logistics and global trade services expert and can provide insights on integrating pricing into your financials systems and into customer- and vendor-facing applications.
Thank you, Rajen, for joining us today and taking questions over this next hour. Before you respond to the questions coming in, I’d like to start with one that stems from your recent interview: What is the most effective way of using Customer Hierarchy Pricing?
Rajen Iyer: Customer hierarchies are defined as logical representations of customer organizations. Large organizations may have customers belonging to different departments that are buying at different negotiated prices.
A customer hierarchy provides the flexibility of defining a customer’s organization more effectively. Transaction VDH2N is used to display a customer hierarchy. The menu path for defining customer hierarchies is Logistics > Sales & Distribution > Master Data > Business Partner > Customer Hierarchy > Edit.
For example, a customer can have sales organizations or locations on the East Coast and West Coast. The customer may be running a pricing promotion on the East Coast. SAP ERP provides the flexibility to define pricing by using hierarchies. In other words, it is possible to have a different pricing for the East Coast organization versus the West Coast organization even though they belong to the same customer.
The customer can be given a different discount based on the region the customer belongs to. To set up customer hierarchies, hierarchy nodes must be cr
eated. Hierarchy nodes can be set up using the menu path Logistics > Sales & Distribution > Master Data > Business Partner > Hierarchy Node > Create or Transaction V-12.
For example, Customer ABC can have a 15% discount in the North area and a 10% discount in the South area. If no discount is defined at the lower level, then the discount at the higher level is taken into consideration.
Customer hierarchies are represented by special pricing elements or condition types. HI01 is the pricing condition used to represent discounts by percentage. HI02 is the pricing condition used to represent discounts by amount.
Allison: Hi Rajen, Thanks for the taking the time to answer our questions today. Are there specific troubleshooting tools for debugging pricing?
Rajen Iyer: In this example, the customer organization is represented by two hierarchy nodes: Global Customer Hierarchy Node and North Hierarchy Node. The Global Customer Hierarchy Node has one customer assigned to it (Global Customer) and the North Hierarchy Node has one customer node assigned (North Customer). North and Global can have different pricing discounts because they belong to different hierarchy nodes.
SAP ERP has provided standard pricing discounts that can be used with customer hierarchies:
– HI01: Customer Hierarchy % Discount
– HI02: Customer Hierarchy Discount Amount
To model percentage discounts, we will use HI01. To use this pricing discount, ele- ment HI01 must be defined at hierarchy node 100020 and 100029. The discount defined at hierarchy node 100029 will override the discount defined at 100020.
Customer hierarchy pricing provides the flexibility of defining a pricing discount at the global hierarchy node level (i.e., hierarchy node 100020) and also at the regional level (i.e., hierarchy node 100029). All customers associated with regional hierarc
hy node receive the regional discount, and all customers who belong to the global hierarchy node receive the discount at that level.
To make this happen, you define different discounts for pricing element HI01 at the regional and global level.
GaryByrne: When is it appropriate to use calculation type -G for condition types?
Rajen Iyer: When “G” is assigned to a condition type in the pricing procedures that contains the affected condition type, usually a condition basis formula and a condition value formula must be assigned to this calculation type. But if the condition basis is not important, or if both the condition basis and the condition value are determined within one condition value formula, you don’t have to use a condition basis formula. For example, condition type KUMU (cumulative condition type) is defined with calculation type “G” and uses the formula (condition formula calculation rule) “36” to calculate cumulating conditions in any pricing procedure that uses KUMU.
The cumulative net column calculates the net value of the product by adding all of the component line items and the header.
Let’s take an example of a consumer electronics sales company example for a moment. If the computer has additional accessories, the keyboard and mouse are represented by line items 0020 and 0030, respectively. The desktop price is represented as the cumulative price of the desktop (Item 0010), keyboard, and the mouse (i.e., $150 + $25 + $25 = $200).
Bette Ferris: Hi Rajen,
When it comes to promotional pricing and sales deals, can you explain the difference between the two from the SAP system’s perspective – and the right configuration
approach to take for each?
Rajen Iyer: Promotions can be applied
to a range of products or to specific products. A promotion can have several sales deals. Promotions are all set up as agreement types in the SAP ERP system. A sales deal targets specific products and provides better focus to selling products. Sales deals can be offered in various ways, such as material discounts or customer discounts.
Promotions are short-term plans to increase sales of products and services, usually by targeting wholesalers and retailers. Promotional pricing can include promotions or sales deals.
As the name suggests, promotional pricing is a marketing plan to sell products. For example, a sportswear company wants to get rid of last year’s inventory, so they decide to offer a 5% discount in the pricing of all men’s leather shoes. This requires setting up a promotional pricing for leather shoes in the SAP ERP system.
Promotions can cover a range of products or only specific products. A promotion can have several sales deals. Promotions are all set up as agreement types in the SAP ERP system. SAP ERP uses agreement types to differentiate between promotions and sales deal.
Laura Casasanto: What’s your best advice for teams struggling to optimize pricing performance amid increasingly complex pricing rules and data?
Rajen Iyer: Performance is one of the most important aspects of pricing, and optimizing involves looking at several aspects of pricing for improvements. As SAP ERP installations and implementations mature, complex business processes are implemented. It’s important to have a set of rules not only during initiation of the project but also during the ongoing implementation and enhancements. This not only ensures better performance but also helps reduce the total cost of ownership. As a general rule, the following considerations will improve pricing performance:
– Eliminating unwanted pricing conditions types
– Selecting the Exclusive indicator on access sequences
– Preprocessing
– Increasing the number of condition types and minimizing access to condition tables
– Minimizing user exits
Antoine Cadot-Wood: Hello Rajen, thanks for being here today.
I have a question from a customer: What are your tips and best practices to avoid rounding errors and discrepancies?
Rajen Iyer: Rounding rule is part of the condition value set up. This setting helps in either rounding the condition value up or down, or in determining a value according to business standards. For example, if the condition type value is 10.459, it rounds up to 10.46. On the other hand, if the value is 10.454, and the rule is commercial, then the value is rounded down to 10.45.
Rounding rules are driven by specific needs concerning whether the pricing condition value has to be rounded up or rounded off, which can vary by business processes and standards. For example, if the price is set at $101.7 for 1000 units, and the customer is interested in buying only 10 units, then the price is $1.017. The rounding rule can be applied to round up the price to $1.02.
If the Rounding rule is set as Commercial, the value is rounded off. For example, if the value is $10.454, then the value is rounded off to $10.45.
Another best known practice is the use of rounding differences. Rounding differences are calculated. You can maintain a rounding unit in table T001R for each company code and currency. If the final amount in the order header differs from the rounding unit, the system rounds the amount up or down as specified. Condition DIFF determines the difference amount. Condition type DIFF is a group condition and is distributed among the different items according to value.
Hope this helps!
Scott Wallask: H
i Rajen —
Good discussion here. Any tips and best practices on applying condition exclusions?
Rajen Iyer: There are different flavours of exclusions, let me touch on them briefly:
The Exclusive indicator controls whether the system stops searching for a record after the first successful access for a condition type within an access sequence. By checking the Exclusive indicator within the pricing procedure requirement, the search for condition records will stop as soon as the appropriate condition record is found. The search does not continue to next sequence.
The above can be applied to a business case, say a customer has already received a favorable price, then he is not entitled to receive additional discounts. Sometimes in pricing for sales and billing documents, more than one condition record may apply to a particular item at any one time. You can use the condition exclusion process to compare possible conditions to determine such things as the best price for a customer.
To build a condition exclusion procedure, you must follow these steps:
1. Define the exclusion groups.
2. Assign condition types to the exclusion groups.
3. Maintain condition exclusions for the pricing procedure.
The following example will help explain the condition exclusion procedure. A customer can receive discounts in various ways. For example, the discount a customer receives can be based on the product the customer is purchasing or based on the high volume of business the customer has been doing with the company.
The various discounts that can be offered (i.e., discounts based on material, customer/material, and so on) are listed here:
– K004: Material
– K005: Customer/Material
– K007: Customer Discount
– K020: Price Group
Let’s take the example of Desktops Inc., who
sells desktops to various customers, including special customers and retailers. The special customer can receive a discount because they belong to a price group (K020 Condition Type) as well as receive a discount because they are eligible for customer discounts (K007 Condition Type). The condition exclusion procedure ensures that the customer receives the most favorable price from the two discounts. It also ensures that the customer doesn’t receive the discount twice.
Condition exclusion groups deal with more than one condition type. The possible variations are described in the following subsections.
Rajuyr: My question is on retroactive billing for Intercompany Stock Transfer business process.
I don’t see a SAP option to reprice the invoices created using ‘price copy from STO (PO)’.
This would have been a great help for businesses using STO (in our case, shared services organization).
Rajen Iyer: You are right about the limitation. Just to understand this better: The invoice is raised against the STO (PO) and not against the delivery note. You could try exploring the following options:
1. Use of invoice against STO delivery note, delivery note pricing and pulling the right value thru the delivery note.
2. Use of Special Value Source within the access sequences > Accesses > Fields, when you maintain the condition.
When you double-click the Fields folder in the Dialog Structure, here, the special value source field can be used to define a different field instead of the proposed source.
Let me know your thoughts!
AJ Whalen: Thanks to all who followed the discussion today!
A full summary of all the questions will be available here in the SCM Forum and in the SCM Group on Insider Learning Network. You can also listen to a recent interview with Rajen with tips and advice on some common pricing issues, including security. For more details on Rajen’s book on pricing, visit SAP PRESS.
The SCM Group also offers ongoing information and additional resources, including tips from SAPinsider’s conferences and ongoing updates about next spring’s SCM 2012 events in
And finally, thank you again to Rajen Iyer of Krypt and Kryaa, for taking these questions today!
Premium
