Condition Technique in SAP
Condition technique is THE most pervasive and a very flexible methodology used by SAP to aid the consultant in configuring complex business rules. Some modules ( SD, MM ) are more dependent on it than others. We are taking Pricing as an example here, but will not enter into the domain of Pricing (which is pretty large by itself ). This article is also useful for consultants working in other modules like FICO who might require an understanding of Condition Technique before they understand Pricing
What is Condition Technique
Condition Technique is an SAP configuration technique/methodology that is used to configure complex business rules. Consider it as a rules engine. For example, in SD it is used across multiple functionalities – Pricing, Outputs, Texts etc. In MM the same technique is used to configure Schemas ( Same as Pricing ).
Why is Condition Technique Used
Condition technique is used when a complex, ever-changing set of business rules need to be configured as generically as possible in the system. Nothing could capture the essence of this statement more than the complex rules that businesses use to Price their products/services. For example, in pricing, each organization has their own set of business rules including base price, margins, discounts, taxes, surcharges, deals/promotions, price lists etc. For a single system to be generic enough to cater to all of these complex needs is a challenge in itself and that is exactly what condition technique tries to solve.
Condition Technique at a Very High Level
There are 7 key components of Condition Technique. Not all of the components are used all the time. But it is beneficial to learn all of them just in case you want to solve complex problems like pricing. .
Field Catalog consists of all the possible set of fields that play a role in determining the business rules
Condition table is a database table that is created from a small subset of the field catalog as part of the customization.
Access sequence comprises of a sequence of condition tables prioritized in a particular order.
Each condition type represents a logical component of the condition technique. For example, excise tax could be one of the logical components of pricing and it could be represented using one condition type or a combination of multiple condition types.
A procedure is a combination of multiple condition types. For example, in output determination procedure, all the sequence of condition types might exist – Like EDI, Print, Fax etc.
Finally the procedure is assigned to the final document type that is effected by the business rule.
It may not make much heads or tails just yet. But continue to read and you will be surprised how simple and powerful this is. Condition technique could be learnt either bottom up or top-down. However, we are trying to explain it here using the bottom-up approach. Also, it is much easier to explain condition technique using a standard SAP functionality as an example. We will take the most complicated example/use ( Pricing ) and that way all of the aspects of the condition technique will be covered. The menu path to be followed is under [ SPRO -> Sales & Distribution -> Basic Functions -> Pricing ].
Field catalog consists of all the possible fields that will play a role in affecting the business functionality. Please remember that this transaction is Cross-Client . Click on “Define Field Tables” and double click on “Conditions: Allowed Fields”
The list of available fields will be shown. These fields are got from the following structures. You can add new fields from any of the standard pricing communication structures
- KOMP ( Line Item level Pricing Communication Structure )
- KOMK ( Header Level Pricing Communication Structure )
- KOMG (Combination of the above structures )
If your business requires that new fields ( not available in the above communication structures ) be available in the field catalog, then they need to be added to the structures in either of the .INCLUDE or .APPEND components.
Without complicating things further, lets move forward to Condition Table.
Condition Table is an actual transparent database table that is created from the list of fields selected from the field catalog. Lets look at an already existing condition table. Click on “Display Condition Tables” and select 005 . This is the condition table for Customer/Material.
As you can see, this table contains the fields “Customer” , “Material” ( Forget about Sales organization and distribution channel for now . They are common fields ).
Click on the button “Technical Overview” and you will get the detailed table-like view of the condition table.
Creating a table is just as simple. Pick a number ( Above 500 and less than 1000 – because the name of the actual database table will be prefixed with A . So if you create a number say 701, an actual database table will be created with the name A701. You can verify the same using table browser SE16 ). You have a choice of either copying from the existing table and adding more fields or creating a completely new table. Let’s start by creating a new condition table – say 899.
Start by entering the number 899 and hit enter. You will be shown a empty column to the left and list of available fields from the field catalog on the right. If you want to select one of the fields, just double click it. There is no scroll-bar to move down, so position your cursor on the right column and hit page-down to see more fields. Fields that were already added will be highlighted in blue in the field catalog. For example, in this case, we have chosen country as the field.
Now lets generate the condition table. Hit on the “Generate Table” button in the application tool bar. SAP will show a log of the table generated ( A899 ).
An Access Sequence is virtually a sequence in which the condition tables are accessed to determine which parameter to consider. For example, in pricing, if you want the discount per material to over-rule the discount per customer , then you would position the discount per material condition table above the discount per customer table.
Click on “Define Access Sequence” and then choose “Maintain Access Sequence”. Once again please remember that an access sequence is Client Independent as well.
As discussed before, an access sequence consists of
Access Sequence -> Accesses ( Condition Tables ) -> Fields (of the condition table )
Lets explore the Access Sequence A001
Select A001 and double-click on “Accesses”
As you can see, the Access Sequence “A001” consists of condition tables – A005, A007, A006, A004 in that order.
You can explore the fields in the corresponding condition tables by selecting any of them and double-clicking on fields. There are other fields that effect how the access sequence performs, but that is currently outside of the scope of this primer.
Condition type is a very important component of condition technique. Condition types form the basis for procedures. The logical sequence of arrangement is as follows. While the condition table aggregates fields in the field catalog, an access sequence aggregates condition tables and lays them down in a sequence. A condition type however is just associated to an Access Sequence ( It does not Aggregate ) . The role of an condition type is to determine the type rather than determine something from a sequence of steps.
Condition Type -> Access Sequence -> Condition Tables -> Fields
Lets take the simple example of PR00 ( The basic price condition type ).
Double click on it to know more about its controls.
The first of the control being its attachment to the access sequence ( In this example, the condition type PR00 is attached to Access sequence PR02 ).
The rest of the data is very specific to Pricing and will not be in the scope of this article.
A procedure is an aggregation of multiple condition types.
Procedure -> Condition Type -> Access Sequence -> Condition Tables -> Fields
For example, click on “Maintain Pricing Procedure” and then search for “RVAA01” which is the standard pricing procedure used.
Double click on Control Data to know more about the different condition types aggregated under Procedure. This is the most complicated screen of condition technique for pricing, but other areas like output determination, text determination are pretty simple.
While the procedure itself determines the sequence of condition types to evaluate the rules, the procedure determination involves determining the right procedure to be used for the specific scenario. For example, this step determines under what circumstances the procedure RVAA01 needs to be used as the pricing procedure to evaluate pricing for that document
As you can see from the picture below, RVA001 will be used as the pricing procedure when the conditions ( The Sales Organization should be “0001”, distribution Channel should be “01” , the division should be “01” and the document pricing procedure should be “A” and the customer pricing procedure should be “1” ) – Which is another way of saying under a particular sales area, for a particular sales order type ( for eg., contracts ) , and a customer type ( say wholesale customer ) , use the logic in procedure “RVAA01”