Condition Table

Introduction
It is the definition of the key of the condition record._

Features
 Condition records are always created using a specific key.
 Use tables for help in defining the structure of condition record keys.
 The most important fields used in pricing at header and item level are available in the standard
system.
 As of R/3 Release 4.5, you can also add non-key fields to the condition tables. This is the case, for
example, in condition table 144, which is used within the price book (condition type PBUD).
*The key fields of a condition table must appear at the start of the table, in other words, non-key
fields must not appear between any two key fields.

Access Sequence
Access Sequence:>> The access sequence determines the sequence in which the condition records
for a condition type are found and read.
>> An access sequence (search strategy) is defined for each condition type (with the exception of
header and manual only condition types) in the pricing procedure.
>> This search strategy defines the sequence in which the system reads the condition records for a
condition type.
>> Each access performed during the access sequence is made using a condition table.
>> A condition table is a combination of fields, which form the key for a condition record.
>> You can make an access dependent on certain requirements.
>> You can define prices, discounts, and surcharges at various levels.
>> Each level is defined by a combination of fields or by a field in a condition table.
>> Using the access sequence, you can define the sequence of the different levels.
The system attempts to determine the condition records in the sequence specified.
>> Within each access of an access sequence, you can specify the specific document field (source
field) with which an access is carried out.
>> Examples:
--> Material or pricing material?
--> Document currency or local currency?
--> Sold-to party or ship-to party?
>> Make accesses dependent on requirements to avoid unnecessary accesses. This reduces the
system load.
>> Access sequence: A search strategy to locate the proper condition record.
Condition Types:
In pricing, Condition type determines the category of a condition and how it is used.
The first and forthmost thing is Condition class and it can be:
Prices

Discount or surcharge

Expense reimbursement

Taxes

Going further we will discuss few the things controlled at condition type for Pricing.

SECTION - CONTROL DATA 1

Condition category
It can be :
Tax

Freight

Price

Cost
Calculation type
It can be
Percentage

Fixed amount

Quantity

Gross weight

Net weight

Volume

Formula

Percentage included

Percentage (travel expenses)

Per mille

Points

Quantity - monthy price

Quantity - yearly price

Quantity - daily price

Quantity - weekly price

Commodity Price

Distance-dependent

Number of shipping units

Multi-dimensional

SECTION - MASTER DATA

Condition update
This indicator controls whether limit values are relevant for pricing.
For example, you can to provide a special price for first 10 orders. By this you can make the use of a
particular condition record in the document dependent on a specified total value. This total value
can be specified in the condition record.

SECTION - SCALES
For example,
The following is the tabular representation of scale data for price condition type:
Number of Material Order Price Currency Per Remarks
Ordered UoM Unit

1 EA 800 USD per EA if quantity is ordered between

1-9 EA

10 EA 750 USD per EA if quantity is ordered between

10-99 EA

100 EA 700 USD per EA if quantity is ordered is above

100 EA

Scale basis
Possible scale basis types and its relevant calculation types
Scale Base Types Calculation Types

Value Percentage from an initial value Fixed amount

Quantity Amount per unit of measure

Weight Amount per unit of weight

Volumes Amount per unit of volume

Time period Quantity per unit of time

Check Value
Checking rule for scale rates indicator indicates whether the scale rates must be entered in
document should be:
None

A Descending

B Ascending

H3. Scale type

This indicator controls the validity of the scale value or percentage. It can be:
Indicator Description

can be maintained in condition record

A Base-scale

B To-scale

C not used

D Graduated-to interval scale

Scale Formula
This for formula or routine for determining the scale base value.
You can use this formula to specify calculation methods that are not provided in the standard
system.For this you can write routine with the help of an ABAPer.
This can be very handy if in case you want to have scales based 3-dimensional parameters.
SECTION - CHANGES WHICH CAN BE MADE
Manual Entries
This indicator controls the priority of determination for condition in pricing.
It can be:
Indicator Description System Behaviour

Blank No limitations No limitation

A Free Freely definable

