Configuring Condition Types for Pricing Elements

In SAP S/4HANA Cloud, a Condition Type is a fundamental building block of the Condition Technique. It represents a specific kind of pricing element that can occur in your daily business transactions. Essentially, each price, discount, surcharge, tax, or freight charge you want the system to consider during price calculation needs to be defined as a distinct condition type.

Well-defined condition types are essential for accurately reflecting your company’s pricing strategy. They provide the flexibility to differentiate between various charges and allowances, apply them under specific circumstances, and control how they are calculated and behave within the overall pricing procedure. This lesson focuses on how to configure these vital elements.

When you configure a condition type in SAP S/4HANA Cloud (typically via SAP Central Business Configuration - CBC for project implementations), numerous control parameters determine its behavior. Key settings include:

• Condition Class: This classifies the condition type. Common classes are 'B' for Prices, 'A' for Discounts or Surcharges, 'D' for Taxes, and 'F' for Freight. This classification influences how the condition is processed.

• Calculation Type: This dictates how the system calculates the amount or value for the condition. Examples include 'A' (Percentage, e.g., a 5% discount), 'B' (Fixed Amount, e.g., a $10 surcharge), 'C' (Quantity-dependent, e.g., $2 per piece), or 'G' (Formula, for complex calculations).

• Condition Category: This provides further classification for specific purposes. For instance, 'E' (Cash Discount), 'L' (Generally new price that re-determines subsequent conditions), 'Q' (Costing, e.g., VPRS for internal cost).

• Plus/Minus Indicator: Determines if the condition amount is positive (surcharge), negative (discount), or can be either. For example, discounts usually have a negative indicator.

• Access Sequence (Optional): This links the condition type to a search strategy for finding condition records. If an access sequence is assigned, the system will try to determine the condition value automatically. If left blank, the condition type is typically intended for manual entry.

• Item Condition vs. Header Condition:

  • Item conditions apply to individual line items in a document. Most pricing elements are item conditions.
  • Header conditions apply to the entire document and are typically distributed among the items.

• Group Condition: If set, the condition value is calculated based on a cumulative value from multiple items (e.g., a discount based on the total quantity of all items in a group).

• Manual Entries: Controls the extent to which the condition type can be processed manually in a sales document (e.g., cannot be changed, manual entry has priority).

• Scales: Defines if scales (e.g., quantity scales, value scales) can be used with the condition type to determine different rates based on different base values.

SAP S/4HANA Cloud delivers a wide range of pre-configured standard condition types to cover common pricing scenarios (e.g., PPR0 for price, DM01 for material discount, standard tax conditions). Before creating a new condition type, it is crucial to check if a standard one can meet your business requirement, perhaps with minor adjustments to its settings.

If a standard condition type is not suitable, you can create custom condition types. The best practice for creating custom condition types is to copy an existing standard condition type that closely matches your needs and then modify its parameters. Custom condition types should be named within the customer namespace (starting with 'Z').

Defining new custom condition types or modifying existing ones is a core 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. Clearly defining the business need for the pricing element (e.g., a new type of customer loyalty discount).
2. Checking if any standard condition type can be used or adapted.
3. If a new type is needed, accessing the relevant configuration activity (SSCUI) for condition types within your CBC project (e.g., General Business Data→Price Management→Sales Pricing→Settings for Pricing in Sales→Set Condition Types for Pricing in Sales).
4. Deciding whether to create a new entry or copy an existing, similar standard condition type (copying is recommended).
5. Assigning a unique ID (e.g., YL01) and a descriptive name for your custom condition type.
6. Maintaining all the necessary control parameters as discussed earlier (Condition Class, Calculation Type, Access Sequence, Plus/Minus, Item/Header flags, etc.) according to the requirement.
7. Saving the new condition type definition.
8. This new or modified condition type, 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 condition type needs to be included in the relevant Pricing Procedures to become active in sales transactions.

• Condition Types are the building blocks representing specific pricing elements (prices, discounts, surcharges, taxes, freight).
• Key control parameters like Condition Class, Calculation Type, and Access Sequence assignment dictate how each condition type behaves.
• SAP provides standard condition types; custom types (Z namespace) are created by copying and adapting standard ones when necessary.
• Definition of new condition types for projects is primarily managed via SAP Central Business Configuration (CBC) in a 3-tier S/4HANA Cloud landscape.
• Once defined, condition types must be included in Pricing Procedures to be active.

• Always analyze if a standard condition type can meet the requirement before creating a custom one.
• When creating custom types, copy from a similar standard type and adjust, rather than creating from scratch. This ensures many underlying settings are pre-filled correctly.
• Use clear and meaningful IDs and descriptions for custom condition types.
• Thoroughly test any new or modified condition type in various scenarios within the relevant pricing procedures.
• Document the purpose and configuration of all custom condition types.