Register Login

Explain Pricing Procedure in SAP MM module

Updated Jan 14, 2020

Pricing Procedure regulates the price of goods and services in the SAP System. With consideration, of condition types, when one processes the sales documents the system computes the documents price. Each pricing procedure in SAP system comprises of its own set of condition types for determining the prices of goods and service for the respective categories of customer.

The sequence of Pricing Procedure activities is generally as follows:

1. Define condition types for each of the price elements (prices, discounts, and surcharges) that occur in your daily business transactions.
2. Define the condition tables that enable you to store and retrieve condition records for each of the different condition types.
3. Define the access sequences that enable the system to find valid condition records.
4. Group condition types and establish their sequence in pricing procedures. 

16 Pricing Elements in Pricing Procedure SAP MM

1. Step:

  • A number which determines the sequence of the conditions within a procedure.
  • In the pricing procedure, it reflects the position of the condition type. 
  • Ex.: 10, 15 etc.

2. Counter:

  • The system utilizes the counter for counting the steps and for counting the mini-steps of similar types of condition for reducing the number of steps in the pricing procedure, thereby improving the performance of the system.
  • In the pricing procedure, accessing the number of conditions within a step. 
  • The system considers the sequence specified by the counter, during the automatic pricing.

3. Condition Type:

  • It reflects the pricing element in the pricing procedure like a discount, base price, tax, and freight.
  • The condition type is utilized for various functions. For instance, in pricing, the condition allows you to differentiate between the various types of discount; in output determination, between the different output types like order confirmation or delivery note; in batch determination, between the different types of strategies. 
  • Ex.: PR00 - Price, K004 - Material Discount, K005 - Customer/Material Discount, K007 - Customer Discount.

4. Description:

  • The system copies the explanation of condition type from its description (V/06).

5. From and 6. To:
 1From: This can be utilized as a base to the condition type for computing further value.
 2. From and To: The range between the steps from and to can be utilized for specifying the range between similar types of condition. Depending on the type of condition type, the system subtracts or adds the total value of those specific condition types from the specific common source.

7. Manual:

  • This indicator reflects the sales order processing in case the specific condition type can be manually determined. 
  • If the user checks the box then the entry will be manual, if unchecked it, it will be automatic.
  • The entry should be automatic, for Base Price and Taxes.
  • The entry should be manual, for Discounts and Freights.
  • If the user checks the box, the condition type will not be listed in VA01 on the conditions at the header/item level. If needed, it needs to be manually entered. 
  • The condition type will be listed, if the user unchecks the box, in VA01 when the user goes to conditions at the header/item level.

8. Mandatory:

  • This indicator lists the specific condition type which is a mandate in the pricing procedure.
  • If the user checks the box, then in VA01 at the header/item level in the conditions tab, the system will not permit the user to do it and shows an error when a user deletes the value in the condition type and tries saving the document.
  • if the user deletes the value in the condition type and tries saving the document, systems allow user to save it, without showing any error, incase user unchecks the box, then in VA01 at the header/item level in the conditions tab. 
  • The mandatory checkbox should be checked in the condition types which are compulsorily needed in the pricing procedure. Ex.: PR00, MWST.
  • If the condition type is checked with the mandatory option, then value ought to be maintained for that condition type, else the system will not permit the user for processing the document.

9. Statistical:

  • This indicator will be activated and will not permit the value of the condition type to be considered into net value calculation.
  • This is only used for information purposes.
  • This indicator sources a surcharge or discount which has to be set in the document statistically (without modifying the value).
  • This is used very commonly for condition types
  • VPRS - Cost (Moving average price/Standard Price).
  • SKTO - Cash Discount

10. Print:

  • The value of this field lists whether one can print the line item or not in the sales document and what is the level it should be printed.

11. Subtotal:

  • The value of this field states where the values of subtotals must be captured i.e. in which table and which field.
  • Controls which fields condition amounts or subtotals (for instance, a customer discount or the cost of a material) are saved. 
  • If the same fields are being utilized for storing the various condition amounts, the system adds the individual amounts.
  • These condition amounts or subtotals are utilized as a starting point for performing further calculations. User may require a subtotal of all the discounts which are encompassed in the pricing of a sales order.

