 What is condition table in pricing procedure in sap mm?

A Condition table is defined as a combination of keys to identify an individual

condition record. A condition record is defined as how system stores the specific
condition. Example of a Condition Record − Entering the price of a product or to
specify the discount for a privileged customer.
 What is access sequence in sap mm pricing procedure?
The access sequence enables the system to access the data records in a particular
sequence until it finds a valid price. In this example, the sales department may want
to use the most favourable price for a certain customer. For this reason, it ensures
that the system searches for a customer-specific price.
Example
A sales department may offer customers different kinds of prices. The department
may create, for example, the following condition records in the system:
A basic price for a material
A special customer-specific price for the same material
A price list for major customers

 What is condition type

A condition type is a representation in the system of some aspect of your daily
pricing activities. For example, you can define a different condition type for each
kind of price, discount or surcharge that occurs in your business transactions.

 What is calculation schema?

A calculation schema is a structure in SAP that logically combines a number of
different pricing conditions that should come appear one after another in a
purchasing document. You can configure various calculation schemes and include
different SAP MM pricing conditions in them.
What is Schema group?

Group for calculation schema (vendor): - Determines which calculation schema

(pricing procedure) is to be used in purchasing documents containing this vendor
number.

Use: - You can use the schema group to specify the calculation schema per
purchasing organization or vendor. The relevant calculation schema is determined
by reference to the schema group.

The effect of this is that the conditions to be maintained in a purchasing document

can differ depending on the relevant purchasing organization or vendor.
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.

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.

Condition Type:

u2022

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.

Description:

u2022

System copies description of condition type from its description (V/06).

From and 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.

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.

Mandatory:

u2022

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.

Statistical:

u2022

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).

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.

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.

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.

AltCty - Condition formula for alternative calculation type:

u2022

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.

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.

u2022
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.

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.