The Complete Beginner’s Guide to SAP SD Pricing configuration

I hope you are well aware of SAP SD Pricing configuration, In Today’s blog we are focusing more on the advanced SD Pricing functionality & controls.In real-time, The main challenge lies in understanding the special pricing scenarios where we need to implement the advance pricing. If we are the inter-company pricing material, the varied tax structures pertaining to different geographies must be understood to perform the correct pricing for the same material.

Advanced pricing takes into account the various diverse market situations. This may be seen when the price of the same commodity varies due to a different distribution procedure. It can be used when the same customer purchases the product in a specified quantity or volume. Or when the price depends on other costs and prices and has a dynamic nature rather than a fixed one.

Advanced pricing is basically addressing these complex pricing scenarios…

Pricing in SD

Pricing combines creating correct pricing procedures that map the business’s needs and processes. This includes correct pricing and discounting and compliance with the legal requirements placed on a company, such as compliance with the tax laws of the country concerned.

Pricing is an essential component of sales and distribution (SD) processes, affecting revenue, profitability, customer satisfaction and market positioning. Pricing determines the monetary value assigned to products and services, which leads to revenue generation; profit margins depend on effective strategies which balance competitiveness with healthy margins while reflecting company brand identity. Market positioning influences pricing strategies, while strategic pricing aims at aligning with healthy competitive margins while taking account of dynamic market conditions, consistency across channels, data accuracy as well as any errors that might arise with pricing errors. Volume discounts, seasonal promotions and contract pricing optimization require continuous optimization strategies in order to maximize revenue generation while optimizing volume discounts, seasonal promotions and contract pricing.

Condition Technique

Condition is the single largest configuration technique used in the SD module. It is also used for pricing. The SAP condition technique is used to find a choice between several alternatives. SAP chooses based on the conditions, hence the name condition technique.

Although the condition technique is a pillar of SD pricing, it also involves other advanced features. Business scenarios are rarely too simple to take care of standard pricing configurations.

For example, a condition record for a scale of 100 articles may be maintained, but the business requires that document pricing be carried out at a rate intended for 10 articles.

Here, SAP will need an alternative calculation technique by bypass that used in the condition technique.

Again, the currency retained in the condition record can differ from the document currency. Businesses can allow pricing to be made in the document currency for which currency conversion needs to be carried out.

SAP includes some primary fields at the level of the condition form to handle these situations.

In a similar way, the company also needs the benefit to be decided in the calculation process. In order to do so, it requires the cost of producing the article to be reported at the process stage. The method will then deduct the same from the cost of sales (net value) to the income. SAP offers special condition types such as – VPRS (cost) etc. to meet these business requirements.

In a complex business process, we often find scenarios in which pricing needs to be carried out on the basis of certain requirements. e.g. a sales order can contain both stock and non-stock products. In this case, the program is not expected to check for non-tock status information.

For this type, SAP has provided certain requirements that exclude the system from pricing for certain special situations.

Thus to carry out advanced pricing in SD :

• We need a detailed review of the pricing process
• Comprehension of price procedure elements such as – alternative calculation form, subtotal, alternative condition base value, etc.
• Understand certain key fields in the type of condition
• Understand the importance of common special condition categories such as VPRS, SKTO, etc. in business requirements. Understand some of the dynamic pricing conditions

Overview of Pricing procedures in SD

The pricing procedure in sap sd is a very complex one. It involves the following, The price procedure is simply a process of evaluating the price using the condition technique. It is where the condition types are sequentially grouped together.

Let’s understand the SAP SD Pricing Procedure.

Pricing is one of the most important aspects of a business. We will show you the 16 fields in the pricing procedure in sap sd that are involved in the pricing procedure and how they can be used in your pricing procedure.

Step number

This shows the number of steps involved in the process. For example, Step 10 should be the first condition type, Step 20 should be the second condition type, and so on.

Condition counter

the indicator is next to the column move. It is used to demonstrate a second mini-step in the main stage. For example, we may have all freight surcharges allocated to Step 100; however, there may be three conditions, each representing a different freight surcharge. So we may allocate a form of freight cond to Step 100, counter 1; another to Step 100, counter 2, and so on.

Condition Type

The type column is the type of condition. This is the cornerstone of the pricing cycle. Upon entering the condition type, the Description field will be automatically filled with a description of the condition type.