B Automatic entry has In case a condition record exists, the condition cannot be
priority entered manually

C Manual entry has When you enter the condition manually, the system does not
priority check whether a condition record exists

D Cannot be processed In any case, system will not determine this manually
manually

Indicators - "changes which can be made"

Indicator Scope of chage/Changes can be made during document processing

Delete Scope for changing rate or deletion of condition from document

Amount/percentage Condition rate of change

Value Scope for changing the value

Qty relation Scope for changing conversion factors for UoM

Calculat.type Calculation type can be changed

Item Condition
This indicator indicates that whether the Conditions can be entered at the document Item level and
therefore this is particular to that item only. For example, Condition type PR00.

Header Condition
Conditions can also be entered at the document header level. These are known as header
conditions and are valid for all items.
These header conditions are automatically distributed among the items based on net value.
The basis for distributing the header conditions can be changed in the pricing procedure by
selecting the appropriate routine (e.g. weight, volumes) in the AltCBV (alternative formula for
condition base value) field.
Incase of Condition type RB00, the value is copied to all line items. For Example: Condition Type
RB00 is maintained with value $ 50 & there are 4 line items, then all 4 line items each will be
populated with the value $ 50.
Incase of Condition type HB00, the value is distributed to all line items. For Example: Condition Type
HB00 is maintained with value $ 50 & there are 4 line items, then the value $ 50 is divided in all 4
line items propotionately.

SECTION - CHANGES WHICH CAN BE MADE

Manual Entries
This indicator controls the priority of determination for condition in pricing.
It can be:
Indicator Description System Behaviour

Blank No limitations No limitation

A Free Freely definable

B Automatic entry has In case a condition record exists, the condition cannot be
priority entered manually
C Manual entry has When you enter the condition manually, the system does not
priority check whether a condition record exists

D Cannot be processed In any case, system will not determine this manually
manually

Indicators - "changes which can be made"

Indicator Scope of chage/Changes can be made during document processing

Delete Scope for changing rate or deletion of condition from document

Amount/percentage Condition rate of change

Value Scope for changing the value

Qty relation Scope for changing conversion factors for UoM

Calculat.type Calculation type can be changed

Item Condition
This indicator indicates that whether the Conditions can be entered at the document Item level and
therefore this is particular to that item only. For example, Condition type PR00.

Header Condition
Conditions can also be entered at the document header level. These are known as header
conditions and are valid for all items.
These header conditions are automatically distributed among the items based on net value.
The basis for distributing the header conditions can be changed in the pricing procedure by
selecting the appropriate routine (e.g. weight, volumes) in the AltCBV (alternative formula for
condition base value) field.
Incase of Condition type RB00, the value is copied to all line items. For Example: Condition Type
RB00 is maintained with value $ 50 & there are 4 line items, then all 4 line items each will be
populated with the value $ 50.
Incase of Condition type HB00, the value is distributed to all line items. For Example: Condition Type
HB00 is maintained with value $ 50 & there are 4 line items, then the value $ 50 is divided in all 4
line items propotionately.
 16 Fields in Pricing Procedure and Their Description
Define Pricing Procedure
 A pricing procedure is a procedure by where in which you control the execution of condition tyoes
in a sequence you would like . It not only executes the condition types but also controls the
execution of condition type by the use of requirements , altcv. altcbv, account key.
 In other words, Pricing procedure is a systematic and sequential use of condition types to arrive at a
right value of the product.
To determine the pricing procedure SALES AREA (Sales Organization + Distribution Channel +
Division) + CUSTOMER PRICING PROCEDURE (from Customer master) + DOCUMENT PRICING
PROCEDURE (from Sales Doc type)
To view a select the pricing procedure in SPRO which is the standard and copy it and create our own
pricing procedure.
 Highlight it and double click the Control icon in the LHS screen.
 We can see that there are 16 columns in the pricing procedure, these are going to be used by the
system to control the condition types.
 The detail description of each column is given below:

