Reviewing the Theory of Pricing Configuration

The overall price of a sales order is calculated based on multiple order items, with each item's value made up of various price elements, also known as price conditions.

Consider a sales order that includes two items: a laptop and a printer. Each item has its own base price and may have additional price elements such as discounts, surcharges, and taxes applied to it. The overall price of the sales order is computed by summing the prices of all items and applying relevant price elements to reach the final total price.

Let's consider some example values:

• The laptop has a list price of $1000, but a 10% discount is applied as a price condition. So, the final price is $1000 - $100 (discount) = $900.
• The printer has a list price of $200, but a $20 additional surcharge is added as a price element. So, the final price is $200 + $20 (surcharge) = $220.

To calculate the overall price of the sales order, the system first determines the total price for each item, then sums these totals. In this case, it would add the calculated prices of the laptop and printer ($900 + $220 = $1120).

Additionally, header-level price elements can be applied. These price elements are calculated based on the order's total amount. For example, if the combined cost of the laptop and printer is $1120, and an additional 10% discount is applied for orders over $1000, the final total would be $1120 - $112 (header-level discount) = $1008.

In summary, the system calculates the final total price for the entire sales order by considering the prices of all individual items and their associated price elements, plus any header-level price elements applied to the order total.

You can review the Price Conditions and the calculated values in the Conditions view of the Create Sales Order app.

Price conditions can be either manually set by the user or automatically determined using master data. For instance, a company may have predefined master data called Condition Records that dictate a 10% discount for a specific customer, say Customer ABC. When a sales order is generated for Customer ABC, the system automatically applies the discount based on these condition records, eliminating the need for manual intervention. This automation not only speeds up the order entry process but also minimizes the risk of human error in calculating the final sales order price.

Condition records are part of the master data that define the pricing conditions for sales and distribution processes. They specify the terms and conditions, such as discounts, surcharges, taxes, and freight costs, that apply to a particular business transaction. Condition records are used to automate and control the pricing process, ensuring consistent and accurate pricing for customers and products.

You can use the Manage Prices - Sales app to maintain Condition Records.

Condition records are categorized by condition types, which define the purpose of the condition, such as discounts (e.g., customer discount, material discount) or surcharges (e.g., peak season surcharge).

For every condition type, condition records are always defined based on a key. A key is a sequence of fields that tells the system when to apply the condition record.

For example, a condition record you could have:

• Condition Type: PR00 (Base Price)
• Key Field: Sales Organization (1010), Material Number (e.g., LAPTOP1001)
• Value: $1000

This condition record says that, in the Sales Organization 1010, the base price for the laptop model `LAPTOP1001` is $1000.

Given a condition type, you can also assign several possible key combinations.

For example, the standard condition type PPR0 ( Price ) foresees the following sequence of key combinations:

1. Sales Organization, Distribution Channel, Customer, Material
2. Sales Organization, Distribution Channel, Material

A a consequence, you can use the second key to value a generic material price, and you can use the first one to value a Customer-specific material price.

By using different keys, you can set up condition records that apply specific pricing rules in different scenarios.

Practical Example: Suppose your company sells laptops, and you want to set up different price conditions based on various factors.

1. Base Price for a Specific Laptop
   • Condition Type: PR00 (Base Price)
   • Key Field: Material Number (e.g., LAPTOP1001)
   • Value: $1000

   This condition record says that the base price for the laptop model `LAPTOP1001` is $1000.

2. Bulk Purchase Discount
   • Condition Type: K004 (Bulk Purchase Discount)
   • Key Fields: Material Number (LAPTOP1001), Quantity (>=10)
   • Value: 10% discount

   This condition record specifies that if at least 10 units of `LAPTOP1001` are purchased, a 10% discount is applied.

3. Special Offer for a Specific Customer
   • Condition Type: ZC01 (Customer-Specific Discount)
   • Key Fields: Customer Number (CUST2001), Material Number (LAPTOP1001)
   • Value: -5% discount

   This condition record indicates that if customer `CUST2001` purchases `LAPTOP1001`, a 5% discount is applied.

4. Seasonal Promotion
   • Condition Type: ZP01 (Seasonal Promotion)
   • Key Fields: Sales Document Type (Promotion), Material Number (LAPTOP1001)
   • Value: $50 off

   This condition record applies a $50 discount to `LAPTOP1001` if the sale is part of a seasonal promotion.

How It Works During Order Processing Let's say Customer `CUST2001` places an order for 15 units of `LAPTOP1001` during the seasonal promotion.

