Define Pricing Procedure

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.
Step:
Number that determines the sequence of the conditions within a procedure.
It indicates the position of the condition type in pricing procedure.
Counter:
ystem uses the counter to count the steps and also it can be used to count mini steps of same condition
types. o that number of steps can be reduced in the pricing procedure and hence enhancing the system
performance. !ccess number of the conditions within a step in the pricing procedure.
"uring automatic pricing# the system ta$es into account the sequence specified by the counter.
Condition Type:
It represents pricing element in pricing procedure as a base price# discount# freight and ta%.
The condition type is used for different functions. In pricing# for e%ample# the condition type lets you
differentiate between different $inds of discount; in output determination# between different output types
such as order confirmation or delivery note; in batch determination# between different strategy types.
&%.' ()** + (rice
,**- + .aterial "iscount
,**/ + 0ustomer1.aterial "iscount
,**2 + 0ustomer "iscount.
Description:
ystem copies description of condition type from its description 341*65.
From and To:
6rom' This can be used as a base to the condition type for calculating further value.
6rom and To' 7 The range between the steps from and to can be used to specify the range between same
condition types. o 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 chec$ the bo% then the entry is going to be manual# if we unchec$ it# it is going to be automatic.
6or 8ase (rice and Ta%es# the entry should be automatic.
6or "iscounts and 6reights# The entry should be manual.
If we chec$ the bo%# in 4!*1 when we go to conditions at the header1item level# the condition type will not
be listed. If we require we will have to manually enter it.
If we unchec$ the bo%# in 4!*1 when we go to conditions at the header1item level# the condition type will be
listed.
Mandatory:
This indicator specifies that particular condition type is mandatory in the pricing procedure.
If we chec$ the bo%# then in 4!*1 at the header1item 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 unchec$ the bo%# then in 4!*1 at the header1item 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.
.andatory chec$ bo% should be chec$ed in condition types which are compulsorily required in pricing
procedure. &%.' ()**# .WT.
If the condition type is chec$ed 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:
This indicator if it is activated will not allow the value of the condition type to be ta$en 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 3that is# without altering
the value5. This is commonly used for condition types
,T9 + 0ash "iscount
4() + 0ost 3.oving average price1tandard (rice5.
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. 0ontrols whether and in which fields condition amounts or subtotals 3for e%ample# a customer discount
or the cost of a material5 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. :ou may# for e%ample# 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 !8!( consultant according to the business requirement.
8y defining )equirement in condition technique we can restrict the access of condition type.
To understand the concept# we will ta$e the e%ample of the )ebates. )ebates are to be included during the
billing document processing and not in the sales document processing. !s rebates are given on the
delivered quantity and not on the ordered quantity 3in case of cut+off period for rebates5.
6or rebates we use the condition types 89*1 to 89*/# and in the )equirement column we give the value
;- which is <9nly in 8illing "ocument<. This )equirement will ensure that these condition types will appear
only during the billing document processing. If new )equirements are to be defined we follow the procedure
given below.
=o to T. 0ode' 496.. + .aintain )equirements > 6ormulas
0lic$ on the <)equirements< in the top menu and then clic$ on <pricing<.
We have a list of requirements# we can as$ !8!( consultant to create new requirement based on the client
requests. !nd we assign the application type li$e 4 + ales1"istribution etc.
AltCty - Condition formula for alternatie calculation type:
It is again a )outine that is written by !8!( 0onsultant. It is an alternative formula for the condition type
that can be used instead of standard formulas.
6or e%ample# let us ta$e the (rofit .argin which can be both 7 1 + # so here this routine will help us in
generating the value which can be either 7 or +. (rofit margin is not a condition type so it cannot be
classified as 7ve or +ve in the 41*6.
&%.' ?/* * (rofit .argin 11.
o we assign 11 + (rofit .argin.
If new routines are to be defined we follow the procedure given below.
=o to T. 0ode' 496.. + .aintain )equirements > 6ormulas
0lic$ on the <6ormulas< and then on the <0ondition 4alues<.
We have a list of routines# we can as$ !8!( consultant to create new routines based on the client requests.
!nd we assign the application type.
AltC!" - Alternatie formula for condition base alue:
6ormula for determining the condition basis as an alternative to the standard.
It is again a )outine that is written by !8!( 0onsultant.
It is used as a basis to calculate value of the condition type instead of using it from the <6)9.< column.
&%.' 6reight + ,6**.
6reight 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 li$e we do for discounts using base price. We have to get the
value from the .aterial master.
In this column we can mention the value as 1; + =ross Weight or 1@ + Net Weight.
"uring pricing# the system will consider the value that is mentioned in this column and determine the freight
based on this value.
uppose we have Net weight' 1** $gs and =ross Weight' 1/* $gs. !nd if we mention 1@ in this column
then the 6reight condition ,6** will be calculated using the weight as 1** $gs.
Acy#y - Account #ey$ Accrls - Accruals:
The values of the ales )evenues# ales "eductions# 6reight )evenues# Ta% )evenues# and )ebate
!ccruals etc. are going to be posted in the respective =1A accounts in 6I .odule.
In order to do this we assign account $eys1 accruals to the different condition types based on their
classification. The classification is shown below.
&)8 )ebate sales deduct.
&)6 6reight revenue
&)A )evenue
&) ales deductions
&)B )ebate accruals
6or &%.#
6or all (rice condition types li$e ()** etc. we assign &)A + )evenue.
6or all "iscount condition types li$e ,**-# ,**/ etc. we assign &) + ales "eductions.
6or all 6reight condition types ,6** etc. we assign &)6 + 6reight )evenues.
6or all )ebates condition types 89*1 to 89*/ we assign in !ccount $ey &)8 + )ebates ales deductions
and for !ccruals &)B + )ebate !ccruals.
This account $eys and accruals are in turn assigned to respective =1A accounts. o the system posts
respective values in respective =1A accounts in 6I+0o .odule.
This also one of the areas of " + 6I Integration. " consultants assign the account $eys and 6I
0onsultants assign the respective =1A accounts in T. 0ode' 4,9!.