1. Step:
 Number that determines the sequence of the conditions with in a procedure.
 It indicates the position of the condition type in pricing procedure.
 Ex.: 10, 15 etc.
 2. Counter:
 System uses the counter to count the steps and also it can be used to count mini steps of same
condition types. So that number of steps can be reduced in the pricing procedure and hence
enhancing the system performance.
 Access number of the conditions with in a step in the pricing procedure.
 During automatic pricing, the system takes into account the sequence specified by the counter.

3. Condition Type:
 It represents pricing element in pricing procedure as a base price, discount, freight and tax.
 The condition type is used for different functions. In pricing, for example, the condition type lets
you differentiate between different kinds of discount; in output determination, between different
output types such as order confirmation or delivery note; in batch determination, between
different strategy types.
 Ex.: PR00 - Price, K004 - Material Discount, K005 - Customer/Material Discount, K007 - Customer
Discount.

4. Description:
 System copies description of condition type from its description (V/06).

5. From and 6. To:

1. From: This can be used as a base to the condition type for calculating further value.
2. From and To: The range between the steps from and to can be used to specify the range
between same condition types. So that depending upon the condition type, the system deducts or
adds the total value of those condition types from specific common source.

7. Manual:
 This indicator specifies whether the specific condition type can be determined manually during
sales order processing.
 If we check the box then the entry is going to be manual, if we uncheck it, it is going to be
automatic.
 For Base Price and Taxes, the entry should be automatic.
 For Discounts and Freights, The entry should be manual.
 If we check the box, in VA01 when we go to conditions at the header/item level, the condition type
will not be listed. If we require we will have to manually enter it.
 If we uncheck the box, in VA01 when we go to conditions at the header/item level, the condition
type will be listed.

8. Mandatory:
 This indicator specifies that particular condition type is mandatory in the pricing procedure.
 If we check the box, then in VA01 at the header/item level in the conditions tab, if we delete the
value in the condition type and try to save the document then system will not allow us to do it and
throws an error.
 If we uncheck the box, then in VA01 at the header/item level in the conditions tab, if we delete the
value in the condition type and try to save the document then system will allow us to save it,
without giving any error.
 Mandatory check box should be checked in condition types which are compulsorily required in
pricing procedure. Ex.: PR00, MWST.
 If the condition type is checked with mandatory option, then value should be maintained for that
condition type, otherwise the system will not allow the user to process the document.

9. Statistical:
 This indicator if it is activated will not allow the value of the condition type to be taken into net
value calculation.
 It is used only for information purposes only.
 This indicator causes a surcharge or discount to be set in the document statistically (that is, without
altering the value).
 This is commonly used for condition types
 SKTO - Cash Discount
 VPRS - Cost (Moving average price/Standard Price).

10. Print:
 The value of this field specifies whether line item can be printed or not in the sales document and at
what level it is to be printed.

11. Subtotal:
 The value of this field determines where the values of subtotals to be captured i.e. in which table
and which field.
 Controls whether and in which fields condition amounts or subtotals (for example, a customer
discount or the cost of a material) are stored.
 If the same fields are used to store different condition amounts, the system totals the individual
amounts.
 These condition amounts or subtotals are used as a starting point for further calculations. You may,
for example, want a subtotal of all the discounts included in the pricing of a sales order.

12. Requirement:
 It is a routine that is written by an ABAP consultant according to the business requirement.
 By defining Requirement in condition technique we can restrict the access of condition type.
 To understand the concept, we will take the example of the Rebates. Rebates are to be included
during the billing document processing and not in the sales document processing. As rebates are
given on the delivered quantity and not on the ordered quantity (in case of cut-off period for
rebates).
 For rebates we use the condition types BO01 to BO05, and in the Requirement column we give the
value 24 which is "Only in Billing Document".
 This Requirement will ensure that these condition types will appear only during the billing
document processing.
 If new Requirements are to be defined we follow the procedure given below.
 Go to T.Code: VOFM. - Maintain Requirements & Formulas
 Click on the "Requirements" in the top menu and then click on "pricing".
 We have a list of requirements, we can ask ABAP consultant to create new requirement based on