When the order is processed, the system will check the condition records and apply the appropriate pricing conditions. In this case, the system will recognize that the customer is eligible for a bulk purchase discount (-10% = -$100) and a customer-specific discount (-5% = -$50), as well as the seasonal promotion discount (-$50).

As a result, the final price for each unit of `LAPTOP1001` will be calculated based on these condition records ($1000 - $100 - $50 - $50 = $800), providing the customer with the most cost-effective pricing based on the specific order details and conditions.

In addition, you can specify a validity period to limit a pricing agreement to a specific period.

For example:

• Different price lists for different years.
• Discounts that are given only for the duration of a special offer.

You can specify an upper limit and a lower limit for each condition record. If you want to manually change the pricing elements that are determined by the system, you can do so only within these limits.

You can define the values in a condition record, such as price, surcharge, and discount, according to a scale.

Scales are used to set specific values based on different factors, like the quantity of items being purchased. Scales condition records are essentially a way to apply different pricing based on certain criteria.

The condition type determines the category of a condition and describes how the condition is used.

For each condition type, you can control the scale base type and the calculation type.

There is no limit to the number of scale levels.

For example, many businesses offer bulk purchase discounts to incentivize customers to buy larger quantities. For example, a wholesale supplier might provide a lower per-unit price for a product if a customer purchases a certain volume. Scales could be used to automatically apply these bulk purchase discounts based on the quantity of items ordered, ensuring that the correct pricing is consistently and accurately applied.

The table below lists the possible scale base types and calculation types:

A pricing procedure is a sequential list of condition types and subtotals that are used to calculate the price at the item and header levels of a document.

All condition types that are permitted for a transaction in pricing are contained in the pricing procedure.

The pricing procedure is determined in Customizing according to the following criteria:

• Sales area (consisting of sales organization, distribution channel and division)
• Sales document (document pricing procedure field)
• Sold-to party (customer pricing procedure field)

Configuration of pricing procedures contains a variety of attributes that can influence the processing of individual condition types.

Some of these attributes are as follows:

• Level (Step): The level in the pricing procedure determines the sequence in which the system processes and places the conditions in the sales document (where applicable).
• Subtotals: The pricing procedure can contain any number of subtotals. To define subtotals, leave the Condition Type field blank and enter a name for the subtotal in the Description field.
• Condition formula: The condition formula in the pricing procedure allows you to define an alternative base for calculating the condition value and for consolidating conditions for subtotals. The default base is the current value that resulted from processing the previous condition types.
• Requirements: You can specify requirements (ABAP routines) to determine how the system must use the individual condition types.
• Specific settings: you can mark a condition type in the pricing procedure as a condition that is mandatory, a condition that can only be entered manually (any existing access sequence is ignored in this case), or as a condition that can be used for statistical purposes only.

If you want to retain the input sequence for manual conditions, these conditions must appear at the same level. Use the Counter sub-key to enter conditions at the same level in the pricing procedure.

An access sequence defines the search strategy to locate the correct condition record of a specific condition type to which the access sequence is linked. This search strategy defines the sequence in which the system reads the condition records for a condition type. Every condition type that retrieves its data from condition records uses an access sequence.

An access sequence can be assigned to a condition type (except for condition types that are configured as a header condition).

Each access within an access sequence describes the key fields for the desired condition record. Each line or access in an access sequence references a condition table.

A condition table defines the key fields that are used for a condition record.

If an access sequence contains more than one access, the accesses are usually arranged from specific to general in descending order.

An access can also be made dependent on the requirements (ABAP routines) that are assigned in the access sequence.

The system determines the relevant pricing procedure based on the sales area, customer, and sales document type.

The system reads the condition type and determines the access sequence that is assigned to this condition type.

The system reads the access sequence. The sequence of condition tables represents the search strategy for finding the relevant condition record.

Each condition table represents one access, which can be used to read a condition record by using the specified key.

The system searches for valid condition records by using the key specified by the condition table (accesses).

If the first access does not find a valid condition record, the system searches for the next access by using the next condition table.

After the system finds a valid condition record for an access, the system reads the condition record and copies the value that corresponds to the scale into the sales document.

The system repeats the entire process for each condition type until the entire pricing procedure has been processed.

If you need new elements for pricing, you first check whether you can use the existing condition tables, access sequences, or condition types to create these elements.

If you cannot use the existing elements directly, you can copy them and use them as a base for creating new elements.

If you have to create all the pricing elements without using any existing elements, you must configure the pricing elements in the reverse sequence to that used when pricing an order. So, for example, if you want to create a new condition type with a new access sequence, you must start by creating the condition table(s).

The first step in pricing configuration is to create a new condition table, if the required key combination (condition table) is not already available in the standard system.