From and To

They are also from and to the columns. They shall be used in two circumstances:-

To define the range for a subtotal

For example, if we want to add all the condition types from phase 10 to 50, we will enter 10 and 50 in the Fro and To columns, respectively.

To define the basis for a calculation

For example, if the discount is specified as a percentage, we need to indicate the phase that should be used as the basis for the calculation. If the calculation is to be carried out from phase 100, we will enter 100 in the field below..

Condition determined manually.

The Man column indicates whether the condition type can only be processed manually or automatically.

Condition is mandatory

The required column describes the types of requirements that are required in the pricing process. The two mandatory condition types are the sale price and the expensive price. If a mandatory condition type is not found in the procedure, the system will cause an error in pricing.

Condition is used for statistics

The condition form marked as statistical or stat will not be included in the calculation of the net value for that element. The net value is shown in the order and invoice object information and the overall net value of all items is shown in the order and invoice document.

Print ID for condition lines

The thin column that follows Stat is called Print. The print indicator determines which definitions and associated values assigned to a phase are printed on a document, such as order confirmation.

Alternative calculation type, subtotal, alternative condition base value etc

The functionalities of the subtotal, the criteria, alternative types of measurement, alternative condition base, account keys, and the value of these in advanced sd pricing are outlined in this section.

Subtotal

The subtotal field assigns the subtotal key to the price procedure step. These subtotal fields are then used in other areas of the system, such as the Logistic Information System ( LIS). For example, it is recommended that the subtotal field 4 be assigned to the total value in the Freight pricing procedure.

Requirement

The requirement is used to assign a condition type requirement. This requirement can then be used to exclude the system from accessing the condition type and trying to determine the value. For example, a requirement can be used to specify that a condition type, a discount, should be accessed only if the customer has a low-risk credit group.

The most commonly used requirement routine is 2, which is a price item. It would therefore be valid enough to see how it is used in the pricing procedure. This requirement is met if the category of the document item is relevant for pricing and no prior condition in the price procedure has been set for the exclusion condition.

E,g: The sales order is placed in the system. Some of the items in the order are free of charge to the customer, and the item category for them is set as TANN. The item category TANN has been configured as not relevant for pricing in the IMG. In the pricing procedure, requirement 2 is assigned to all conditions. Using this requirement, the system cannot access price condition records for free line items. Again, some of the prices are defined as net prices. A subsequent discount or surcharge should be assigned to the item if a net price is found. Requirement 2 also ensures that additional condition records are not accessed when the net price for the item has already been determined.

Alternative calculation type

The AltCty column specifies that the system is to use the formula represented in this column as an alternative to the condition type value, rather than using the standard condition technique. This can be used, for example, to calculate complex tax scenarios

The most commonly used AltCty formula is 2 which is Net Value. A condition type or value line can be assigned to the price. Formula ‘2’ sets a value equal to the net value calculated so far for the item in the price procedure. It includes the amount excluding taxes.

Example-A company would like to display subtotals on its price screen representing the gross value, net value and net value 2. These are all value lines in the pricing procedure that do not correspond to a specific type of condition. The user assigns the AltCty formula 2 to determine the value for these value lines.

Alternative condition base value

Column AltCBVis a formula assigned to a condition type to support an alternative base value for calculating a value. For example, a formula that uses a subtotal, such as 4, can be slightly modified from the Subtotal field, dividing it by 2, and then using the resulting value as the base value for the condition type.

The most commonly used AltCBV routine is 2 which is Net Value. It is assigned to the type of condition in the pricing procedure. Formula ‘2’ uses the net value of the line sales document item.

Example-A company applies SKTO fixed header cash discount to a sales order. Fixed header conditions are always spread across the line items in the document. In this case, the company would like to distribute the fixed amount based on the net value of the line items. In order to do this, the user would assign the alternative condition base value formula ‘2’ to the header discount condition type in the pricing procedure.

ActKey and Accruals

Account and account keys are used to grant account keys, which are then assigned to GL accounts that FI uses to register posts. The ERL key is used to post-sales revenue to GL. Whereas, ERF is used to deduct sales to GL. The accrual key is used for accrual condition types such as Rebates and freight.

