Reviewing the Theory of Pricing Configuration

Click Play, then click on the pillars to get further information.

In pricing, conditions such as prices, discounts, surcharges, freight, and taxes, must be determined automatically for business transactions. A condition type is the template or formula for one part of the overall pricing calculation. Condition types define how an individual pricing calculation will take place and serve as the template or pattern for condition records.

The levels at which pricing is most commonly performed are predefined in the SAP standard system.

However, you can define conditions at any key level. Therefore, you can add key levels if required. A standard field catalog containing the fields that are commonly used in pricing is provided within Customizing for this purpose. You can add other fields to the field catalog.

The master data for price conditions is stored in condition records.

Condition records are always defined for a key combination that is assigned to the respective condition type. You can also assign several possible key combinations to a condition type, such as in the standard condition type PR00 ( Price ).

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

Examples:

● Different price lists for different years.

● Discounts that are given only for the duration of a special offer.

You can define the values in a condition record, such as price, surcharge, and discount, according to a scale. There is no limit to the number of scale levels.

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.

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.

The table above 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

● Sales document (document pricing procedure)

● Sold-to party (customer pricing procedure)

Pricing Procedure Attributes

Customizing for 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 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 subkey to enter conditions at the same level in the pricing procedure.

An access sequence defines the search strategy to locate the proper 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 depending on the requirements 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 create a condition record by using the specified key.

The system searches for valid condition records by using the key that is 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 system completes the entire pricing procedure.

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 the new elements.

If you have to create all the elements without using any existing elements, you must configure the pricing elements in the opposite order in which you use them in pricing. Therefore, if you want to create new objects, such as a new condition type with a new access sequence, you must start by creating the condition table.

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 defining 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 have to 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 surcharges or discounts 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 refers to several condition tables.

You can only assign one access sequence to each condition type

Condition types are combined 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 not allow other conditions if a particular condition is used. For example, if a certain type of discount is used, other discounts are not allowed.

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 customer pricing procedure indicator in the customer master.

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