What Is The Condition Technique In SD Pricing?

For the pricing to be automatically determines in the sales document, we have to make all the following customizing settings.

The pricing is based on “condition technique”. Condition technique comprises of 

1.  Condition Tables 
2.  Access Sequence 
3.  Condition Type 
4.  Pricing Procedure.

Condition Tables

Condition table contains the key fields for maintaining the condition records i.e. condition records of a condition type will be stored in condition tables.  Depending on the sales requirement of the client we can have any field as a key field in the condition table.  

One condition type can have multiple condition tables and if required one condition table can be used for multiple condition types.

Defining condition tables

Tcode: SPRO 
- Sales and distribution 
- Basic functions 
- Pricing 
- Pricing control 
- Define condition tables 
- Create condition tables

Specify a condition table number which must be between 501 and 999

From the field catalogue which contains all the available fields select the required key fields.

While maintaining condition records in order to set the validity period we have to get the fields “valid on” and “valid to”. For this here we need to check the field “with validity period”

Select the button “Technical view”. Here fields which are marked as key appears at key level and the fields marked as footer field appears at footer level while maintaining the condition record.

Select the icon “Generate”.

Select the button “Local object” for saving the Table.

Use of Exclusion Group Customizing to Exclude Conditions

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:

a) Define condition exclusion groups: 
First create one or more exclusion groups, for example:

• G001 Discount group 1
• G002 Discount group 2

This data is stored in the T684 database table.

b) Assign condition types to the exclusion groups:

Then the required condition types are assigned to the exclusion groups, for example:

• G001 Discount Group 1 ZD01 Discount 1
• G001 Discount Group 1 ZD02 Discount 2
• G002 Discount Group 2 ZD03 Discount 3
• G002 Discount Group 2 ZD04 Discount 4

This data is stored in the T684G database table.

c) Maintain condition exclusion for pricing procedures:

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

- 10 D Exclusive G002 Discount Group 2 G001 Discount Group 1 
- 20 A More favorable ... G002 Discount Group 2

This data is stored in the T684S database table.

All exclusion rules except for rule 'D' are based on the knowledge of the condition values of the condition types involved. In accordance with exclusion group Customizing, the condition exclusion is therefore also created in pricing in the FORM XKOMV_AUSSCHLUSS (include LV61AA56)

- after an 'initial' (preliminary) valuation (FORM XKOMV_BEWERTEN, Include LV61AA55) of the pricing result  
- and after the condition exclusion based on the KMANU field

(FORM XKOMV_AUSSCHLUSS, Include LV61AA56)

The exclusion is created with inactivity indicator 'A'.

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:

The aforementioned exclusion group Customizing is valid.  Before an exclusion is created, a document item contains the following preliminary pricing result, which of course is not displayed in this form. In this case, the percentage discount ZD02 refers to the price ZPR0 and the percentage discount ZD04 refers to subtotal 1.

Condtns Amt Condtns Val Inactive

• ZPR0 Price EUR 100.00 1 PC EUR 100.00
• ZD01 Discount 1 EUR 4.00 1 PC EUR - 4.00
• ZD02 Discount 2 5.000% EUR - 5.00

Subtotal 1 EUR 91.00

• ZD03 Discount 3 EUR 9.50 1 PC EUR - 9.50
• ZD04 Discount 4 10.000% EUR - 9.10

Subtotal 2 EUR 72.40

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:

Condtns Amt Condtns Val Inactive

• ZPR0 Price EUR 100.00 1 PC EUR 100.00
• ZD01 Discount 1 EUR 4.00 1 PC EUR - 4.00 A
• ZD02 Discount 2 5.000% EUR - 5.00 A

Subtotal 1 EUR 100.00

• ZD03 Discount 3 EUR 9.50 1 PC EUR - 9.50
• ZD04 Discount 4 10.000% EUR - 9.10 A

Subtotal 2 EUR 90.50

Note that, if subsequently considered, discount 4 would now be more favorable than discount 3, since the exclusion of discounts 1 and 2 influenced the condition basis of the percentage discount 4, but it did not influence the absolute discount 3.

Reasons For Making Any Pricing Procedure in SAP

1. Why we are maintaining separate pricing procedure for inter company sales and business processs. 
  
2.  What is the different between standard and inter company pricing procedure and what type condition type we are using in this intercompany.

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.

Eg: Domestic sales pricing procedure, 
- Export Pricing Procedure, 
- A rebate pricing procedure or 
- A High Discount oriented pricing Procedures. 
- A repair 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.

2) A special pricing procedures, in order to facilitate added functionalities of SAP pricing architecture, we must define new 
pricing procedure. SAP Standard programmes checks these special Indicators in-order to do some required functions.

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.

Eg: KA0000 for Condition Supplement for KA00 
- PR0000 for Condition Supplement for PR00 
- ICAA01 for Inter-Company Billing

Here I would like to remind about a important field in pricing.

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.

The SAP help reads for this field as Under:

Transaction-specific pricing procedure

Pricing procedure transaction-specific indicator

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.

Can Sales Order and Billing Have Different Pricing

During the interview, the interviewer raised one question,  whether the SALES ORDER & BILLING can have different pricing Procedure?

Yes, can have 2 different pricing procedures

1. One for Sales Order 
2. Another at the Billing

Let us take an example :

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.

How To Add New Fields To Field Catalog

I have to add new field "Profit Center(Design ID)" to the field catalog first and then create new condition table for pricing using this field.

1. How to add new field to field catalog? 
2. How to create condition table using that new field?

For adding field into Field catalogue:

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

To solve the problem, proceed as follows:

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

Save, check and activate the change you made.

3. Note:Because of the change in structure KOMPAZ, field ZZPSTYV is now known in structures KOMG and KOMP because structure KOMPAZ is included in both structures.

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:

              MOVE xxxx-PSTYV TO TKOMP-ZZPSTYV.

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.

For creating a condition Table:

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.

2) In case you should define the new condtion Table,