A condition table defines the structure of the key that you can use to create dependent condition records. To create your own condition tables, use the customer namespace from 501 to 999.

The most important fields that are used in pricing at the header and item levels are available in the standard system.

The key fields of a condition table must appear at the top of the table.

In the condition table, you can determine whether a field appears in the header or in the item part of the fast entry screen that is generated for creating condition records.

Customizing for pricing is restricted by the catalog of allowed fields for condition tables. If a particular situation requires an exception to this rule, you can use the release-neutral procedure to add additional fields to the catalog.

The information that you need to add new pricing fields is available in the customizing documentation in the Self Service Configuration User Interface for the element 'Change Field Catalog' under the Sub Application Area 'Price Management'..

You can define prices, discounts and surcharges at various levels by using an access sequence.

Each level is defined by a condition table.

The hierarchy of the different levels is determined by the sequence of the entries in an access sequence.

The sequence of these tables determines the sequence in which the system searches for valid condition records. Therefore, you must ensure that the condition tables are in the correct sequence, from specific to general.

In an access sequence, the Document Structure and Document Type fields specify the exact data that will be used to build the access sequence key. Therefore, the condition table may specify the Customer field, for example, but the access sequence specifies the partner function that is read to supply the customer number.

You can create your own condition type by copying and adjusting an existing condition type. You can determine the characteristics of each condition type. For example, you can determine whether the condition type represents a surcharge or a discount, and whether it is dependent on values or quantities.

If the value of a condition type must be determined from a condition record, you must assign an access sequence to the condition type. If the condition type uses multiple keys for the condition records, the access sequence must refer to several condition tables.

You can only assign one access sequence to each condition type

Condition types are included in the required sequence in the pricing procedure. The pricing program can only execute the condition types that are contained in the pricing procedure.

Group conditions allow you to combine the condition base value from multiple items before calculating the price or discount. As a result, you can use the total quantity of a group of items to determine a discount.

In Customizing, you can set a condition type to be a group condition. The condition base value, such as weight, is then calculated as the sum of the individual items within a group.

Conditions can be linked to requirements in the pricing procedure. A requirement can evaluate the condition exclusion indicator and, if this indicator is set, ignore the condition.

The condition exclusion indicator can be set in either the condition type or the condition record.

You can create your own exclusion indicators and test for the existence of the indicator in the requirement routines.

If the exclusion indicator is selected in a condition type or a condition record, all the condition types in the pricing procedure that meet the following criteria are ignored:

● The condition types that follow the condition type for which the exclusion indicator is set.

● The condition types to which a requirement routine is assigned to check for the exclusion indicator.

There is a difference between setting the exclusion indicator in the condition type and the condition record;

• If the indicator is set in the condition type, the exclusion applies to all the condition records of that type.
• If the indicator is set in the condition record, the exclusion applies only to that record. Other condition records of the same type are not affected.

You can use condition exclusion to exclude other conditions if a particular condition is used. For example, if a certain type of discount is used, other discounts are excluded.

You can use the condition exclusion function to compare various conditions, or groups of conditions, and select the most favorable or least favorable pricing conditions.

Customizing gives you the option to define exclusion groups. As a result, you can compare various condition types and activate only the required conditions during pricing. The system will activate the discount and/or the pricing conditions within the exclusion group based on the type of setting you use.

The condition types that need to be compared are first placed in an exclusion group.

During pricing, the system selects the conditions that result in the best price (lowest charge or highest discount) from this group. The system deactivates all other conditions.

Comparison Methods for Condition Types

There are several comparison methods that can be used for comparing condition types.

Some of the comparison methods are as follows:

● A All conditions records in the first exclusion group are compared with each other and the condition with the best price is selected. All other conditions are deactivated.

● B All condition records for one condition type are compared with each other and the condition with the best price is selected. All other conditions are deactivated. This method can be used with condition type PR00.

● C The overall price of all condition records in the first exclusion group is compared with the overall price of all condition records in the second exclusion group. The group resulting in the best price is selected. The conditions of the other group are deactivated.

● D If a condition record is determined for the condition types of the first exclusion group, all the condition records for the second exclusion group are deactivated.

● E Method E is similar to method B, except that the worst (highest charge or lowest discount) price is selected.

● F Method F is similar to method C, except that the group with the worst overall price is selected. The conditions of the other group are deactivated.

● L Method L is similar to method A, except that the worst (highest charge or lowest discount) price is selected.

The pricing procedure is determined based on the following factors:

● The sales area.

● The document pricing procedure indicator in the sales document type.

● The customer pricing procedure indicator in the customer master (sold-to party).