Building Pricing Procedures for Calculation Logic

Objective

After completing this lesson, you will be able to configure pricing procedures to establish the detailed calculation schema used for sales document pricing in SAP S/4HANA Cloud.

Introductory Video

Understanding and Configuring Pricing Procedures

The Role of Pricing Procedures in Price Calculation

The Pricing Procedure is a cornerstone of the SAP S/4HANA Cloud pricing engine. Its primary function is to define the exact sequence and manner in which various pricing elements—such as prices, discounts, surcharges, freight, and taxes—are calculated to arrive at a final net value for a sales document item and the overall document total. It acts as a structured calculation schema or a roadmap that the system follows during price determination.

Effectively configuring pricing procedures is critical because it gives you precise control over how prices are determined. You can specify which condition types are active, their order of application, how percentage-based conditions calculate their base, which conditions are mandatory, which are for statistical purposes only, and how intermediate totals are derived and used. This ensures that your complex pricing logic and business rules are accurately reflected in every sales transaction.

Key Elements and Control Fields in a Pricing Procedure

A pricing procedure is defined as a sequence of steps. Each step typically involves a condition type or a subtotal. Key columns and control fields you will work with when defining a pricing procedure include:

  • Step: A sequential number defining the position of the line in the procedure.

  • Counter: Used to process multiple conditions with the same step number (e.g., different discounts at the same calculation level).

  • Condition Type (CTyp): The specific condition type (e.g., PPR0 for base price, DM01 for material discount, a tax condition type like MWST) to be processed at this step. If this field is blank, the line is typically used for a subtotal or a formula.

  • Description: Automatically populated from the condition type or manually entered for subtotals.

  • From / To (Step numbers): These fields are crucial for percentage calculations and subtotals. For a percentage discount, the 'From' field references the step number whose value serves as the base for the percentage. 'From' and 'To' can also define a range of preceding steps to be summed into a subtotal.

  • Manual (Man.): Indicates if the condition type can be entered or changed manually in the sales document. Some conditions are purely automatic, others purely manual, and some can be automatic with manual changes allowed.

  • Mandatory (Mand.): If checked, the condition type must have a value during pricing. If the system cannot find a value (e.g., a missing condition record for a mandatory price), it may result in an error or an incomplete status.

  • Statistical (Stat.): If checked, the value of this condition type is for informational purposes only and does not affect the net value of the item. Examples include internal cost (VPRS) or some types of informational discounts.

  • Print (P): Controls whether the condition type and its value are printed on documents like order confirmations or invoices.

  • Subtotal (SubTo): Specifies how the value of the condition line is stored in temporary memory fields (e.g., KOMP-KZWI1 to KZWI6, or XWORKD, XWORKE etc.) for use as a base for other calculations or for informational subtotals (e.g., 'Net Value', 'Gross Value').

  • Requirement (Reqt): Assigns a routine (a small ABAP program or predefined logic) that checks if certain prerequisites are met before the condition type is processed. If the requirement is not met, the condition type is skipped.

  • Alternative Calculation Type (AltCTy): Assigns a routine that can override the standard calculation logic defined in the condition type (e.g., for complex group condition calculations).

  • Alternative Base Value (AltCBV): Assigns a routine that can determine an alternative base value for percentage calculations, instead of using the value from the 'From' step.

  • Account Key (AccKey / ActKy): This key links the condition type's value to specific G/L accounts in Financial Accounting for revenue, sales deduction, or tax postings (e.g., ERL for Revenue, ERS for Sales Deductions, MWS for Output Tax).

  • Accruals Key (Accruals): Used for conditions that post accruals, such as freight clearing or rebate accruals (e.g., ERU for rebate accruals).

Standard vs. Custom Pricing Procedures

SAP S/4HANA Cloud provides standard pricing procedures as part of its Best Practice content, tailored for common business processes and countries. It is highly recommended to review these standard procedures first to see if they can meet your company's requirements, possibly with minimal adjustments.

If significant deviations are needed, you can create custom pricing procedures. The best practice is to copy an existing standard pricing procedure that most closely matches your needs and then modify it. Custom pricing procedures should be named within the customer namespace (starting with 'Z').