the client requests.
 And we assign the application type like V - Sales/Distribution etc.

14. AltCty - Condition formula for alternative calculation type:

 It is again a Routine that is written by ABAP Consultant.
 It is an alternative formula for the condition type that can be used instead of standard formulas.
 For example, let us take the Profit Margin which can be both + / - , so here this routine will help us
in generating the value which can be either + or -. Profit margin is not a condition type so it cannot
be classified as +ve or -ve in the V/06.
 Ex.: 950 0 Profit Margin 11.
 So we assign 11 - Profit Margin.
 If new routines are to be defined we follow the procedure given below.
 Go to T.Code: VOFM. - Maintain Requirements & Formulas


 Click on the "Formulas" and then on the "Condition Values".
 We have a list of routines, we can ask ABAP consultant to create new routines based on the client
requests.
 And we assign the application type.

15. AltCBV - Alternative formula for condition base value:

 Formula for determining the condition basis as an alternative to the standard.
 It is again a Routine that is written by ABAP Consultant.
 It is used as a basis to calculate value of the condition type instead of using it from the "FROM"
column.
 Ex.: Freight - KF00.
 Freight is calculated based on weight, volume etc. and not on the base price. In pricing there is no
entry of weight from which the value can be referred like we do for discounts using base price. We
have to get the value from the Material master.
 In this column we can mention the value as 12 - Gross Weight or 13 - Net Weight.
 During pricing, the system will consider the value that is mentioned in this column and determine
the freight based on this value.
 Suppose we have Net weight: 100 kgs and Gross Weight: 150 kgs. And if we mention 13 in this
column then the Freight condition KF00 will be calculated using the weight as 100 kgs.

16. AcyKy - Account Key/ Accrls - Accruals:

 The values of the Sales Revenues, Sales Deductions, Freight Revenues, Tax Revenues, and Rebate
Accruals etc. are going to be posted in the respective G/L accounts in Fi Module.
 In order to do this we assign account keys/ accruals to the different condition types based on their
classification. The classification shown below.
 ERB Rebate sales deduct.
 ERF Freight revenue
 ERL Revenue
 ERS Sales deductions
 ERU Rebate accruals
 For Ex.,
 For all Price condition types like PR00 etc. we assign ERL - Revenue.
 For all Discount condition types like K004, K005 etc. we assign ERS - Sales Deductions.
 For all Freight condition types KF00 etc. we assign ERF - Freight Revenues.
 For all Rebates condition types BO01 to BO05 we assign in Account key ERB - Rebates Sales
deductions and for Accruals ERU - Rebate Accruals.
 This account keys and accruals are in turn assigned to respective G/L accounts. So the system posts
respective values in respective G/L accounts in Fi-Co Module.
 This also one of the areas of SD - Fi Integration. SD consultants assign the account keys and Fi
Consultants assign the respective G/L accounts in T.Code:VKOA.
 Pricing Procedure - Introduction
 Pricing procedure: A sequential list of condition types and subtotals.

 All condition types permitted in pricing are contained in the pricing procedure.

 You determine how the system is to use conditions by specifying requirements for each condition.

 The sequence in which the system accesses conditions in the business document is also determined
here.

 The reference level provides a method to specify a different basis for the condition type calculation
and for grouping conditions for subtotals.

 The pricing procedure can contain any number of subtotals between gross and net price.

 You can mark a condition type in the pricing procedure as being:

- a mandatory condition
- a manually entered condition
- for statistical purposes only
Pricing Procedure Determination & Overview:

 In this example, an order for 120 pieces of a material is created. The system must determine the
price automatically.
 First, the relevant pricing procedure is determined based on the sales area, customer, and sales
document type.
 The system reads the condition type of the first step. It determines the assigned access sequence
for this condition type.
 The system reads the access sequence. The sequence of condition tables represents the search
strategy for finding the relevant condition record.
 Each condition table represents one access which can be made for a condition record with the
specified key.
 The system searches for valid condition records with the key specified by the condition table