The determination of the account will take place on the basis of the account keys assigned in the pricing procedure. Here in TCode – VKOA, the appropriate GL will be posted based on Account Keys, Condition Types, Account Charts, and Sales org.

Certain Controls fields in condition type

The system uses the condition class to determine which conditions it must re-determine and when. The system would re-determine the following types of conditions.

• Taxes (condition class D)
• Rebates (condition class C)
• Inter company billing condition types (condition class I)
• Cost conditions (condition category G)
• Cash discounts (condition category E)

“Copy price elements unchanged and reconsideration of taxes,” type G, is in copy control price

• Rounding rule – It is based on which the value for the condition type is rounded. The system would use commercial rounding to find a condition type value if left blank. In commercial rounding, a value less than 5 will be rounded down, and a value greater than or equal to 5 will be rounded up.

• Group condition: Group status – It indicates whether the system calculates the scale value base on more than one item in the document.

In order for the group condition to be effective, the items must belong to a group. Items may, for example, all belong to the same materials group.

Example-A sales order contains two items. Both items belong to material group 01. The group condition indicator is set out in the definition of the type of condition for material group discounts. Neither item alone is eligible for a discount on its own. However, when the items are combined as part of the group condition, the combined quantity provides the basis for the discount. This basis then exceeds the scale value needed to qualify for the higher discount.

• Currency conversion – If marked, this indicator will cause the system to convert the currency from the condition currency to the document currency after the multiplication of the terms. If the value is not marked, the system converts the currency of the condition to the document’s currency before multiplying the items’ value.

• Accruals – Indicates that the system posts the amounts from this condition to financial accounting as accruals.UseIf you mark this indicator, the condition appears in the document as a statistical

• Exclusion – Indicates whether the system automatically excludes proposed discounts during the pricing process. This indicator can be set in two ways:

• For a particular condition record (the field appears on the Details screen)
• For all records of a particular condition type (the field appears on the screen where the condition type is defined)

• Pricing date – The system date to determine the validity of the condition record shall be indicated by the entry at the price date. If the field is blank, the system will use the standard pricing date KOMK-PRSDT for pricing, but for taxes and rebates, the system will use the date KOMK-FBUDA.

• Rel Acc Assig – Controls how an account is assigned for conditions of this type. If we enter Indicator B, the system will include an accounting indicator in assigning an account. Information from the status record is forwarded to Controlling with the “accounting indicator” classification. The system links the status record to the underlying billing document item in order to find the accounting indicator assigned to the particular transaction.

For transactions involving an accounting variable, the KBM1 condition is set up in the standard framework.. Account assignment using an accounting indicator is often used in the Service Management system. It enables you to determine how the costs of a specific service transaction (for example, goodwill under guarantee) were incurred.

• Qty conversion – This field controls the conversion quantity during the determination of the condition basis.

Deactivated: The basic quantity of the condition shall be converted to the storage unit by means of the quantity. This means that the quantity of the condition is determined for the planned factors. This means that no change to the conversion factors is taken into account in the delivery or order. Rounding errors may occur during the conversion of quantity.

Activated: If the sales quantity unit and the condition quantity unit are the same, the quantity of the document item shall be used, i.e. the actual quantity.

Complex pricing requirements

• Different Payer (1) – This requirement is met if the sell-to-party in the sales document differs from the payer. This can be assigned to an access sequence for aid performance when the price status records are maintained at both the level of sales and/or payers.

Example – As part of the pricing program, a company sometimes defines prices on the basis of sales to or to the payer. Within their customer base, some customers have a central payer who is used to sell to many parties. Other customers are smaller where the seller and the payer are the same. Within the price access sequence, the user sets up accesses for both the seller and the payer. The first access searches for a price using the sales document. The second is looking for a price based on the sales document payer. The user assigns requirement 1 to the second access to indicate that it is only necessary to look for the payor level price if the seller differs from the payer

• Inter-company (22) – This requirement is met if the document is an intercompany billing document. This billing document is the billing of the company code to the sales org company code. This requirement should be assigned to conditions relevant to the intercompany billing document, such as PI01 and PI02.