The Process of Defining Pricing Procedures

Defining new or modifying pricing procedures is a critical configuration task. In a project setting for SAP S/4HANA Cloud (3-tier landscape), this is primarily managed through SAP Central Business Configuration (CBC).

The general (high-level) process involves:

  1. Analyzing and documenting the required calculation logic, including all necessary prices, discounts, surcharges, taxes, and freight, and their sequence.
  2. Identifying the condition types that will represent each of these pricing elements.
  3. Accessing the relevant configuration activity (SSCUI) for pricing procedures within your CBC project (e.g., often named "Set Pricing Procedures" or "Define and Assign Pricing Procedures").
  4. Deciding whether to adapt a standard procedure or create a new custom one (usually by copying a standard one).
  5. If creating a new procedure, assigning a unique ID (e.g., ZDOM01) and a descriptive name.
  6. Building the procedure step-by-step: adding condition types in the correct sequence, assigning step and counter numbers, and maintaining all the control fields (From, To, Manual, Mandatory, Statistical, Subtotal, Requirement, Account Key, etc.) for each line.
  7. Saving the pricing procedure definition.
  8. This new or modified pricing procedure, once defined and confirmed in CBC, will be part of a deployment to your S/4HANA Cloud development system and subsequently transported through your landscape.
  9. After deployment, the pricing procedure must be assigned through pricing procedure determination configuration to be used in sales transactions (this determination is usually based on criteria like Sales Area, Document Pricing Procedure, and Customer Pricing Procedure).
A conceptual mockup of a configuration screen for a Pricing Procedure. It shows a table with columns: Step, Counter, CTyp (Condition Type), Description, From, To, Man, Mand, Stat, SubTo, Reqt, AccKey. Example rows show PPR0 (Base Price), YK07 (Customer Discount) with 'From' pointing to PPR0 step, a subtotal line for Net Value, a tax condition, and a final total line.

Summarizing Pricing Procedure Configuration

Key Takeaways for Pricing Procedures

  • A Pricing Procedure defines the sequence and calculation logic for all pricing elements (condition types) in a sales document.
  • It is a structured list of steps, each potentially containing a condition type and critical control indicators.
  • Key control fields include Step, Counter, Condition Type, From, To, Manual, Mandatory, Statistical, Subtotal, Requirement, Account Key, and Accruals Key.
  • SAP provides standard procedures; custom procedures (Z namespace) are typically created by copying and adapting standard ones.
  • Definition is primarily managed via SAP Central Business Configuration (CBC) in new S/4HANA Cloud projects.
  • For a pricing procedure to be used, it must be correctly assigned via pricing procedure determination configuration.

Best Practices for Pricing Procedure Management

  • Keep it Simple: Aim for the simplest procedure that meets business needs. Overly complex procedures are hard to maintain and troubleshoot.
  • Leverage Standard Logic: Understand and utilize standard SAP functionalities like requirements, formulas, and subtotal logic before resorting to extensive custom development.
  • Document Thoroughly: Clearly document the purpose of each step, the logic behind requirements or formulas used, and the G/L account assignments.
  • Test Rigorously: Test procedures with a wide variety of sales scenarios, customer types, and product combinations to ensure accuracy. Pay attention to subtotals and final values.
  • Consistent Naming: Use clear and consistent naming conventions for custom procedures.
  • Impact Analysis: Before changing an existing procedure, analyze the potential impact on ongoing business and other integrated processes.

Designing Key Steps for a Simple Pricing Procedure (Conceptual Exercise)

Your company needs to set up a very basic pricing procedure for domestic sales in SAP S/4HANA Cloud. The requirement is to calculate a net value and then apply tax to arrive at a final total.

The pricing elements to be included are:

  • A Base Price (e.g., using condition type PPR0)
  • A Customer Discount (e.g., using condition type YK07, calculated as a percentage of the Base Price)
  • A Subtotal representing the Net Value before tax.
  • A standard Sales Tax (e.g., using condition type MWST or a similar output tax type, calculated on the Net Value)
  • A final Total Price.