12. Requirement:

  • This is a practice which is written by an ABAP consultant as per the business requirement.
  • User can restrict the access of condition type, by defining the requirement in condition technique. 
  • For understanding the concept, the user can refer to the example of the Rebates. Rebates have to be encompassed during the billing document processing and not in the sales document processing. As rebates are provided on the delivered quantity and not on the quantity ordered. (in case of cut-off period for rebates).
  • For rebates, we can utilize the condition types BO01 to BO05, and in the Requirement column we provide the value 24 which refers to "Only in Billing Document".
  • This Requirement ensures that these condition types only appear during the billing document processing.
  • Incase new Requirements are required to be defined we follow the procedure listed below.
  • User Goes to T.Code: VOFM. - Maintain Requirements & Formulas
  • Clicks on the "Requirements" in the top menu and then clicks on "pricing".
  • User has a list of requirements, he can ask the ABAP consultant for creating the new requirement which are based on the requests of the client.
  • User assigns the application type such as V - Sales/Distribution etc.

14. AltCty - Condition formula for alternative calculation type:

  • It is again a Routine that is written by ABAP Consultant.
  • It is an alternative formula for the condition type that can be used instead of standard formulas.
  • For example, let us take the Profit Margin which can be both + /- , so here this routine will help us in generating the value which can be either + or -. Profit margin is not a condition type so it cannot be classified as +ve or -ve in the V/06.
  • Ex.: 950 0 Profit Margin 11.
  • So we assign 11 - Profit Margin.
  • If new routines are to be defined we follow the procedure given below.
  • Go to T.Code: VOFM. - Maintain Requirements & Formulas
  • Click on the "Formulas" and then on the "Condition Values".
  • We have a list of routines, we can ask ABAP consultant to create new routines based on the client requests.
  • And we assign the application type.

15. AltCBV - an Alternative formula for condition base value:

  • Formula for determining the condition basis is reflected as an alternative to the standard.
  • This is a Routine which has been written by an ABAP Consultant.
  • This is used for calculating the value of the condition type instead of using it from the "FROM" column.
  • Ex.: Freight - KF00.
  • Freight is computed on the basis of volume, weight, etc. and not on the base price. In pricing there is no entry of weight from which the value can be referred as it can be done for discounts utilizing the base price. User has to derive the value from the Material master.
  • In this column user can list the value as 12 - Gross Weight or 13 - Net Weight.
  • During pricing, the system considers the value which is listed in this column and on this value, determines the freight based. 
  • For instance, user has Net weight: 100 kgs and Gross Weight: 150 kgs. And if he lists 13 in this column then the Freight condition KF00 will be computed using the weight as 100 kgs.

16. AcyKy - Account Key/ Accrls - Accruals:

  • The values of the Sales Deductions, Tax Revenues,  Sales Revenues, Freight Revenues and Rebate Accruals etc. are going to be posted in the respective G/L accounts in Fi Module.
  • For doing this user assigns the account keys/ accruals to the various types of condition based on their classification. The classification shown below.
  • ERF Freight revenue
  • ERS Sales deductions
  • ERU Rebate accruals
  • ERB Rebate sales deduct.
  • ERL Revenue
  • For Ex.,
  • For all Discount condition types such as K004, K005 etc. user assigns ERS - Sales Deductions.
  • For all the Price condition types such as PR00 etc. user assigns ERL - Revenue.
  • For all Freight condition types KF00 etc. user assigns ERF - Freight Revenues.
  • For all Rebates condition types BO01 to BO05 user assigns in Account key ERB - Rebates Sales deductions and for Accruals ERU - Rebate Accruals.
  • This account keys and accruals are assigned to respective G/L accounts. Therefore, the system posts respective values in respective G/L accounts in Fi-Co Module.
  • This also one of the areas of SD - Fi Integration. SD consultants are responsible for assigning the account keys and Fi Consultants have to assign the respective G/L accounts in T.Code: VKOA.