Example – A company receives a sales order from a customer. The company code of the shipping plant differs from the company code of the sales organization, indicating the inter-company sales. In addition to the invoice to the customer, the system creates an additional invoice to indicate the payment of the company code to the sales org company code. The company’s policy is to charge the sales company’s code for a fixed amount per unit of material for the transaction. In the pricing procedure, the user configures the condition type PI01 to maintain fixed amounts and assigns the requirement ’22’ so that it can only be accessed when an inter-company invoice is generated. If the amount has to be in

• Free goods pricing (55) – This requirement is met if the item category for the item has the price indicator ‘B’ – Free goods prices. The 100 percent discount is automatically applied to the system using the R100 condition in the pricing procedure. Requirement ’55’ should be assigned to this type of condition in the pricing procedure so that it applies only to free items.

Example – A company has a free goods agreement with its customers. For every 10 cases of Product A that the customer purchases, the customer receives 2 cases of Product B free of charge. From a price point of view, the user wants to track revenue and sales deductions for free items. To do this, the user flags the category of free goods item with the price indicator ‘B.’ In addition, the user adds the condition type R100 to the pricing procedure at the point at which the discount of 100% is to be applied. The user also assigns the condition ’55’ to the price procedure in order to apply for free goods items.

Creation of Customized requirements & Formulas

Creating Customized Requirements, Alternative Calculation Type, and Alternative Condition Base Value Routines – In addition to the Sap Requirements provided, Alternative Calculation Type and Base Value Routines, we can create our routines if the pricing requirements so required.

Pricing Enhancement

How to add new fields in the pricing field catalog

• The document and item data in SD are stored in data tables like VBAK and VBAP

• The field catalog is a structure- KOMG that consists of 2 tables KOMK and KOMP. They are communication structures used to communicate transaction data with the pricing procedure. The structure KOMG contains fields of tables KOMK and KOMP.

• If a field is not in KOMG, it means it is not in KOMK and KOMP. For that, we need to add the field in KOMK or KOMP and then write ABAP code to transfer the data in the field from the transaction tables to the communication structure.

Following are the steps:-

• Create the field in the KOMK and KOMP tables using the standard includes provided for the requirement.
• Write a code in the user exit to read the transaction data and transfer it to the KOMx structures.

If the field is from the header table, we need to add it to the included table KOMPAZ  in the table KOMK. Lastly, we need to write the ABAP code in USEREXIT_PRICING_PREPARE_TKOMP to include programs MV45AFZZ for order and RV60 AFZZ for billing

User-exits in Pricing

Price Determination: Module pool SAPLV60A, Include RV60AFZZ:

• USEREXIT_PRICING_PREPARE_TKOMK (To copy additional fields for pricing in the TKOMK communication structure (header fields), which have not been provided in the standard SAP system)

• USEREXIT_PRICING_PREPARE_TKOMP (To copy additional fields for pricing in the TKOMP communication structure (item fields))

• USEREXIT_PRICING_PREPARE_TKOMK (Hdr Strctr for Pricing) -FV45PF0P_PREISFINDUNG_VORBEREI

• USEREXIT_PRICING_PREPARE_TKOMP (Itm Strctr for Pricing) -FV45PF0P_PREISFINDUNG_VORBEREI

• Module pool SAPMV61A, Include MV61AFZA: USEREXIT_FIELD_MODIFICATION, USEREXIT_PRICING_CHECK & USEREXIT_CHANGE_PRICING_RULE

• Module pool SAPMV61A, Include MV61AFZB.

• Module pool SAPLV61A, Include RV61AFZA: USEREXIT_PRICING_RULE & USEREXIT_PRICING_COPY

• Module pool SAPLV61A, Include RV61AFZB.

Pricing OSS Note

• SAP Note 388112: Change of pricing procedures in the production system
• SAP Note 834174 : How are ‘value-related’ condition bases determined?
• SAP Note 1007110 : How is the KWERT defined in the subtotal?
• SAP Note 791944 : How is the KBETR determined by the subtotal?
• SAP Note 363212 : Analysis of prices’ mode of operation
• SAP Note 859876 : The condition is missing: VE 108 or VE 008
• SAP Note 156230 : Requirements: What is permitted, what is not?
• SAP Note 24832 : Pricing rules / TVCPF

Now follow these tutorial links to learn more about Available to Promise

• Available to Promise (ATP) in SAP
• Replenishment lead time (RLT)
• SAP S4HANA
• SD integration
• SAP intercompany
• Third-party sales
• Route determination