Skip to end of metadata
Go to start of metadata

This article covers some of the basic techniques a pricing consultant should know in order to optimize the performance of pricing and associated functionalities. Though the tips are meant to work or tested at least only for pricing , the concept can be extended to all the processes handled by this technique and hence the title.

Condition types

The most important constituent of the condition technique in pricing is condition technique. Even then, only minimum importance is given to the configuration of the condition type for the influence it can have on the pricing condition technique. Only the most obvious fields are configured consciously neglecting others without realizing the fact that they can play vital role in making the pricing procedure work trim and slim.  

To quote and example the field Plus/Minus configuration can prevent lot of errors in condition types. Problems noticed due to this field are the condition type having a negative value in credit memo, due to sheer negligence of the user. A small change in the configuration considering the functionality supported by the condition type would have save hundreds of such wrong credit memos and the efforts taken in finding them and cancelling them. 

Another way to make report generation simple to follow a convention for the condition types. We followed a norm that base price condition type should always belong to Condition category H, all automatic discounts Condition category X and all manual discounts as Y. This helps a lot in coding at later point of time. These kind of conventions are strictly adhered to in technical objects, but seldom in functional configuration, which leads to lot of hard-coding in reports, proving any newcomer to understand the code very complex and cumbersome. 

The most important way by which condition types can be configured is the usage of the field "Manual entries" and the corresponding "Manual entry only" key in the pricing procedure. A slightly overlooked configuration in these places updates KONV tables with a records with null values. This bloats the size of condition screen, leading to lot of condition types having a value of 0 for an item. This can be controlled very easily by knowing when such null records are created. A cursory overview of the OSS notes 392668 and 1007110 can help to ensure the appearance of condition types in condition screen only with non-null values thus preventing unnecessary entries in KONV. In scenarios like the one I work, where a pricing procedure can have nothing less than 200-250condition types, a simple understanding of the said note helps to optimize pricing to a great extent.

The tab which allows one to configure the possibility of changing the details of condition type in condition screen is one tool which if effectively handled can save the support consultants from any problem. We have encountered problems when sales users just change the value of condition type value in condition screen, and some user from FI complains that condition type updation is not happening from condition records. The problem could finally solved only by blocking the ability to change, though the change history helped most of the times. In summary if a condition type detail should not be overwritten in condition screen, please configure the same in this tab.

Condition tables

This is a component where no amount of expertise makes one perfect. Configuring a condition tables in SAP is much easier than determining the strategy which should decide the value of the condition type. Instead of just asking the user on the fields of condition table and configuring it in the system, a functional consultant should really look into the drivers for the particular condition type.  If this is overlooked, the consultant may end of creating 10condition tables having almost the same fields with only one field difference from each table. To quote an example, we use product hierarchy in 8levels and we have 25 condition tables having only one node of the product hierarchy to all the 8nodes along with either customer or division. If the business driver for the condition types would have been discussed with the users, now we can make use of all the condition types to use only one of the 2condition tables instead of the 25tables we have as of now. Though we have 8levels of Product hierarchy and have combination of various levels of product hierarchy in condition tables, only the first level and at the most the second level decided the condition values almost all the times!!! So the take home for this is not to consider condition table as another technical object, but to be considered as one of the business driver which controls the costs and prices of the materials. Thus create highly optimized (table with minimum number of fields), reusable, essential condition tables which will reduce the search criteria much simpler in condition technique.