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.
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 performance and not to create the duplication 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 contains two accesses 20 and 30 having the same table no. But you see there is the difference between the technical view of it for transferring 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 differences 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.
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 credit 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 weight, 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 cases to be assumed in spite of maintaining the scale, an alternate base value is configured, 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.
Add a Field To New Condition Table in Pricing
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:
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