a) Goto TCode: V/03

b) Give a Table any number from 501-999

Press execute and reach to next screen.

c) Check up whether  the field you are looking is already added in Field catalogue.

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.

Check the Table is generated or not.

You can check it at V/04 or V/05 or in SE11.

Meaning of Column in Pricing Procedure

What is the meaning of this column in the pricing procedure ,i.e 
  
1. STEP 
2  CTRSTEP 
3. CTYP 
4. DISCRIPTION 
5. FROM 
6. TO 
7. MAN 
8. Mand 
9. STAT 
10. PRINT 
11. REQUIREMENT 
12. ALCTYP 
13. ALBCTYP 
14. ACKEYS 
15. ACCRUALS

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.

Steps for Variant Configuration and Pricing

I want to configer motercycle having differnt types of colour, each colour have varity of standered feature as wall as differnt CC. while want to create slaes order I want motercyle with speciefic colour, Cc feature. which is not possible while creating BOM it will only be configer by materiel Varient Configration.

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

------------------------------------- 

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.

------------------------------------- 

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.

------------------------------------- 

A cool Question. It will really get us into the thick of things in Variant Configuration.

Here are the steps.

1.Create a Characteristic called ZColour(Standard SAP has a characteristic called colour.I did not use it.) 
         Give your values. 
         Say, Red  & Blue

2.Now create another characteristic called ZCol_surcharge 
Give the description and go directly to Addnl Data Tab.Here in the table name Enter "SDCOM" and in the Field Name Enter "VKOND".The system will pick up the format from the Dictionary.

3.Now go to CT04 and change the Characteristic Zcolour. 
Go to values tab and select RED.Goto Extras-> Object Dependencies->Editor and then select Procedure.

In front of 000010 Enter  $self.ZCol_surcharge='RED'. 
Similarly Select Blue  and enter $self.ZCol_surcharge='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.

5.Go to your order and Enter your material.

------------------------------------- 

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.

------------------------------------- 

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

------------------------------------- 

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.

I went to ZCOLOUR characterstics I maintained (extras-object dependicies-editor-action) there I have given   $self.ZPRICE = 'RED' for all the values.

when am creating the sales order price is coming only for RED colour not other colours. even price is maintained for all the colours.

------------------------------------- 

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.

In front of 000010 Enter  $self.ZCol_surcharge='RED'. 
Similarly Select Blue in the Values Tab  and enter $self.ZCol_surcharge='BLUE'

All this is Case Sensitive. So please be careful.

------------------------------------- 

Now its coming any way thank you very much.

------------------------------------- 

I have been reading your's and ugamesh's mails regarding the same but no where the sales doucments have been discussed as well as material master record and configuration in SPRO.

If you can kindly explain me the same as I was trying to do the same.

------------------------------------- 

There is no need SPRO involvement in Variant Configuration.Everything happens in Easy Access. 
As far as Material Master record is concerned you only need to use a KMAT Material type.

There is no need to assign any sales document to this material.

Follow the steps and you will get the result.

------------------------------------- 

I have gone thru the steps and created a sales order, but the pricing procedure is not coming proper. Also do we have to maintain the values for the ZCol_surcharge. 
As I have already maintain the rates of the color in VK11 - VA00.

------------------------------------- 

Have you maintained the Object Dependencies for the values in the characteristics class.

------------------------------------- 

Yes !

What I have done is created a customer with KMAT ( Car), without characteristics tab pg. After this I created 3 charateristics viz., zcolor, zengine & zcol_surcharge and assigned them to Class 300 ( Variant). 
But I have maintained the dependencies only for Zcol_surcharge : $self.Zcol.surcharge='RED' 
Then I assigned all these to a config profile and aslo added the condition VA00 in the pricing procedure, then maintained the same in VK11. 
Now my problem is it is not coming in the SO

------------------------------------- 

I think the problem is with the characteristics. 
For the characteristics Zcolor and Zengine you must maintain some values in the Values Tab. 
Ex: 
Zcolor-  Red 
            Blue 
Zengine- V6(Right now you can use only one Characteristic for learning) 
             V8

The characteristic Zcol_surcharge(By name this suggests that it is applicable only to colour-Whereas you can use it for other characteristics as well) does not have any values.

For the values maintained in the Characteristics Zcolor and Zengine you have to go to each value(Go to values tab and select Red) and maintain the object dependency "Action"  $self.Zcol_surcharge='RED'. Similarly maintain for Blue,V6,V8 for Example.

Then maintain the condition records for Va00(without any Case mismatch).

Use standard pricing procedure RVAA01.(or a copy- as it has provision for VA00).

This should solve your problem.

Pricing Procedure in Product Hierarchy

Can someone help me with an example of Pricing in Product Hierarchy.

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.

4. Activate the structure.

5. Check in which table the field PRODH exists. 
The field is in table VBAP (sales document: item data).

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.

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 tells you to modify userexits: USEREXIT_FIELD_MODIFICATION, USEREXIT_FIELD_MODIFIC_LEER, 
USEREXIT_FIELD_MODIFIC_KZWI, USEREXIT_FIELD_MODIFIC_KOPF and USEREXIT_PRICING_CHECK.

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.

* Berechtigungsprüfung auf Kalkulationsschema und Stufen-Nr. 
* Beim Wechsel der KOMV-Zeile einmalig eine Berechtigungsprüfung 
* durchführen 
IF KOMK-KALSM NE OLD_KOMK-KALSM OR KOMV-STUNR NE OLD_KOMV-STUNR. 
AUTHORITY-CHECK OBJECT 'Z_KONH_KLS' 
ID 'ZKALSM' FIELD KOMK-KALSM 
ID 'ZSTUNR' FIELD KOMV-STUNR 
ID 'ACTVT' DUMMY. 
AUTH_SUBRC = SY-SUBRC. 
OLD_KOMK = KOMK. 
OLD_KOMV = KOMV. 
ENDIF.

IF AUTH_SUBRC NE 0 AND ( SCREEN-NAME = 'RV61A-SELKZ' 
OR SCREEN-NAME = 'KOMV-KAWRT' 
OR SCREEN-NAME = 'RV61A-AWEIN' 
OR SCREEN-NAME = 'KOMV-KBETR' 
OR SCREEN-NAME = 'RV61A-KOEIN' 
OR SCREEN-NAME = 'KOMV-KPEIN' 
OR SCREEN-NAME = 'KOMV-KMEIN' 
OR SCREEN-NAME = 'KOMV-KWERT' ). 
SCREEN-ACTIVE = 0. 
ENDIF. 
MODIFY SCREEN. 
* Ende Berechtigungsprüfung

for include ZZAUTH02

***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 action you can populate '*'

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

After check if it works.

Delivery Pricing Conditions

Configure the pricing procedure at delivery with the required condition type to determine freight. Also have the copying control from delivery to billing at item level with Price source as D for Delivery. While you execute billing you would get the prices from the sales order as well as from deliveries.

If you were to look at the pricing procedure RVAA01 you will see there was a section dedicated to the various freight charges. Normally, I would use one of the available condition types and create a condition master based on the Incoterms.

Configuration path :-

IMG -> Logistics Execution -> Shipping -> Basic Shipping Functions -> Pricing

Pricing Release Procedures

4.6x

Define Processing Status - SM30 -> V_T686E

You are free to design your own processing status flow. 
e.g. from 01 -> 02 or 
      from 01 -> 02 -> 03

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.

Change a Particular Pricing Procedure

Suppose the client requests to change a particular pricing procedure with respect to a particular customer so what are the steps to go about solving it. 
What is the standard method? 
 

=== 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:

1. create a condition table in necessery by using v/05 or IMG->S&D->BASIC FUNCTIONS ->PRICING ->PRICING PROCEDURE -> CREATE TABLE (first serch is ther any table which is having customer number , name , org, order no and all the requeried fields)

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

3. copy a accecss sequence which u want v/07

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

You will get pricing of that.

Lavanya sudha 
 

Pricing report

Is there a standard SAP report that shows all the sales price for a material/ customer / qty??? 
 

=== Take a look at transaction V/LD or something similar. In the menu path where you maintain the conditions there is also a folder for output and there is this transaction "Pricing report" or something similar.

If you have the transaction and it doesn't "work" you might have to execute report RV14ALLE to get the transaction to work.

If the above transaction doesn't satisfy your needs, you can always configure a pricing report through configuration.

Create a New Pricing Conditions Key Combination

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

Select PR00 - Price 
Click Accesses 
Click New entries

AcNo  Tab   Exclusive 
 50        90      X - Tick

Save your entries

IMG - Sales and Distribution -> Basic Functions -> Pricing Control -> Define Condition Tables -> Defince Access Sequences -> Optimize accesses

Copy an existing PR00 and substitute the AcNo with 50

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?

Control Pricing Conditions based on Order Type

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.

Follows this steps :-

IMG - Sales and Distribution -> Basic Functions -> Pricing Control -> Define and Assign Pricing Procedures

Define document pricing procedure 
e.g. Q - Quotation

Assign document pricing procedures to order types 
e.g.  Assign Q to Order Type QT - Quotation

