Professional Documents
Culture Documents
The term pricing is used broadly to describe the calculation of prices (for external use by
customers or vendors) and costs (for internal purposes, such as cost accounting). Conditions
represent a set of circumstances that apply when a price is calculated. For example, a particular
customer orders a certain quantity of a particular product on a certain day. The variable factors
here - the customer, the product, the order quantity, the date - determine the final price the
customer gets. The information about each of these factors can be stored in the system as master
data. This master data is stored in the form of condition records.
V/06 - Create new condition types by copying a similar conditions type and changing it
according to your needs.
Click on the Pricing Procedures e.g. PR0000 - Condition Supplements for PR00
Click Control - e.g. Tick Mdt if you want the condition type to be mandatory
o OV34 - Define account key
o OV35 - Assign account key
Actky - Revenue account
Accrls - Accruals account
OVKK - Determine which Pricing Procedures to use for which Condition Type.
You can add additional decimals for a currency through a work around method.
Set up a currency let's say instead of USD call it US$ ( OY03 ) and define the number of decimal
places ( OY04 ) to be 3 or more depending on your requirement.
Maintain the exchange rate for between US$ and USD to be 1 to 1 ( OBBS and OB08 ).
Create pricing condition records for those customers requiring 3 decimal places using Current
US$ instead of USD.
That will give you 3 decimal places for your prices. However, one thing you will have to watch
out for is rounding.
You can try transaction OB90, define rounding rule for currency. Here you define the rounding
rule for your customer's currency.
4.6x
e.g. You create an order type ZP00 for QT - Quotation and does not wish it to be used in OR -
Standard Order.
IMG - Sales and Distribution -> Basic Functions -> Pricing Control -> Define and Assign
Pricing Procedures
Define document pricing procedure
e.g. Q - Quotation
Users will receive Message no. V1 206 "Condition ZP00 is missing in pricing procedure A V
ZQT".
4.6x
In VK12, click the Key Combination button. You can see a list of available key combination for
your price master.
Now, let create a new key combination e.g. Customer + Sales Document + Material
IMG - Sales and Distribution -> Basic Functions -> Pricing Control -> Define Condition
Tables -> Create condition tables
e.g. 900
Selected fields
Sales organization
Distribution channel
Customer
Sales document
Material
Click Generate to activate it
IMG - Sales and Distribution -> Basic Functions -> Pricing Control -> Define Condition
Tables -> Defince Access Sequences -> Maintain Access Sequences
IMG - Sales and Distribution -> Basic Functions -> Pricing Control -> Define Condition
Tables -> Defince Access Sequences -> Optimize accesses
Finally, goto VK12 and key in the new price master for PR00.
Next, goto VA02 and test out the material. If it didn't work check the pricing date in the header
details. Is the pricing date within the validity period?
=== For a particular customer if you need a unique price, then create a condition table with field
customer. Put this condition table in the pricing sequence.
Since this sequence is assigned to the pricing condition, Create record for this codition table
(Price) This will ask customer number and price for that customer.
Sandeep Budhraja
=== I hope you might have done pricing in SAP SD before this if not, pl follow the steps which I
am giving next:
2. copy a condition type which is sutible for your requerment . by using v/06 or IMG PATH
WHICH I HAVE GIVEN IN STEP ONE
4. assign access sequence to conditiona type and condition tabel to access access sequence .
5. finale create your only pricing procedure by using condition type like price , discount, tax etc
see the standard condition pricing procedure rvv001 . attech this procedur to pricing
determination with your sales area.
Now go to VK11 and create pricing condition record by using customer / material.
and also discount and tax recards and save them
After creating your pricing procedure and records you creat a sales order wiht the same sales area
and order type which you atteched to pricing determination and give a material code and quentity
and press enter
4.6x
To convert the old Pricing Condition with the release status use program
SD_MOVE_A004_TO_A304.
For the standard tables, the following pairs of condition tables are intended to be used:
'old' <--> 'new' VAKEY fields
A004 <--> A304 VKORG + VTWEG + MATNR
A005 <--> A305 VKORG + VTWEG + KUNNR + MATNR
A006 <--> A306 VKORG + VTWEG + PLTYP + WAERK + MATNR
A007 <--> A307 VKORG + VTWEG + (SPART) + KUNNR
For example, if you are using A005 --> A305, you have to copy the program to
ZSD_MOVE_A005_TO_A305 and amend the program Source and Target table.
First test run by ticking both option. If you confirm that there are no errors, then run by
unticking both options.
Be careful while executing the conversion program as it can erase all your existing pricing
condition data.
Once the conversion is completed, you can activate the Customer/Material with release status :-
IMG -> Sales and Distribution -> Basic Functions -> Pricing -> Pricing Control -> Define
Access Sequences -> Maintain Access Sequences
In VK12, you will be able to choose the new Customer/Material with the release status column
per material.
Hiding condition type VPRS - OSS note 105621
We are wanting to implement an OSS note 105621 that will check authorizations and keep
condition type VPRS from being displayed. I have done most of the note, but am a bit
confused by part of it.
It also tells you to create two new includes: ZZAUTH01 and ZZAUTH02, but it doesn't tell
you what changes to actually make in any of these. I am assuming that the authority checks
have to be added somewhere, but what goes where?
The coding for includes ZZAUTH* are (create them in SE38 like INCLUDE, and althought note
say that dev.class must be VF, I have them with own dev.class ie: Z**, and it works)
include ZZAUTH01
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
*& Object REPS ZZAUTH01
*& Object header PROG ZZAUTH01
*&---------------------------------------------------------------------*
*& This object has been generated from an advance correction *
*& attached to a R/3 note. *
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
*& Title: Authority check for displaying fields *
*&---------------------------------------------------------------------*
***INCLUDE ZZAUTH01.
* Beim ersten Aufruf ist KOMV initial; OLD_KOMK löschen,
* damit auf jeden Fall Berechtigungsprüfung durchgeführt wird.
* Sicherheitshalber zunächst Berechtigung verweigern.
* if komv is initial.
IF SCREEN-NAME = 'FCODE'.
CLEAR OLD_KOMK.
AUTH_SUBRC = 4.
ENDIF.
***INCLUDE ZZAUTH02 .
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
*& Object REPS ZZAUTH02
*& Object header PROG ZZAUTH02
*&---------------------------------------------------------------------*
*& This object has been generated from an advance correction *
*& attached to a R/3 note. *
*&---------------------------------------------------------------------*
*&---------------------------------------------------------------------*
*& Title: Authority check for creating new conditions *
*&---------------------------------------------------------------------*
***INCLUDE ZZAUTH02.
AUTHORITY-CHECK OBJECT 'Z_KONH_KLS'
ID 'ZKALSM' FIELD KOMK-KALSM
ID 'ZSTUNR' FIELD KOMV-STUNR
ID 'ACTVT' DUMMY.
IF SY-SUBRC NE 0.
MESSAGE E609(VH).
ENDIF.
* Ende Berechtigungsprüfung
...
*&---------------------------------------------------------------------*
In my system (46B) I remember that the subroutines USEREXIT is not changed for this
purpose. With SU21 (z_konh_kls I think that you don't have problems), like with SU02.
In su02, remember that in XU180-PROFILE of first dynpro, you must populate with value
'ZCOND_STD' and click on create work area for profiles. Double click on zcond_std. In object
populate with 'Z_KONH_KLS', double click and you see the parameters like in tcode PFCG
(profiles and auth.)
For procedure you can populate with the procedure (see tcode V/08 ) that you use in your SD
documents, or the procedure/s in where you want that the restriction will work, if you have many
procedures.
For level, you must write the ranges of levels in this procedures (into V/08 ) that you want that
the user can see (remember that alpha routine conversion dont works, ie: for level ' 1' [in dynpro]
you must write '001', if not, you will have problems). The levels out of this ranges, the user with
this profile when go to conditions in SD document will not see the value of these items.
Finally, in SU01, add this profile to profiles created with PFCG in 'profiles'.
If you are an SD consultant (you are one, yes?), you should know your tables and fields. Because
you can't do a lot of customizing without that.
But if you want an example here goes. Say, you want to base your pricing procedure on first
three digits of product hierarchy, defined in the material master, via condition technique.
Pricing structure for line item is KOMP. A quick look thru KOMP structure (tx SE11) shows that
you have only PRODH field for all 18 digits of product hierarchy, whereas you need only the
first three. So you do the following:
1. Create the new data element ZZPRODH1. Also create a domain with the length "3" and the
data type "CHAR" for the new data element. Remember that new data fields must start with the
letters "ZZ" or "YY", since SAP reserved these letters to protect them from being overwritten
during a release upgrade.
2. Check whether the product hierarchy (PRODH) is found at header or at item level. In table
VBAP, document field PRODH is defined as an item field.
3. Integrate the field name ZZPRODH in the communication structure KOMP using the
INCLUDE KOMPAZ and allocate the data element PRODH to it.
6. Assign a value to the new field in the FORM routines for sales order processing and billing
using the appropriate user exits: In sales order processing the user exit is found in member
MV45AFZZ. The complete statement is:
FORM USEREXIT_PRICING_PREPARE_TKOMP.
MOVE VBAP-PRODH(3) TO TKOMP-ZZPRODH. ENDFORM.
The routines for assigning a value to the new fields in billing are found in member RV60AFZZ.
The statement is as follows:
FORM USEREXIT_PRICING_PREPARE_TKOMK MOVE
XVBRP-PRODH(3) TO TKOMP-ZZPRODH. ENDFORM.
7. Allocate the specifications A, V and 001 to the field ZZPRODH in table T681F. Use "E" has
been added for fields in rebate processing.
This is a standard example from SAP Library. In this case you must tell the ABAP three things:
- that your source field is VBAP-PRODH,
- that you need to get the first three digits from that field into your pricing structure KOMP
- and that you need to specify the transfer by user exit thru MV45AFZZ
Please note that this is a very simple example. Quite often you have to dig a lot deeper.
Modifications of Copy Control routines, making output forms (thru SapScript) and such requires
you to know all the necessary tables, structures and fileds.
The only advice I can give you is to use tx SE11, which will show you the organisation of a
table/structure, and can also help you check the contents of a specific table in a specific sales doc
-------------------------------------
Here are the Steps for Variant Configuration
1.Create a Material of your Motor Cycle using Material type KMAT(MM01).
2.Then create a characteristic called ZColour(SAP has a standard Characteristic for this but it has
multiple values-i.e you can select more than one colour for your Bike.If you do not want that
create your own)with character format and assign single value radio button on the initial
screen.Go to values Tab and give the colours you need.save the characteristic.Similarly repeat
for CC(I figure this CC as 100cc & 200cc kind of thing.If you want these as materials then it is a
different story-I am taking this as feature as well)
3.Create a class called Zbike with the above 2 characteristics.save the class
4.Create a configuration profile Zbikeprof using Cu41 and assign the Kmat material to Class
Zbike,
5.Then create the order and Enter the Kmat material you want in the Order.
John Devraj.
-------------------------------------
In variant configuration I have configured my material properly during sales order creation it is
selecting proper characterstics. but my question is pricing should calculate at characterstics level
not at header level.
Ugamesh.
-------------------------------------
Pricing in variant Configuration is done at the Header level only.The logic is that you create
pricing variant keys for each characteristic Value.This will be done at the Header level using
cond type VA00.based on the characteristic chosen the appropriate price according to the pricing
variant key will be picked up.
John Devraj.
-------------------------------------
Here my question is with out creating the materials is it possible to get price based on the
characterstics.
I am working on variant configuration here my product is 9-100. i have created characterstics for
describing colours. this characterstics assigned to class, this class is assigned to 9-100(KMAT
type). here i have not created amterial to describe each colour.
Now how I need to setup my system to calculate the price based on colour.
Ugamesh.
-------------------------------------
A cool Question. It will really get us into the thick of things in Variant Configuration.
1.Create a Characteristic called ZColour(Standard SAP has a characteristic called colour.I did
not use it.)
Give your values.
Say, Red & Blue
3.Link both these characteristics to the Class(The class which you have attached the KMAT
Material).
4.Go to VK11 and the Enter VA00.Then give the values RED and BLUE and enter the values.
John Devraj.
-------------------------------------
Here are some clarifications required from you.
what is the significance of item category group 0002 and 0004. Apart from these are they any
other item category groups are available for configurable materials ?
In BOM header material having components. is it possible to make the component as
configurable material.
Ugamesh.
-------------------------------------
The difference b/w 0002 and 0004 is basically that of LUMF & ERLA.
In 0002 the pricing happens at the Header Item Level.
In 0004 the pricing happens at the Sub Item Level.
Check out the Item category Assignments and things will be Clear.
I think these two are the only ones used for Configuration.
Please let me know in which Scenario you would like to have the configurable material Inside a
BOM(as it would help me in visualising thh Item Category Assignment).
John Devraj.
-------------------------------------
As you said I setup my system to calculate price based on colour.
ZCOLOUR contains all colours in values tab page.
ZPRICE contains table name and filed name in additional data tab page.
when am creating the sales order price is coming only for RED colour not other colours. even
price is maintained for all the colours.
Ugamesh.
-------------------------------------
Seems like there is a mistake in the line $self.ZPRICE = 'RED' (You have said you have given
this for all the values- If I have not mistaken). This refers only to red colour.
John Devraj.
A. STEP
This indicates the number of step-in the procedure.
B. COUNTER
This is used to show a second ministep
C. CONDITION TYPE
This is the most important component in the pricing procedure. The rates are picked up from this
element, on the basis of the properties described.
D. DESCRIPTION
This forms the description of the condition type.
E. FROM
This is used to define the progression of the calculation and range of subtotals
F. TO
This is used to define the progression of the calculation and range of subtotals
G. MANUAL
This function enables to allow the condition type to be entered manually also apart from
automatic pickup.
H. MANDATORY
This function identifies the conditions that are mandatory in the pricing procedure. The sales
price is a mandatory condition type.
I. STATISTICS
This can be used to represent the cost price of the material sold, generally used for study
statistical impacts of price
J. PRINT
The activation of this function will enable the printing of the values and conditions to the
document.
K. SUBTOTAL
A key is assigned from the drop down menu; this can be used by the system in other area like Sis
for reporting purpose also
L. REQUIRMENT KEY
This function is used to assign a requirement to the condition type. This requirement can be used
to exclude the system from accessing the condition type and trying to determine the value. This
can be used to specify that the condition type should only be accessed if the customer has a low
risk credit.
M. ALTERNATE CALCULATION TYPE
This function allows you use a formula as an alternative in finding the value of the condition
type, instead of standard condition technique. this can be used to calculate complex tax
structures.
N. ALTERNATE CONDITION BASE VALUE.
The alternative condition base value is a formula assigned to a condition type in order to promote
an alternative base value for the calculation of a value.
O. ACCOUNTS KEY
The account keys form part of account determination. These keys are used here to define the
posting of the revenue generated to respective account heads& to subsequent assignment to GL
accounts.
PR00- ERL
K007/KA00- ERS.
KF00- ERF………….& so On.
P. ACCRUAL KEY.
The accrual keys form part of account determination. These keys are used here to define the
posting of the revenue generated to respective account heads& to subsequent assignment to GL
accounts and payment to respective parties.
Amol Wani
I shall give an example. But you should first identify the field for Profit Center (Design ID) and
then do as follows:
For example if you want to use field PSTYV ('Sales document item category') that is included in
structure KOMP ('Pricing Communication Item') as a key for a condition table.
When you create a condition table (Transaction V/03), however, the system does not propose the
field in the field catalog.
Prerequisites:
For technical reasons, field PSTYV was included in structure KOMP, however, not in structure
KOMG ('Allowed Fields for Condition Structures').
1. Call up the ABAP Dictionary (Transaction SE11) and create data type ZZPSTYV. Choose
PSTYV as a domain.As a short text, you can use, for example, 'ZZ - sales document item
category' and as a field label, you can use the field labels of PSTYV.Save, check and activate
your entries.
2. Call up structure KOMPAZ in the ABAP Dictionary (Transaction SE11) in the change mode
and make the following entry:
Component Component type
ZZPSTYV ZZPSTYV
4. Call up Transaction SPRO. Navigate to 'Sales and Distribution -> Basic Functions -> Pricing
-> Pricing Control' and execute 'Define Condition Tables'. Choose 'Conditions: Allowed fields'
and include ZZPSTYV as a new entry.
5. Note:Now you can use field ZZPSTYV as a key field when you create a condition table Axxx.
6. Supply the new field you defined by including the following source code line in
USEREXIT_PRICING_PREPARE_TKOMP:
In order processing you find the user exit in Include MV45AFZZ, and in billing document
processing you find it in Include RV60AFZZ.
Consider that you can also use this note as a help if you want to use other customer-specific
fields as key fields in a condition table.For header fields, use structure
KOMKAZ instead of structure KOMPAZ and USEREXIT_PRICING_PREPARE_TKOMK
instead of USEREXIT_PRICING_PREPARE_TKOMP.
For more information, see Transaction SPRO via the path 'Sales and Distribution -> System
Modifications -> Create New Fields (Using Condition
Technique) -> New Fields for Pricing' and Note 21040.
1) There are almost all the regularly used Conditon Table predefined in the system from 001 to
500.
See what best you can use the Standard Tables to avoid further errors.
d) Double click on the fields you want to make a Table..one by one. Note that the sequence here
is important in higher hierarchical to lower..
Eample : Sales Org, DC, Division, Customer and then Material etc..,
e) After selecting, click on the Techincal View buttin (redone) and reach to next screen.
7) Check which key should be in header and which key should be footer. Use check and
uncheck functionalities there..
8) Once you are through with all the above steps ..click on generate button.
Generally in the Pharma industry this procedure is adopted becuase all the goods are batch price
based.
1. In the Pharma Industry whenever the goods are manufactured it will done in a batch to keep
track and price is fixed, I mean there will be a Batch Master which has a certain price fixed for it.
This Batch Master will have certain number of batches . These batches will have the number
series generated wither by internal or external generation depending upon the client requirement
2. So till all the batches are produced as per that particular Batch Master will have the same
price. Like that there will n number of batches will different different prices
3. So when you are preapring Sales Order you be only putting the tenative price for the goods
that are sold
4. Then at the time of delivery we will be picking up the goods from different batches basing on
the required delivery quantity and finally we do the PGI.
5. This is called Delivery Based Pricing becuase your price for the goods will be determined at
the time of the delivery as the goods picked up from the different batches which have different
prices. ( Mind it there will very less difference in the prices).
6. So at the time of Billing the Pricing Procedure behaves differently depending upon the
differnent batches that are picked basing on the batch determination.
7. So the prices which are detemined from different batches will be the actual prices at which
the goods are billed to the customer along with other condition that are applied as required
There are two simple reasons for making any Pricing Procedure in SAP SD Modules.
1) Business Reason. What are the pricing aspects or strategies you want to apply for the client
requirement in order to sell their
goods or render services, is all about the reason for various pricing procedures.
You have your own conditions intended to few transactions only. Put all this conditions as a set
defining your own Procedures. It may even include special requirements and formulas applied
for such Pricing Procedures.
As a example 1, you need to have a Pricing procedure for condition supplement inorder to use
the condition supplements. The condition supplement pricing procedure must be given in the
condition type definitions (v/06) of the Pricing Condition where you need to supplement, without
which SAP SD Condtion Supplements functionality doesnt work.
As a example 2, you need to have a Pricing procedure for Inter Company Billing
Conditions(IV01 & IV02) inorder to be active for Inter Company Billing specific transactions.
Thus make sure that, the procedure wouldnot apply for non-Inter company transactions.
In V/08 of defining a new Pricing Procedure, in main screen, you have a field called TSPP
(Transaction Specific Pricing Procedure). This has to be ticked on for Intercompany Billings.
Before Release 4.0A, no special pricing procedures were used for intercompany billing and
rebate credit memos, programs were just set accordingly to deal with these situations. As of
Release 4.0A you are offered greater flexibility in the form of the option to define special pricing
procedures for intercompany billing and rebate credit memos. For reasons of future
compatability, you will still be able to use the old program specifications. For this reason, you
must set this indicator if you want to create a special pricing procedure. This is to prevent the
program settings being used.
This indicator is also used as of Release 4.0A to redetermine the condition class and the
statistical condition indicator when copying from a reference document.
Example:
You copy prices from a shipment document to the billing document. The prices should lead to a
surcharge in the billing document. This is guaranteed by the redetermination of the condition
class in the pricing procedure.
Same case with Standard Pricing procedure or Inter Company Pricing Procedure.
How to configure pricing procedure to choose only one among the different condition type?
ECC 6 - Exclusion group Customizing is in the following IMG path (transaction SPRO):
Sales and Distribution > Basic Functions > Pricing > Condition Exclusion > Condition Exclusion
for Groups of Conditions Carry out the following steps:
Then the required condition types are assigned to the exclusion groups, for example:
Finally, define the required exclusion rules for each pricing procedure. In this case, you can
create exclusions in accordance with the following predefined rules (KAUVF field):
- 'A' - Selection of the most favorable condition type within a condition exclusion group
- 'B' - Selection of the most favorable condition record of a condition type if several condition
records exist (for example, selection under various condition records of the condition type PR00)
- 'C' - Selection of the most favorable of the two condition exclusion groups (in this case, all of
the condition types of the two groups are cumulated and the totals are compared with each
other).
- 'D' - "Exclusive" procedure: If any of the condition types of the first group exists on the item,
all of the condition types of the second exclusion group are excluded.
- 'E' - Similar to 'B', but with the most unfavorable condition record.
- 'F' - Similar to 'C', but with the more unfavorable condition exclusion group.
The actual exclusion rules for a pricing procedure are maintained with a sequence number and
completed by specifying the exclusion rule and the affected exclusion group(s):
The information in section 3 also applies here: If conditions were excluded from FORM
XKOMV_AUSSCHLUSS, a 'second' (final) valuation of the pricing result takes place once
again (FORM XKOMV_BEWERTEN), in order to update the pricing result based on the
exclusions made. In this case, conditions with inactivity indicator 'A' are no longer valuated.
Note:
a) Since the exclusion of a condition may influence the condition basis and therefore also the
condition value of follow-up conditions, a condition or exclusion group that was more favorable
(more unfavorable) than another condition or exclusion group after the preliminary valuation
may have been more unfavorable (more favorable) after the final valuation. See also the
following example.
In such a case, another exclusion or valuation based on the last valuation is NOT triggered. This
procedure could result in a continuous loop (the "flip flop effect"). For more information, see
Note 217009.
b) In the R/3 standard system, conditions with a zero condition value do not participate in
exclusions according to exclusion groups. However, you can change the system response in such
a way that conditions with a zero condition value also participate in exclusions.
To do this, add the value formula 038 (Include FV64A038), or a corresponding user-defined
value formula that contains the source code from value formula 038, to the pricing procedure
used for a condition that will definitely be part of the pricing result.
c) Conditions that the condition exclusion indicator (see section 2) already fully excluded from
the pricing result of an item no longer participate in exclusions according to exclusion groups. As
a result, you can no longer use rule 'D' to exclude the conditions of another group.
d) Exclusion group Customizing should not be maintained randomly, but rather with care. If
exclusion group Customizing is so extensive that you can no longer comprehend the formation of
the 'final result', it is time to reconsider the relevant business process.
Example:
In accordance with exclusion rule 10, the discounts ZD01 and ZD02 are excluded from the G001
exclusion group since conditions were determined from the G002 exclusion group with the
discounts ZD03 and ZD04.
In accordance with exclusion rule 20, discount ZD03 (condition value EUR -9.50) excludes
discount ZD04 (condition value EUR -9.10) since ZD03 is the more favorable discount in the
G002 exclusion group.
After you create the exclusion and the conditions have been valuated again, you finally receive
the following final pricing result: