Fundamentals of SAP SD Pricing

Consider this as an extract of a grocery bill. You have purchased some items from the Produce section and some from the stationery section. Your Produce sub-total is 18.00 and your stationery sub-total is 10.00. You have been taxed 10% and your total comes to 27.00 as shown in the picture above.

Let’s just explore on how the pricing is calculated on line item No. 10 – Milk. However, they might not be shown on the bill but are internal to the company selling the product. Let’s explore how a potential bill could be created. As you can see from the picture below, there is a Base Price from the price list – 5.00 . And since the bill is for a retail customer , there is a retail discount of 1.00. So the sub-total for the line item 10 is 4.00.

Condition Type :

The types of calculation ( whether its a price, discount or a tax calculation, and in price – if its a retail price or a wholesale price or a variant price etc ) are called condition type. Normally, condition types of a particular kind are not cumulative – Meaning if there are more than 1 Pricing condition type, they don’t add up – instead the last pricing condition type is taken by the system. There are some exceptions to this however. For example when pricing a car, its the sum of the different pricing condition types that gives you the Price. They are called variant condition types.

Requirement

A requirement is a piece of code that calculates if a particular condition type should be evaluated or not. This is not necessarily the only way to check if. However, since this involves hard-coding the logic in the system, this functionality should be used sparingly.

For example, the following piece of code says, “If the item is not relevant for pricing – do not price it”. Functional consultants should be aware of the final result SY-SUBRC. SUBRC stands for SUB Routine Return Code. Typically in SAP, a return code of 0 signifies a success. Otherwise its a failure.

* Pricing is turned on in item category configuration (TVAP)

form kobed_002.

sy-subrc = 4.

if komp-kposn ne 0.

check: komp-prsfd ca ‘BX’.

check: komp-kznep = space.

endif.

sy-subrc = 0.

endform.

* Prestep

form kobev_002.

sy-subrc = 0.

endform.

Similarly, the following picture shows a simple requirement. There are 2 types of discount condition types – Retail and Wholesale. If the customer is retail, then apply that discount. If the customer is wholesale, then apply the other discount. So the actual total depends on who the Order’s customer is. The same can be achieved using many different ways, but this is sure one hard-coded way to do it.

Sub-Total

A sub-total as the name implies holds temporary totals before the final price is calculated. As shown in the picture below, the Gross price is a sub-total that results from the base price. The Net Price is a sub-total that is arrived at subtracting the Discount percentage off of the Gross Price. There are many additional steps that might be required to arrive at the final price. For example, if the item is taxable, should the tax be applied on the Gross Price or the Net Price..? That actually depends on the business scenario. However, the Sub-totals allow for easily identifying and computing values for further use.

Alternative Calculation Type

The value 5.00 for the Base Price ( shown in the picture above ) is derived based on condition records which we will see much further in the discussion. However, if the condition type should NOT be calculated based on a condition record, but should be calculated based on an external or internal logic, then an alternative calculation routine should be used. Each alternative calculation routine is a 3 digit number between 1 and 999 that contains a piece of code that does some calculation either internally or externally and returns a value. That value will be used to calculate the condition type as opposed to a condition record. A simple example for the same is US Taxes. Taxes in the US and Canada are based on Jurisdiction code. There are around 50000+ jurisdiction codes in the US alone ( Based on all possible variations of City, County, State and District ). And they change continuously. So it is not practical for companies to keep track of the changes in tax rates. There are external tax companies ( Called Tax Vendors ) that only does this. So it is wiser for companies to just call an external tax vendor using a remote function call, get the tax rate as relevant for the corresponding jurisdiction code and return that value to the pricing procedure.

Account Key

When an invoice is created, the finance departments wants the corresponding Sales, expenses, tax accounts etc to be updated on the fly. The account key in the pricing procedure ( with the help of Account Determination ) helps in identifying which G/L account this should the amount flow into. A simple example could be

Statistical

This is a flag ( A Check mark ) that is used to signify if the pricing condition type is being used in the calculation or not. For example, the actual cost of the material ( not the price but the cost price ) is available in all pricing procedures, since this is used by Controlling ( CO ) to evaluate profitability. However, the value should not be relevant when pricing to the customer. So, if you need informational condition types for further analysis set them up in the pricing procedure as statistical.

Print Flag

The print flag is another check mar that is used to tell SAP if the particular pricing condition type should be printed on the final bill or not. As discussed in the previous example, the cost condition type should not be printed on the invoice. With the advent of advanced technologies like SmartForms, Adobe Forms etc, this flag has almost no use ( Since what is printed and what is not is decided mostly by these programs ).