Maintain pricing procedures 
e.g. Copy Standard Pricing Procedure to e.g. ZQT (all the pricing conditions list will only be allowed in order type QT - Quotation

Define Pricing Procedure Determination 
e.g. Copy and assign Document Pricing Q and Pricing Procedure ZQT accordingly

Users will receive Message no. V1 206 "Condition ZP00 is missing in pricing procedure A V ZQT".

Price with additional decimals

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.

Pricing In SAP SD - Create New Condition Types and Procedure

This configuration is done when user request for new pricing condition type other than the standard ones provided by the system.

Screen to tcode VA01 - Create New Sales Order for customers 
  - Double Click the Item  
      - Then Click the Conditions Tabstrips

Define Condition types

V/05 - Condition Table for V/07 
e.g. a business may no longer wants to have a sales discount based on the sales organization, customer group, and material, but decided that the discount should be based on the sales organization, customer group and material group.

V/06 - Create new condition types by copying a similar conditions type and changing it according to your needs.

• Double click on the condition type to change the control options

V/07 - Access Sequences for condition type

V/08 - Pricing Procedures for condition types. 
The pricing procedure is also used in the account determination.  This determines the general ledger accounts to which prices, discounts and taxes must be posted.

• 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
• OV34 - Define account key
• OV35 - Assign account key
• Actky - Revenue account
• Accrls - Accruals account

OVKK - Determine which Pricing Procedures to use for which Condition Type

Pricing Report & Condition Index

What is difference between pricing report & condition index?

Pricing Report:

A Pricing report basically helps to get the list of all the pricing details which we have maintained in the system. We can get details of all the condition types including the scales. We can get the details as per our requirement i.e., Sales org/Dc/Division/Plant /material etc wise. The selection criteria would be as per the Key combination which you select in the IMG screen

You get following information from pricing report.

1. It informs you about the customer specific price agreements that were made within a certain period 
2. From pricing report you can know which condition records exist for freight charges 
3. Which condition records exist for customers in a particular region or country

You can create your own pricing reports with V/LA.

Also

V/LD is very useful. This can be customized.  
The sales personnel use it to

1. get information for price (discounts) that existed at previous period (Say June 200X)

2. Inform potential buyer about the current price (and discounts)

3. Review price and discounts.

Though all the above T Codes and there are many More standard SAP Reports have very high utility, it is not widely used. Clients prefer customized reports when it comes to pricing reports - all Z programs and Transactions. 

These kind of reports are generally required by the Top Management for periodical review // Finance team for price control // Master data team for record purposes // Process audits by Internal/external agency // Of late, for every SOX audit done in the company...especially the change records for prices.

Condition Index

Condition index is very useful for searching the condition record for a customer. 
It becomes easier and faster to search for condition records for a customer or material just like it become easier to search a topics in the book with help of index.

You have to mark the "condition index" check box in the condition type and you have to activate the index in customization.

You can set the discount for fast ten orders through "condition update".

First, in your discount condition type(V/06) activate the "condition update" check box.

Second, in the condition record, in additional data put "maximum number of orders" as 10.

You may also create the condition record for discount through VK31. Now go to change(VK32), scroll to the right, you will find a column "N". This is maximum number of order field. Here you can put value 10 and save it.

Now, system will give the discount to the first 10 orders.

Condition Exclusion

What is meant by condition exclusion for Condition types and records?

Condition Exclusion 

The system can exclude conditions so that they are not taken into account during pricing in sales documents.

Material 4711 costs 150 USD. Some customers receive a discount of 10 USD per 100 pieces.

However, a specific customer can buy the material for 100 USD. Since this is a particularly good price, the customer should not also have a discount of 10 USD per 100 pieces. Therefore, this discount is to be excluded from pricing.

To do this, you must follow two steps:

You must set a condition exclusion indicator for the price. You can do this in two ways: If you want to set the condition exclusion indicator a follows then you specify it:

- for all condition records of a condition type (e.g. with condition type PR00) when defining a condition type in SD Customizing

- for an individual condition record (e.g. only for material 4711) in the detail screen of a condition record (in the Condition exclusion field)

You must set a condition for the discount in the pricing procedure in Customizing for sales. If this condition is set, the discount is not valid if the condition exclusion indicator is set. Condition 2 is available in the standard R/3 System.

The condition exclusion indicator is not valid for condition supplements.

This means that if a condition record contains condition supplements they will be taken into account during pricing.

Condition Exclusion Group – 

In any normal situation there could be more than one condition type in a pricing procedure offering a discount to a customer. Should the discounts be automatically determined, there is the risk that the customer will receive all the relevant discounts and thus purchase the product for a lower price than he should.

By using ‘condition exclusion groups’ you can ensure that the customer does not receive all the discounts, but instead only receives the best of the available discount condition types.

Menu path – IMG - Sales & Distribution - Basic functions – pricing – condition exclusion – condition exclusion for groups of conditions (OV31).

A condition exclusion group is merely a grouping of condition types that are compared to each other during pricing and result in the exclusion of particular condition types within a group or entire groups. It is important to note that the condition types you want the system to compare must exist in the pricing procedure and must have valid condition records created for them.

If for example, a sales order is created using the pricing procedure that the exclusion group is assigned to, you can see that the condition offering the most favorable discount to the customer is represented in the pricing procedure.

For instance, condition type K007 has offered a discount of 10% off the sale price or a real value of $30, while another condition type K005 has offered a real value discount of $10. The system then takes the best discount for the customer between the two, which is K007 and makes the other discount K005 inactive. This can be seen by double clicking on the condition type K005, where you can find a entry saying ‘Inactive A condition exclusion item’.

There are four possible methods of using condition exclusion groups – 

A – best condition between the condition types

B – best condition within the condition types

C – best condition between the two exclusion groups

D – exclusive

E – least favorable within the condition type

F – least favorable within the two exclusion groups

Configuring ‘Condition Exclusion Groups’

First step is to define a ‘condition exclusion group’ by using a four character alpha numeric key.

Next step is to assign the relevant condition types to the exclusion groups such as discount condition types, freight condition types.

After completing the assignment of the condition types to the exclusion group, proceed with assigning the condition exclusion group to the relevant pricing procedure.

After selecting the pricing procedure for which you want the condition exclusion to be active, select the folder ‘Exclusion’ where you can assign the relevant condition exclusion procedure to the relevant condition exclusion group.

When using the condition exclusion group to find the best condition record in a condition type – only use one condition type per exclusion group. The most important thing to remember here is to “deactivate” the Exclusive Indicator on the access sequence assigned to that condition type. Otherwise, the system will merely find the first condition record and stop searching for other records.

Freight in Header Condition SO

Common questions: 
We are using the Freight in Header Condition. I maintained two line items in the Sales Order. So the Header freight is splitting irregularly for two line items (in item conditions) . How it is happening? Any formula is there?

Header Conditions - Automatic pricing does not take header conditions into account; you can not create condition records for them in the standard system. 

Header conditions are entered manually in order processing. R/3 includes the following header conditions: 
- Percent discount (HA00)  
- Absolute discount (HB00)  
- Freight (HD00)  
- Order value (HM00) 

Header Condition: If this condition is marked as a header condition, it is possible to enter the condition type in the header condition screen. Checks for changing the condition manually are unaffected by this.

Group Condition: Group conditions are helpfull incase of discounts. If group condition is selected then the discount percentage or quantity is applicable for the total sum of the quantity in the PO for those materials belonging to the same material group.  Suppose if two materials of same matl grp have discounts for 100 qty and above but in PO if the two matls are bieng procured for 50 qty then they cant avail discounts but if group condition is selected then the sum of the quantity of both matl of same matl group is considered (50 + 50) and discount can be availed for 100 qty.

Further Group condition: Indicates whether the system calculates the basis for the scale value from more than one item in the document.

The nature of header condition is that whatever value you are giving in sale order / billing, line item wise, it will be distributed proportionately.

If you access V/06 and the header condition type, you can see that the condition type  
- does not have any access sequence  
- field Group condition is selected 

Normally Freight Header condition like condition type "HD00" is calculated on the basis of weight. This is a Manual condition and you have to enter it in the header screen.  It will be proportionately distributed on each item on the basis of weight.  If you will uncheck the group condition field, the same freight amount will be copied to each item, possibly irrespective of different weight which may not be logical.

That is the standard behaviour of the header condition type.

Based on whether the group condition field is ticked on or off, it will either split the header condition value to the items on pro-rata basis or it will just duplicate the header value to all the items.

What you are experiencing with Fixed Amount Header conditions is standard behaviour. Please see below Notes:  
- 876617 FAQ: Header conditions / Header condition screen  
- 317112 Behavior of conditions w/ calculation rule B changed  
- 485740 Conditions with fixed amount in copy activities 

To achieve what you wish (absolute amount), solution is in the below Notes:  
- 84605 Transfer absolute amount condition to billing doc.  
- 25020 Value changes during over/underdelivery  
- 25144 Freight conditions during milestone billing 

What are the 8 steps involved in condition technique?

What are the 8 steps involved in condition technique?

It starts with an understanding of the factors that influences the Price. Lets say it depends on Customer and Material. With this understanding now we will start with the Table where we will pass the above parameters. There is a table 5 which already has Customer and Material so we can now copy and rename it or use the same table in our Pricing Procedure.  
  
T Code VOK0 
  
Step 1. Define/Choose your Table (with the requirement parameters that influence the price) 
Step 2. Define your Access Sequence and include the above Table in your Access Sequence 
Step 3. Define your Condition Type (There are four Price Types Basic Price, Discount, Freight and Tax) and include your Access Seq. Its always better to copy the Price Types provided by SAP. 
Step 4. Now comes your Pricing Procedure where you include include Condition Types and format. 
Step 5. Now comes Procedure Determination where you specify the Document Pricing Procedure and Customer Pricing Procedure along with Sales Organisation, Distribution Channel. 
Step 6. Maintain Condition Records for your Condition Types 
  
I guess you can make it 8 Steps by dividing some of the main steps. Few important things to note is following.. 
  
1. XD01 - Create Customer - Always ensure that you pick the right Customer Pricing Procedure from here. 
2. VA01 - Sales Order - Ensure that you have the right Document Pricing Procedure from here 
3. While Creating Access Sequence, check your Fields and ensure that they appear with any warning (Highlighted in Red) 
4. Do not forget to mention your Access Sequence while defining your Condition Type 
5. Always remember that your Procedure Determination has only Basic Price as Condition Type 
6. Do not forget to mention the Range (From To) while creating your Pricing Procedure.  
  

Header Condition and Group Condition

What are header conditions?

Header conditions are those which appear in the header level of any sales order. these conditions are to be entered manually and get distributed automatically and the basis for distribution are taken from the NET VALUE of items mentioned at item level. 

When we go to the conditions section in a sales order, where the details of pricing is mentioned, here we add these conditions. 

Whenever any Header Condition is used, it overrides the PR00 condition type.

Examples of header condition.

- HA00 - % Based Header Condition. 

- RB00 - Absolute or numeric value which applies to all items.

- HB00 - Numeric value or Absolute value.                          *-- Vivek Chokshi

What is the difference between group condition and header condition?

Group Condition: You can use this is feature of a condition type to apply price or discount for a material based on common property.  
  
Header Condition: This is a manual condition which you apply to header (Condition screen) of a sales document. This amount is applicable to all items.

Usage of this feature is to apply price / discount for a specific group of materials. 

1. You maintained a discount based condition record fbased on material group ( = 01 for example). You maintained scales also. 
   
     Qty      Discount           
    1 - 10   Rs. 100.00 
  11 - 50   Rs. 105.00 
51 - 150   Rs. 110.00 etc.

2. You are creating a sales order for a customer with five different items with different quantities as below

ITEM 1 - 25 No's 
ITEM 2 - 3 No's 
ITEM 3 - 12 No's 
ITEM 4 - 27 No's 
ITEM 5 - 62 No's

All the material is having the material group = 01.

3. While calculating the discount, because of this group condition, system add the quantities of items which have material group = 01. In the above example total quantity is = 109. System apply a discount of Rs. 110.00 to each item irrespective of the individual quantities.

4. If you have not activated the group condition feature, system determines the discount value based on individual item quantity which is as below. 
                                      Discount 
 ITEM 1 - 25 No's         Rs. 105.00 
 ITEM 2 -   3 No's         Rs. 100.00 
 ITEM 3 - 12 No's         Rs. 105.00 
 ITEM 4 - 27 No's         Rs. 105.00 
 ITEM 5 - 62 No's         Rs. 115.00

5. Is it clear now. Just try a sales order and see the out come

Procedure to Test: 
1. Create 3 materials. Maintain Material Group of each item is same.  
2. Activate the condition type as a group condition.  
3. Create a condition record for this condition type with scales.  
4. Process a sales order for a customer with these three material with different quantities.  
5. Check the outcome.    

Add a Field To New Condition Table in Pricing

Add a field to a new condition table in Pricing (Condition Technique):-

I will explain you the process with below example...Please follow steps in below sequence-

Try to add the filed from the field catalog.  In case the required combination field is not there, you can add the field through the following process to filed catalog and create the condition table.   It is most common that one or other time we need to use this function while configuring multi tasking & complex Pricing Architecture.

Here I'm giving a simple guide to add fields to the Pricing Field Catalogues:

For example 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.

Condition access, field catalog, allowed fields, KOMG, KOMK, KOMP, KOMPAZ, KOMKAZ, PSTYV are the other terms which we need to know about, to add Fields.

Reason and Prerequisites:  
For technical reasons, field PSTYV was included in structure KOMP, however, not in structure KOMG ('Allowed Fields for Condition Structures').

Proceed as follows: 
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 
Save, check and activate the change you made.

3. Note:Because of the change in structure KOMPAZ, field ZZPSTYV is now known in structures KOMG and KOMP because structure KOMPAZ is included in both structures.

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: 
MOVE xxxx-PSTYV TO TKOMP-ZZPSTYV. 
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 OSS Note 21040.    

SD Questions About Pricing Condition

The Most Important Tips in Pricing For SAP SD Module to crack interviews...

Whenever we define our pricing procedures, we remain least interested in creating our own Condition Types,Condition 
 Tables & Access Sequences. What we do is, we just define our own pricing procedures by using the existing condition types (i.e: PR00, K004, K007, KA02, KF00 etc.) & then assign that Pricing Procedure with " Sales Area, Document Pricing Procedure & Customer Pricing Procedure " . 

After that we put the values against each Condition Types, mentioned in our Pricing Procedure by using the T-Code "VK11". But we also need to know about the Condition Tables, Condition Types & Access Sequence Creation. So for that purpose we have to use the following T-Codes respectively : "V/05", "V/06" & "V/07". Now it will become easy to create the same.

Also to inform that, using T-Codes is more smarter than following paths through IMG screen. 

Utsav Mukherjee - utsavmukherjee143@hotmail.

What is the difference of VK11 and VK31 (condition records)?

My condition type is PR00 and Access sequence is PR02.  And in this access sequence table 304 is available.  Now when I was entering the PR00 in VK31 it shows error Table 304 is not defining for the condition type PR02.  But when I was entering the PR00 at VK11 it is accepting it.

Difference between VK11 and VK31 - if you go through the menu path you will get the vk 31 as condition record from the tamplets whereas vk11 as simple condition record.  In VK11 you can store condition record for more than one condition 
type.  This means you can have same condition record for different condition types.This feature is given to enhance the system's performane and not to create the duplcation of the work for each condition type.  
Again system is not allowing to store the record in the vk31 for the condition type pr00 and access sequence pr02.This is because if you see this ac seq cointains two accessses 20 and 30 having the same table no.But you see there is the difference between the technical view of it for transfering the data from document field and condition field,so you can not maintain the data at VK31. 
 

What is the difference between Header condition and Item condition?  I know item condition applies to each item in a sales document.  Header condition can only be applied to an entire document.

Difference between header and item condition - as YOU CORRECTLY SAID HEADER CONDITION IS APPLICABLE FOR THE WHOLE DOCUMENT where as item is for item.Ex-Say fright is dependent on the total weight of all the items in the documents then header condition adds on weights of all items and calculates the record accordingly.  
You have two different types of the header conditions. 
a) In one you can duplicate the same value throughout the document for each item.Say discount 2% at header level which is also applicable to all the items 
b)Second is the accumulation of the values of all the item at the header level,as earlier explained for the weight/fright. 
These differenes are controlled through the indicator of group condition in the cond.type configuration.

