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) Step No
2) Counter
3) CTyp - Condition type
4) Description
5) From
6) To
7) Manual
8) Required
9) Statistics
10) Print
11) SuTot - Sub Total
12) Reqt - Requirement
13) CalTyp - Condition formula for alternative calculation type
14) BasTyp - Alternative formula for condition base value
15) AccKey - Account Key
16) 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 (SY-
SUBRC = 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: anupaw@gmail.com / anupaw@learnsaptips.com
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.