(accesses).
 If the first access does not find a valid condition record, then the system searches for the next
access using the next condition table.
 Once the system finds a valid condition record for an access, it reads the condition record and
copies the value that corresponds to the scale into the sales document.
 The whole process is repeated for each condition type until the system has finished the entire
pricing procedure.

Pricing Configuration:
 The condition table contains the keys that can be used for creating dependent condition records.
 You can add your own condition tables using table numbers 501 through 999.
 An access sequence is composed of one or more condition tables.
 After creating the access sequence, it is assigned to a condition type.
 You can also create your own condition types. You determine the characteristics of each condition
type, for example, whether it is for surcharges or discounts and whether it should be dependent on
values or quantities.
 The condition types are combined in the required sequence in the pricing procedure.
 Finally, you need to maintain the procedure determination table for the pricing program.
The pricing procedure is determined according to:
- Sales area
- Customer pricing procedure field in the customer master
- Document pricing procedure field in the sales document type.
Pricing Procedure in SD
Pricing Procedure is indeed an heart of SD module, reason being if everything else is working fine,
but price is not being calculated correctly, the purpose of billing fails.
An Overview of Determination & Configuration of Pricing Procedure is as follows:
In SD, Pricing Procedure (TCode OVKK) is determined based on :
Pricing Sales + Distribution + + Customer + Document
Procedure = Organization Centre Division Pricing Pricing
Procedure Procedure

Sales Area is determined in Sales Order Header Level. Customer Pricing Procedure is determined
from Customer Master - Sales Data - Sales Tab - Pricing Section. Document Pricing Procedure is
determined from Sales Document Type (TCode VOV8) / Billing Type (TCode VOFA) (if configured).
Once the pricing procedure is determined, Condition records are fetched. If appropriate condition
records are found, the price is determined. If Mandatory pricing condition is missing, system will
through an error message.
In SD, the steps to configure Pricing procedure are as under:
Step 1:
Condition table (TCode V/03, V/04 & V/05): If existing condition table meets the requirement, we
need not create a new condition table. Considering the requirement for new condition table, the
configuration will be done in SPRO as follows: IMG - Sales & Distribution - Basic Function - Pricing
Control - Condition Table (select the required fields combination, which will store condition record).
Step 2:
Access Sequence (TCode V/07) : If existing access sequence meets the requirement, we need not
create a new access sequence. Considering the requirement for new sequence, the configuration
will be done in SPRO as follows: IMG - Sales & Distribution - Basic Function - Pricing Control - Access
Sequence (Access sequence is made up of Accesses (Tables) & the order of priority in which it is to
be accessed. Here we assign the condition table to access sequence.). So, we can say that the access
sequence is a search strategy which the System uses to search for condition records valid for a
condition type. We create new or modify an existing access sequence follow rule "Specific to
General" while maintaining the accesses for the access sequence by specifying the condition tables
in the desired sequence. For example,
Step 3:
Condition Type (TCode V/06) : If existing condition type meets the requirement, we need not
create a new condition type. Considering the requirement for new condition type, the configuration
will be done in SPRO as follows: IMG - Sales & Distribution - Basic Function - Pricing Control -
Condition Type. It is always recommended to copy an existing similar condition type & make the
necessary changes. Here we assign Access sequence to Condition type.
Step 4:
a. Pricing Procedure (TCode V/08) : It is recommended to copy a similar pricing procedure & make
the necessary changes in new pricing procedure (Note: It should suffice business
requirement). Pricing Procedure is a set of condition type & arranged in the sequence in which it has
to perform the calculation. Considering the requirement for new Pricing Procedure, the
configuration will be done in SPRO as follows: IMG - Sales and Distribution - Basic Function - Price
Control - Pricing Procedure - Maintain Pricing Procedure.
b. Pricing Procedure Determination (TCode OVKK) : After maintaining the pricing procedure the
next step will be determination of pricing procedure. Configuration for determining pricing
procedure in SPRO is as follows: IMG - Sales and Distribution - Basic Function - Price Control - Pricing
Procedure - Determine Pricing Procedure.
Step 5:
Condition record (TCode VK11, VK12, VK13) : Condition record is a master data, which is required
to be maintained by Core team / person responsible from the client. During new implementation,
the condition records can be uploaded using tools like SCAT, LSMW, etc. It is assumed that
document pricing procedure, customer pricing procedure , ... and other required config &
Determination are in place.
Cost Condition
VRPS:
n In the standard version, condition type VPRS is used to retrieve the standard cost of the
material.
n It is used as a statistical value by the pricing procedure.
n Using condition category G, VPRS accesses the valuation segment of the material master
locating either the standard cost or the moving average cost, as specified in the material master.
n Condition category S will always access the standard cost, while condition category T will always
access the moving average cost.
n The profit margin is calculated using formula 11 in the pricing procedure. This formula subtracts
the cost from the net value 2 subtotal.