And so obviously header condition can not have the condition record and hence access sequence.

 

Disallowing Condition Types - How I can accomplish the following: 

Be able to DISALLOW Z0BP Condition type to be negative ( Invoice Block) 

You can modify condition type from customising;  
Sales and Distribution->Basic Functions->Pricing->Pricing Control->Define Condition Types->Maintain Condition Types 

Change condition type ZOBP's plus/minus indicator to "A" which means only positive is allowed.   *-- Arvind Rana  
 

In pricing procedure there are column such as requirement, sub total altclty, altbv, accurals. What are these and where we calculate all these values which we put. 

1. Requirement: Denoted by nos and maintained in VOFM, this is a condition required for a particular condition type  to be executed. Eg. PR00: req 2 ie item relevant for pricing 
      VPRS/EKO1: req 4 ie cost 
      Rebate BAO1 Req 24/Req 25  etc

2. Subtotal: this represents where a which table a value is stored, which can be processed for further calculation.

Eg. for PR00, if this value is to be used for credt check of a customer, we mark the subtotal as A.

3 Alternate Calculation type: this is also denoted by numbers and maintained in VOFM. Eg. Suppose for 45 units , each unit is charged $100 per unit, the order value comes out to be $4500, that is calculation is done as per unit price, if the client wants calculation type  to be based on volume or wieght, alternate calculation type can be configured.

