Welcome to today's SCM Forum on enhancing your pricing techniques in SD and MM.

We invite you to post your questions on standard and custom pricing configuration and to get tips and advice from Rajen Iyer, 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?

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

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

Hello, Rajen

When is it appropriate to use calculation type -G for

condition types?

 

 

Sep 8, 2011 -- 12:43PM, Allison wrote:

Hi Rajen,

Thanks for the taking the time to answer our questions today. Are there specific troubleshooting tools for debugging pricing?

Thanks,

Allison

Pricing analysis debugging is one of the tools used to analyze pricing from a technical perspective. Breakpoints help in setting up where to debug the code. To test whether a requirement is working correctly, a breakpoint is set on the requirement ABAP code. When the sales document is created, the debugger stops at the break- point.

 

The analysis of the field values reveals whether the requirement is functioning as designed. quoting an example of computer sales company, let’s assume that the gross price calculation is enabled only when the desktops are shipped from certain manufacturing plants. By debugging the requirement, you can check if the requirement is activated only for certain manufacturing plants.

 

Similarly, a condition formula and condition-based formula can also be debugged. These pricing conditions in the document represent the price that is agreed on with your business partner.

 

Sep 8, 2011 -- 12:53PM, Gary Byrne wrote:

Hello, Rajen

When is it appropriate to use calculation type -G for

condition types?

 

 

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