Definition and Usage of 16 Fields in the Pricing Procedure

Contents Introduction .................................................................................................................................................. 2 Step No ...................................................................................................................................................... 2 Counter ..................................................................................................................................................... 3 CTyp - Condition Type ............................................................................................................................... 3 Description ................................................................................................................................................ 4 From .......................................................................................................................................................... 4 To .............................................................................................................................................................. 4 Manual ...................................................................................................................................................... 5 Required .................................................................................................................................................... 9 Statistics .................................................................................................................................................... 9 Print ........................................................................................................................................................... 9 SuTot - Sub Total ..................................................................................................................................... 12 Reqt - Requirement ................................................................................................................................. 13 CalType - Condition formula for alternative calculation type................................................................. 14 BasType - Alternative formula for condition base value ........................................................................ 15 AccKey - Account Key .............................................................................................................................. 15 Accruals ................................................................................................................................................... 17

Introduction In one of my previous posts, we discussed how condition technique works in SAP. There we identified all condition types are grouped in a basket called "Procedure". Same functionality is used in output determination, tax determination, pricing, revenue account determination, listing and exclusion, etc. Today let's see what fields are available in a pricing procedure and the use of each field. You should be able to identify below 16 fields in a standard pricing procedure. They are; 1) 2) 3) 4) 5) 6) 7) 8) 9) 10) 11) 12) 13) 14) 15) 16)

Step No Counter CTyp - Condition type Description From To Manual Required Statistics Print SuTot - Sub Total Reqt - Requirement CalTyp - Condition formula for alternative calculation type BasTyp - Alternative formula for condition base value AccKey - Account Key Accruals

Step No Technical Name: T683S / STUNR This is a 3 digit number which used to define the sequence of conditions within a pricing procedure. During configuration, it is always advisable to keep a gap between two step numbers (Eg: 10, 20, 30, 40, etc). This will allow you to add an intermediate step later if required (Eg: 15, 25, etc)

Counter Technical Name: T683S / ZAEHK This is a 2 digit access number which is used to define a sequence of conditions within one step no. It is same like you define paragraphs called, 1.1, 1.2, 2.1, 2.2, etc in Microsoft word. During pricing determination, system takes the step no as well as counter in to consideration. If you do not have any specific requirement to have multiple counters within a step, then leave the field blank. Then system will take "0" as the counter. Eg: 

Blank value in the field "Counter" -



Define a value in the field "Counter" -

CTyp - Condition Type Technical Name: T683S / KSCHL This is the condition type which you configured for a specific purpose. It can be a pricing condition, tax condition, surcharge condition or a discount condition. You define these conditions in the below IMG node;

-> Condition type data are stored in below tables;  

T685 - Conditions: Types T685T - Conditions: Types: Texts



T685A - Conditions: Types: Additional Price Element Data

Description Technical Name: T683T / VTEXT This is the description of the pricing condition type which you have maintained in the column "Condition Type". For some cases you can specify only a text without a condition type. Eg: Gross Value, Net Value, Rebate Basis, Total, etc. In that case you can directly get the description from the field T683S / VTEXT.

From Technical Name: T683S / STUNB This is the step no which needs to be referenced to get a value for further calculation. Eg:

In the above example, you see step "110" is assigned with from step "100". Therefore when calculating a value for condition "RA01" (in the step 110); the value which is already calculated under step 100 will be used as the basis.

To Technical Name: T683S / STUN2 This is the "To" step number which will be used to calculate total values. Eg: When you have multiple discount conditions in the pricing procedure, you need to use "From" and "To" fields to calculate the total discount amount.

As shown above pricing procedure, there are 4 discount conditions under step 110, 125 and 127. In order to calculate the total discount amount (In step 300), I have used "From step no" 101 to "To step

no" 299. This means all discount conditions that are specified between 101 to 299 (including both 101 and 299) will be totaled to get the final discount amount. Today it will sum step 110, 125 and 127. Any further conditions that will be included later between 101 to 299 will also be included for the total discount calculation. This is very common functionality which we use to sum multiple condition types.

Manual Technical Name: T683S / KAUTO This field is used to specify whether a specific condition type can be determined manually or automatically during sales order processing.  

If you check this box, the condition has to be entered manually (No automatic determination using VK11 conditon master records) If you uncheck this box, then it will be open for automatic determination. If there is a valid VK11 record, system will determine it automatically.

Eg: Scenario 1: Condition J3AP is un-checked in the pricing procedure and there is a valid VK11 record exists

o

Condition automatically determined

o

Condition origin is through automatic pricing

o

Pricing analysis shows the conditon "J3AP"

Scenario 2: Condition J3AP is checked in the pricing procedure and there is a valid VK11 record exists

o

Condition record was not determined during sales order processing (J3AP was missing)

o

Pricing analysis does not even show the conditon "J3AP"

o

When you enter condition type manually in the sales order, value automatically determined from the VK11

o

Now analysis shows the conditon type "J3AP"

Therefore marking this tick box will let user to enter the conditon type only as a manual condition or not. Note: It is very important to keep in mind that the setting which you have made in the conditon type definition will have priority over this setting in the pricing procedure. Let's say in the condition type configuration, you have setup Manual entries as "D - Not possible to process manually" and in the pricing procedure, you mark the tick box for "Manual". In such a scenario, system will not allow you to enter this condition manually in the sales order as condition is configured to block manual entries.

If you try to enter it manually, then you get below error message;

Therefore please make sure to use/change condition types according to your requirement

Required Technical Name: T683S / KOBLI This tick box is used to set certain conditions mandatory. For example, we have to set tax conditions with this tick box. This will avoid sales order processing without those mandatory conditions. In such a scenario you will get a error message as below;

Message no. 8J 399

As you can see above, this message is not an "ERROR" message in RED colour. Therefore user can save the sales order with incompletion status. Therefore you need to make sure your incompletion procedure is configured to handle such cases.

Statistics Technical Name: T683S / KSTAT This tick box is used to mark conditions which are configured for statistical purposes. When you mark any condition as "Statistical", it will not be considered for account determination. Therefore you do not have to assign an "Account key" to such condition types. This is very commonly used for the standard cost condition type - VPRS.

Print Technical Name: T683S / DRUKZ The value you specify in this field is used to specify whether line item can be printed or not in the sales document outputs (Eg: Order confirmation) and at what level it needs to be printed. Please note this is only applicable for standard output types such as BA00 - Order Confirmation. In all custom develop print programs (Z) you can have own logics to display conditions. Below values are possible for use.

Please go through the "F1" help in this field for more documentation. Example, 

Let's see when you do not have any value specified for "Total", how the standard order confirmation output (BA00) looks like;

Output:



Now let's use value "X" for "Total" and see the standard order confirmation output - BA00

Output:

Now you can see an extra line appear in the detail area for "Total". This is because "X" is used to print it in "Item Level"



Now let's use value "S" for "Total" and see the standard order confirmation output - BA00

Output:

Now you can see an extra line appear in the total area for "Total". This is because "S" is used to print it in "Total Level"

SuTot - Sub Total Technical Name: T683S / KZWIW The value you specify here (rather we can call it as a field) is used to capture different sub total values you require for further processing. For example you might need to store the total discount value, rebate basis (Base value for rebate calculation), total, etc of the sales order. SAP standard has delivered those fields for this purpose. In the KOMP structure you can see those as well.

During debugging you can see how these fields are filled as well. For example, in my pricing procedure the rebate basis is assigned with the Sub total "7"

Value "7" is;

During debugging, KOMP-BONBA value is as follows;

In the sales order, below you can see the rebate basis value comes as 600 as well.

Reqt - Requirement Technical Name: T683S / KOBED This field is used to assign ABAP routines which can be used to trigger/suppress condition types based on certain business requirements. For example, if you want to suppress a certain condition type based on the order type, you can create a requirement routine in the transaction "VOFM" which checks the order type in the sales document and set active/inactive flag accordingly. You need to assign this routine to respective condition type in the pricing procedure. During sales order processing, system checks whether the assigned requirement is satisfied or not (SYSUBRC = 0). If it is not satisfied, system will ignore that condition type for processing. In the pricing analysis option you can see it. Check this link to see how to create a new requirement routine Check this link to see How to transport those requirement routines from one client to the other New requirements can be coded in the transaction VOFM under below menu path;

CalType - Condition formula for alternative calculation type Technical Name: T683S / KOFRM Under this field you can assign another ABAP code (Routine) which can be used for the condition type calculation. This is an alternative formula other than the standard formula. You need the help of an ABAP developer to code a new condition formula for your specific business requirement. This is also done under the transaction VOFM under below menu path;

BasType - Alternative formula for condition base value Technical Name: T683S / KOFRA Under this filed you can assign an ABAP formula that can be used to determine the condition basis as an alternative to the standard. This is also ABAP routine which needs to be developed by an ABAP developer. This can be used to define a different base value instead of using it from the "From" column. These also have to be coded in the transaction VOFM under below menu path;

AccKey - Account Key Technical Name: T683S / KVSL1 Under this field you need to assign an account key which will be used later to determine different G/L accounts during postings. This is another key integration point between SD and FI as well. A new account key can be defined under below IMG path;

Under below IMG path, relevant G/L accounts are assigned based on different combinations.

Eg:

Accruals Technical Name: T683S / KVSL2 This is a key which identifies various types of G/L accounts for accruals or provisions in SAP. Using the account key assigned here, system can post amounts to certain types of accruals accounts. For example, rebate accruals which are calculated from pricing conditions are normally posted to the corresponding account for rebate accruals using the account "ERU"

These keys are also defined under below IMG Path;

Author: Anupa Wijesinghe E-Mail: [email protected] / [email protected] Website: www.learnsaptips.com View my profile in LinkedIn Follow me on Twitter

Disclaimer This article is done based on my research and readings, unless otherwise stated. The views expressed are my own and not of anyone else. Author accepts no liability for the content of the articles in this website or for the consequences of any actions taken on the basis of the information provided. Using this information is at the users own discretion and responsibility.