4. Alternate base value: Denoted by no. and maintained in VOFM.

Eg, if the pricing scale is maintained and pricing for 45 units comes under the scale of $100 per unit., the base value is 45 units, but if the client wants a standard base value in some casesto be assumed inspite of maintaining the scale, an alternate base value is confihured, that is the base value based on which the order value is to be calculated changes.

5. Accruals: Accruals are maintained for rebate agreements, it constitutes the total accumulated value which customer has earned through rebate, one the rebate for certain amount is settled the amount from the accruals get deducted.

Partner determination and Creating Commission for Agent

For creating commission agent, you have to follow below steps.

1) Establish Partner Functions for the Commissionee(s) 
Menu Path: TOOLS ->; BUSINESS ENGINEER ->; CUSTOMIZING ->; SALES AND DISTRIBUTION ->; BASIC FUNCTIONS ->; PARTNER DETERMINATION ->; DEFINE PARTNER FUNCTIONS 
Transaction Code: VOPA

2) Assign the Partner Functions to Partner Procedures 
Menu Path: TOOLS ->; BUSINESS ENGINEER ->; CUSTOMIZING ->; SALES AND DISTRIBUTION ->; BASIC FUNCTIONS ->; PARTNER DETERMINATION ->; DEFINE PARTNER FUNCTIONS 
Transaction Code: VOPA

3) Create a Partner Procedure for the Commissionees 
Menu Path: TOOLS ->; BUSINESS ENGINEER ->; CUSTOMIZING ->; SALES AND DISTRIBUTION ->; BASIC FUNCTIONS ->; PARTNER DETERMINATION ->; DEFINE PARTNER FUNCTIONS 
Transaction Code: VOPA

4) Create New Customer Account Group(s) for Commission Agents 
Menu Path: TOOLS ->; BUSINESS ENGINEER ->; CUSTOMIZING ->; LOGISTICS GENERAL ->; LOGISTICS BASIC DATA: BUSINESS PARTNERS ->; CUSTOMERS ->; CONTROL ->; DEFINE ACCOUNT GROUPS AND FIELD SELECTION FOR CUSTOMER 
Transaction Code: OVT0