Prerequisites

You have completed Concept: "Understanding and Configuring Pricing Procedures" and are familiar with the key columns/fields in a pricing procedure definition (Step, Counter, Condition Type, From, To, Manual, Mandatory, Statistical, Subtotal, Account Key, etc.).

You understand the purpose of condition types like PPR0 (Price), YK07 (Customer Discount, assumed to be percentage-based here), and a tax condition type like MWST.

Steps

  1. Outline the logical sequence for these pricing elements in the new pricing procedure. Propose appropriate Step numbers (e.g., in increments of 10 or 100) and Counter numbers (usually 0 if only one condition at a step).

    Think about the typical calculation flow: start with a price, apply discounts, arrive at a net value, then apply taxes.

    1. A logical sequence with example Step/Counter numbers would be:

    2. Step 100, Counter 0: Condition Type PPR0 (Base Price)

    3. Step 110, Counter 0: Condition Type YK07 (Customer Discount)

    4. Step 120, Counter 0: (Subtotal Line for Net Value before Tax)

    5. Step 130, Counter 0: Condition Type MWST (Output Tax)

    6. Step 140, Counter 0: (Subtotal Line for Total Price)

  2. For Condition Type PPR0 (Base Price) at Step 100, should it typically be marked as 'Mandatory' in the pricing procedure? Explain your reasoning.

    1. Yes, the Base Price condition type (PPR0) should typically be marked as 'Mandatory'.

    2. Reasoning: A base price is fundamental for any sales transaction. If the system cannot determine a base price for an item, the pricing is usually considered incomplete or erroneous. Making it mandatory ensures the system flags an issue if a price is missing.

  3. For Condition Type YK07 (Customer Discount) at Step 110, assuming it's a percentage discount based on the Base Price (PPR0), what value would you enter in the 'From' column? Also, suggest a typical 'Account Key' for a customer discount.

    The 'From' column tells the system which previous step's value to use as the base for percentage calculations.

    1. In the 'From' column for Step 110 (YK07), you would enter the step number of the Base Price, which is 100 (the step for PPR0).

      This tells the system to calculate the 5% YK07 discount based on the value determined at Step 100.

    2. A typical 'Account Key' for a customer discount like YK07 would be ERS (Sales Deductions) or a similar key configured for posting discounts to the appropriate G/L accounts.

  4. For Step 120, intended to represent "Net Value before Tax," what would you typically enter in the 'Condition Type' column, and which control field is crucial for making this line act as a subtotal and store its value?

    Subtotals don't have their own condition types in the typical sense; they are calculation results.

    1. In the 'Condition Type' column for Step 120, you would typically leave it blank as this line represents a subtotal, not a specific condition type to be determined from a condition record.

    2. The crucial control field is the 'Subtotal' (SubTo) column. You would select a value here (e.g., 'S' for certain standard subtotals, or assign it to a subtotal field like KOMP-KZWI1 through KOMP-KZWI6) to indicate that the calculated value up to this point should be stored and can be used as a base for subsequent conditions (like tax).

    3. You would also enter a descriptive text like "Net Value before Tax" in the 'Description' column for this step.

  5. For the Tax Condition Type (MWST) at Step 130, which previous step's value should it ideally use as its calculation base (entered in its 'From' column)? What is a typical 'Account Key' used for output tax?

    1. The Tax Condition Type (MWST) at Step 130 should typically use the "Net Value before Tax" as its calculation base. Therefore, in its 'From' column, you would enter the step number of the Net Value subtotal, which is 120.

    2. A typical 'Account Key' used for output tax conditions like MWST is MWS (or a country-specific equivalent).

Result

By completing this exercise, you have conceptually designed the key steps of a simple pricing procedure. You have determined the sequence of condition types and subtotals, and considered important control settings like 'Mandatory', 'From' references for calculations, and 'Account Keys' for G/L integration.

This design provides a basic framework that could be implemented in SAP Central Business Configuration (CBC) to create a functional pricing procedure for domestic sales transactions.

Learning

SAP FacebookSAP YoutubeSAP LinkedIn