SKTO:
n In the standard system, condition type SKTO is used to retrieve the cash discount rate.
n It is used as a statistical value by the pricing procedure.
n Table T052 is accessed using condition category E and an amount is calculated from the first
percentage rate of the item payment terms.

EDI1 & EDI2:

n The customer expected price can either be entered manually in the order, or retrieved from the
incoming IDoc in an EDI environment.
n Condition type EDI1 is used to compare the net price for each item. Condition type EDI2 is used
to compare the overall item value (net price * quantity).
n Calculation formula 9 is assigned to condition type EDI1 in the pricing procedure. This formula
tests for a maximum deviation of 0,05 currency units.
n Calculation formula 8 is assigned to condition type EDI2 in the pricing procedure. This formula
tests for a maximum deviation of 1.0 currency units.
n If the customer expected price differs from the automatically determined price or value by more
that the maximum difference allowed, the system will regard this order as incomplete when it is
saved.
n You may process lists of orders having differences in prices, allowing the system to use or
correct the price it determined.
VPRS, EK01 (Actual Cost) and EK02 (Calculated Cost)
Condition Type VPRS, EK01 and EK02VPRS (Internal
Cost):
It cost is mainly used to determine whether the material is having the standard price or moving
average price.
The condition type VPRS is labeled as a statistical condition in the pricing procedure.
in this, using the condition category G, the condition type VPRS goes into the valuation segment of
the material master and determines from here the standard or average price.
The condition category S always accesses the standard price whereas condition category T always
accesses the average price.
EK01 (Actual
Cost):
It is used to is used to post actual price. If you use this condition type, the result of unit costing is
issued to the first position on the conditions screen for the item. The value can be used as a basis
for price determination. It is mainly used for cost-plus contracts in which the sales price depends on
the expected costs.
It is selected for sales document type TA (standard order). This means that the value from the cost
estimate goes directly into pricing. A surcharge is calculated from this value and the net value for
the sales order item is calculated. It will be positioned in the first step of all the condition types in
Pricing procedure and the values are given manually.
EK02 (Calculated Cost):
It is used for statistical posting. If you use this condition type, the result of unit costing is simply a
statistical value which you can compare with the price. So, this can be can used instead of VPRS to
calculate the profit margin for the assembly item.
Please note the following points:
1) The condition type must have condition category 'Q' (costing).
2) The condition type must agree with the condition type defined for unit costing in the pricing
procedure.
So, EK01 & EK02 are the condition type that will display the results of the unit costing for certain
type of sales document and can be used in Make To Order scenario.
Sales order cost estimate can be flow to COPA. Where you have to maintain setting in COPA in
Define access to Standard cost estimate for costing key select sales order cost estimate.
For transfer SD to COPA you have to use Transaction KE4I here enter SD conditions with COPA Value
fields.
So, whether EK01 or EK02, these will determine from Requirement class configuration.
Requirement class in turn there is requirement type and requirement type is determined by item
category and MRP type when you cost a sales order (valuated/non valuated sales order) at that
time when save the cost estimate then the cost value automatically gets populated in your
condition tab. Hence, if the item is not relevant to sales order costing then the cost comes from
VPRS.