5) Assign the Partner Functions to the Customer Account Group(s) 
Menu Path: TOOLS ->; BUSINESS ENGINEER ->; CUSTOMIZING ->; SALES AND DISTRIBUTION ->; BASIC FUNCTIONS ->; PARTNER DETERMINATION ->; DEFINE PARTNER FUNCTIONS ->; GOTO ->; PARTNER FUNCTIONS ->; ENVIRONMENT ->; ACCOUNT GROUP ASSIGNMENT 
Transaction Code: VOPA

6) Assign the Partner Functions to the Partner Procedure for the Sales Document Header 
Menu Path: Tools ->; Business Engineer ->; Customizing ->; Sales and Distribution ->; Basic Functions ->; Partner Determination ->; Define Partner Functions 
Transaction Code: VOPA

7) Assign the Partner Functions to the Partner Procedure for the Sales Document Item (OPTIONAL) 
Menu Path: TOOLS ->; BUSINESS ENGINEER ->; CUSTOMIZING ->; SALES AND DISTRIBUTION ->; BASIC FUNCTIONS ->; PARTNER DETERMINATION ->; DEFINE PARTNER FUNCTIONS 
Transaction Code: VOPA

8) Edit the Pricing Communication Structure (KOMKAZ) to Hold the New Functions (Client Independent) 
Menu Path: Menu Path: TOOLS ->; ABAP WORKBENCH ->; DEVELOPMENT ->; DICTIONARY 
Transaction Code: SE11

9) Edit MV45AFZZ – userexit_pricing_prepare_tkomk (Client Independent) 
Menu Path: TOOLS ->; ABAP WORKBENCH ->; DEVELOPMENT ->; ABAP EDITOR 
Transaction Code: SE38

10) Edit RV60AFZZ - userexit_pricing_prepare_tkomk (Client Independent) 
Menu Path: TOOLS ->; ABAP WORKBENCH ->; DEVELOPMENT ->; ABAP EDITOR 
Transaction Code: SE38

11) Edit MV45AFZB - userexit_new_pricing_vbkd changing new_pricing (Client Independent) 
Menu Path: TOOLS ->; ABAP WORKBENCH ->; DEVELOPMENT ->; ABAP EDITOR 
Transaction Code: SE38

The following code should be inserted into program MV45AFZZ to allow the system to re-execute pricing if the user makes a change to the relevant partner function (alteration, addition, deletion).

13) Add the KOMKAZ Fields to the Pricing Field Catalog (Client Independent) 
Menu Path: TOOLS ->; BUSINESS ENGINEER ->; CUSTOMIZING ->; SALES AND DISTRIBUTION ->; BASIC FUNCTIONS ->; PRICING ->; PRICING CONTROL ->; DEFINE ACCESS SEQUENCES ->; MAINTAIN ACCESS SEQUENCES 
Transaction Code: OV24

14) Create Condition Tables (Client Independent) 
Menu Path: TOOLS ->; BUSINESS ENGINEER ->; CUSTOMIZING ->; SALES AND DISTRIBUTION ->; BASIC FUNCTIONS ->; PRICING ->; PRICING CONTROL ->; DEFINE ACCESS SEQUENCES ->; MAINTAIN ACCESS SEQUENCES 
Transaction Code: V/03

15) Create an access sequence containing the new tables (Client Independent) 
Menu Path: TOOLS ->; BUSINESS ENGINEER ->; CUSTOMIZING ->; SALES AND DISTRIBUTION ->; BASIC FUNCTIONS ->; PRICING ->; PRICING CONTROL ->; DEFINE ACCESS SEQUENCES ->; MAINTAIN ACCESS SEQUENCES 
Transaction Code: V/07

16) Create a new condition type 
Menu Path: TOOLS ->; BUSINESS ENGINEER ->; CUSTOMIZING ->; SALES AND DISTRIBUTION ->; BASIC FUNCTIONS ->; PRICING ->; PRICING CONTROL ->; DEFINE CONDITION TYPES ->; MAINTAIN CONDITION TYPES 
Transaction Code: V/06

17) Add the Condition Type to the Pricing Procedure 
Menu Path: TOOLS ->; BUSINESS ENGINEER ->; CUSTOMIZING ->; SALES AND DISTRIBUTION ->; BASIC FUNCTIONS ->; PRICING ->; PRICING CONTROL ->; DEFINE AND ASSIGN PRICING PROCEDURES ->; MAINTAIN PRICING PROCEDURES 
Transaction Code: V/08

11) Create Commsission Report ZZCOMMISSION (Client Independent) 
Menu Path: TOOLS ->; ABAP WORKBENCH ->; DEVELOPMENT ->; ABAP EDITOR 
Transaction Code: SE38

Customer discounts on effort only

We have a requirement of giving a discount to customer based on the total 

amount invoiced so far (across financial years). 
Where do we set this up? We have seen so far the discounts are calculated 
based on the value of the current invoice. 
The discount should be on a graduated scale basis for example

0 - 100000 No discount 
100000 - 200000 5% 
200000 - and above 10% 
This means that discount would only start after the customer's net sale 
value crosses 100000. 
For example, if the customer has been billed for 99000 and the current 
invoice is for 3000, a discount of 5% should be given on 2000 i.e. 100. 
Another complication is that, the discount is not based on the total amount 
billed so far, but only on the effort billed and not on reimbursements (like 
airfares, living expenses, visa charges, beeper charges etc). The discount 
applies only to the effort and not to the reimbursements. In the above 
example (invoice of 3000) say the effort billed is only 1500, the rest being 
reimbursements. The discount is only on the 500. (the rest being taken up by 
the lower limit for eligibility of 100000)

For example the customer might have been billed say 150000 so far but actual 
effort billed might be only 90000, the rest being reimbursements of actual 
costs and hence the customer is not eligible for the discount.

*The solution for this is Using rebate condition types and suitable condition 

records.

Of this to handle your first problem that is the rebate has to be applied 
only on the "effort" you have to set up a line in the pricing procedure 
which gives the rebate basis i.e the value to be used for rebate cond types. 
This I believe solves your problem of rebate only on effort.

Your second problem i.e the discount should start getting applied 
automatically when it reaches the first scale for which the values span few 
financial years. This I am not really sure whether it can be made possible 
in the invoice itself. But a work around is not giving the discount directly 
in the invoice but settling it against the rebate agreements by Credit notes 
periodically.

*Arent we looking at rebate agreeement. That appears to be a straightaway 

solution to your problem. You activate the sales organization and the 

payer for that

*I am in SAP R/3 rel.30F. 

We have 2 options to meet your requirement. 
1. Using scale in condition type ( tcode V/06 ), choose scale basis 
G.Scale based on a formula ( be: your based amount is invoice ). Define 
scale formula. You need ABAPER to define it. 
2. Using routine in Alt.calc.type ( tcode V/08 , Maintain Pricing 
Procedure ). Here, you also need ABAPER to create routine.

Make Material Master Price of a material as sales price automatically

The first method is not to set the pricing condition VPRS as statistical.

Simply remove PR00 and it will work fine if you always use VPRS as your pricing base inside the pricing procedure.

VPRS will reads both prices based on the price control in the material master. 

Price control S for standard price.  
Price control V for moving average price. 

It is this simple if you do not have any other "Prices" in the price procedure.  
 

However, if you are using one pricing procedure where for some items you price using VPRS and some others using PR00, then you should use requirement routines to enable the correct price condition type at the right time. 

The second method involves more work as you need to write a formula (VOFM) to get that information. 

This is how it goes :- 

1. Set VPRS to be the first step in the pricing procedure and to be subtotal B (as standard). 

2. Set PR00 with alt. calc. type formula, which sets the value of PR00 to be equal to the subtotal B.  
    The routine (created with transaction VOFM) is: 

RV64A901 
FORM FRM_KONDI_WERT_600.  
    XKWERT = KOMP-WAVWR. 
ENDFORM.

The pricing procedure than looks like that: 

Step 1 VPRS statistical, subtotal B, reqt 4  
Step 2 PR00 Altcty 600  

Mass Update of condition pricing

You can update the condition pricing for a range of sales order.

For e.g. if you create sales order for 15 months or so, and at the beginning of each year,  you have to update the prices for lots of sales orders.

Other than using VA02 and make an Update of the conditions at item level which is a big work because you will have lots of open sales order after so many months. 

Use VA05, select your Orders and on the result screen :-

click Edit- > Mass Change -> New Pricing (menu). 

or 

if you don't want to do that Online, write your own abap report and use Function SD_BULK_CHANGE (check where-Used at SE37, Trace VA05 on how to fill the parameters,  Function MPRF => New Pricing) 

Report to Check the Entered Pricing Condition Price

Which is the best transaction code to check the Pricing condition price entered in "VK11"?

Other than "VK13", to display the price, you can use V/LD - Execute Pricing Report to check the prices entered into the Pricing Master.

Normally Pricing Report - "07 Cust.-specific Prices with Scale Display" will do.

Other Pricing Reports you can tried are these:

--------------------------------------------------------------------------- |LR|Report title                                                          | -- ------------------------------------------------------------------------ |01|Comparison of Price Lists Without Scale Display                       | |02|Comparison of Price Groups Without Scale Display                      | |03|Incoterms with Scale Display                                          | |04|Incoterms Without Scale Display                                       | |05|Price List Types Without Scale Display                                | |06|Price List Types with Scale Display                                   | |07|Cust.-specific Prices with Scale Display                              | |08|Cust.-specific Prices W/out Scale Display                             | |09|Material List/Material Pricing Group with Scale Display               | |10|List Mat./Mat.Pricing Groups Without Scale Display                    | |11|Price Groups With Scale Display                                       | |14|Taxes                                                                 | |15|Material Price                                                        | |16|Individual Prices                                                     | |17|Discounts and Surcharges by Customer                                  | |18|Discounts and Surcharges by Material                                  | |19|Discounts and Surcharges by Price Group                               | |20|Discounts and Surcharges by Material Group                            | |21|Discounts and Surcharges by Customer/Material                         | |22|Discounts and Surcharges by Customer/Material Group                   | |23|Discounts and Surcharges by Price Group/Material                      | |24|Discounts and Surcharges by Price Group/Material Group                | |25|VAT/ATX1                                                              | |26|Canada/USA                                                            | |27|I.E.P.S Mexico                                                        | |28|Conditions by Customer                                                | |30|Conditions by Customer Hierarchy                                      | |31|Price List with Release Status                                        | |AC|                                                                      | |AD|                                                                      | ---------------------------------------------------------------------------

Pricing date based on delivery date

Pricing date based on delivery date

Used transaction VOV8.

This configuration is by order type.

There is a field called proposal for pricing date.

There you can select pricing date as requested delivery date.

A - Proposed pricing date based on the requested dlv.date (Header) 
 

This control is set at the document level as oppose to the condition type level (PR00).

That means your other condition types such as surcharges and discounts are also determined using the requested delivery date.

If your requirement is for PR00 to alone to be priced at delivery date then this will not work.

How pricing date is determine in the sales order and billing document? Where is the setting?

The pricing date is proposed based on the setting you make in the Sales document configuration. ( T code : VOV8) 
You have a field" Prop.f.pricing date " in the Requested delivery date /  pricing date /  purchase order date  segment. 
  
Then you can choose the follwoing options: 
Blank - Indicates the current date as the pricing date 
A -  Indicates the date based on the requested delivery date 
B - Indicates the date based on the order validity start from date 
  
And the pricing in the billing document is copied from thte sales order / Delivery document.. 
  
It again depends on the setting u have in the copy control from order - billng or delivery - billing. 
In the copy control, in the item settings you have two fields relavant for this. 
  
One is pricing source and the other is pricing type.

The pricing sources are generally the order.   But if you want you can change it to other values mentioned in the drop down, 
but this values have no effect if the pricing type is B.

Any other value other than B in the pricing type will take the reference document price mentioned in the pricing source field. 
but for the pricing type B.  The new price is determined in the billing order.