Chapter 5: Pricing and Tax Determination

One of the most critical areas in Sales and Distribution is pricing, in other words, determining the price at which a sales transaction takes place. In order to arrive at the final price, there can be several elements such as a base price, discounts, and taxes, linked together in a pricing schema. In this chapter, we will study the set up of a pricing procedure.

In addition, most sales are subjected to tax, as per the law of the land. The tax structure varies from region to region. Setting up and calculating tax is therefore important from both a legal and a sales perspective. Hence, in this chapter, we will focus on basic concepts of tax determination.

Pricing

A pricing procedure is a schema to arrive at the final price of a product or a service. For example, if a price of a product is determined as (base price – discounts + freight + tax), you would arrange these conditions in a sequence and specify the rules for arriving at a total. Each of these pricing elements in a pricing procedure is called a condition type. The conditions can either be at header level (applicable to the entire document) or at an item level. You can either enter the values for each condition type manually or determine them automatically using a condition technique. We discussed and showed how to apply this condition technique in Chapter 4, “Partner, Text, and Output Determination.” To reiterate, when using this technique, you can assign an access sequence to each condition type. Following the sequence, the system looks up pricing records maintained in condition tables in a specific order. The condition record is then picked up from the tables and used in the pricing schema. Figure 5-1 gives you an overview of a pricing procedure and its constituents. You can refer to this figure as you go through this chapter.

To configure pricing, follow these major steps:

Step 1: Define the condition tables First, you define the condition tables, with combinations of key fields. You then set up the pricing condition records for these key combinations.

Step 2: Define the access sequences SAP uses access sequences as the search criteria to find the valid condition record during the pricing determination run. In this step, you define this access sequence and arrange the condition tables defined in step 1 in the sequence in which you want SAP to access the condition records. As in any condition technique, the rule of thumb is to arrange the tables in order from most specific to most generic.

Step 3: Set up the condition types Here you set up condition types and assign the access sequence created in step 2 to them. Each condition type represents an element in the schema. You set up prices, discounts, freight conditions, tax, and costs as individual condition types.

Step 4: Define the pricing procedure The pricing procedure is the schema to arrive at the final price. You link together the individual condition types defined in step 3 and maintain the relation between them. You can also attach complex formulae that may be required to compute any value.

Step 5: Assign the pricing procedure You then determine the pricing procedure for each sales transaction. You can control which procedure is to be used for a specific customer and sales document type. In this step, you specify these rules for determining the pricing procedure.

Deciding the Scope of Customization

As with any major customization activity, you should identify the scope of the customization based on your business blueprint. The following questions will help you understand the scope of work:

• How does your pricing schema look? It is often very useful to write down the complete schema in a spreadsheet. This gives you a picture of the various pricing elements and the formulae needed to arrive at a final price.
• Does the pricing schema vary by sales area? Do you have different document types that require a separate pricing schema?
• What are the pricing elements you require? Can you group them together under Prices, Discounts, Freight, Tax, and so on?
• What is the key to determining the value for each condition? Is the price of a material customer-specific? Or is it constant for all the customers in your sales area? Do you require multiple accesses to get the appropriate price? List all criteria for the price determination.
• What are the financial accounts to be updated? Where should you post the price, discount, and so on? What are the criteria for account determination?
• Are there any reporting requirements that need you to capture pricing subtotals as you go along computing the final price? You can capture gross price, net price, total discount, and so on, as intermediate subtotals and use the values in reports or in documents for customers.

Based on this list of answers, you should check the SAP standard pricing procedures in the system. Check whether those procedures meet your requirements or whether any customization is required.

For a better understanding of these concepts, let’s go through the customization scope for Galaxy Musical Instruments.

Configure Pricing

We will follow the step-by-step procedure discussed earlier to build a pricing procedure, and we’ll elaborate on each step of the procedure in the following sections.

Step 1: Define the Condition Tables

The first step is to define condition tables. To set up a condition table, you need to refer to a field catalog. From this list, you can pick up the fields that you require in your condition table.

Conditions: Allowed Fields

Use the menu path IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Pricing ⇒ Pricing Control ⇒ Define Condition Tables ⇒ Conditions: Allowed Fields (OV24).Using this transaction, you can check the fields available in the standard field catalog (Figure 5-2). If this list does not meet your requirements, you can access a larger list of fields in the catalog by using the drop-down list (function key F4). Figure 5-3 shows the larger list.

For Galaxy Musical Instruments, we need a table for a combination of Sales Organization and Customer Group. We first check in the field catalog and verify that these fields are available.

Create Condition Table

Follow the menu path IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Pricing ⇒ Pricing Control ⇒ Define Condition Tables ⇒ Create Condition Tables (V/03).

This option allows you to set up a condition table. The steps are similar to the condition table set up and discussed in the “Output Determination” section of Chapter 4, “Partner, Text and Output Determination.” You select the fields and generate a new table.

As shown in Figure 5-4, the selected fields appear in the list on the left. These fields will form the key to the new table. You can also choose to add a validity period and a release status to control the pricing records contained in the table. This option was not available in the condition technique discussed in “Output Determination.”

If you select the With Validity Period option, the pricing records get a Valid From date and a Valid To date. When you maintain the price, you can specify the exact duration for which the record should be active. Once the expiry date is reached, the record becomes obsolete. This feature enables you to maintain an archive record of all the previous prices over a period of time. You can also set up new pricing records in advance and release them using the Valid From date.

If you select the With Release Status option, you can control the pricing record further by adding a status field. Using this feature, you can flag a record as active or not yet released, depending on your requirements.

You will see how to use these fields (using transaction VK11) later in the chapter in the “Maintaining Price Records” section.

After you have selected the required fields, save and generate the new condition table. Figure 5-5 shows the generation log screen.

Step 2: Define the Access Sequences

To define an access sequence for pricing determination, the menu is as follows: IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Pricing ⇒ Pricing Control ⇒ Define Access Sequence. From the Select Activity menu, choose Maintain Access Sequence. The transaction code is V/07.

From the Change View: Access Sequences: Overview screen, you can create a new access sequence by clicking the New Entry button and adding the condition tables in the required sequence (Figure 5-6). Please refer to the discussion on the exact steps in Chapter 4.

In Figure 5-6, you can see the Exclusive indicator at the access steps. If the system finds a record at any step, it stops any further searching. If there are more records at subsequent levels, they will be ignored, and an exclusive record will be used to calculate the price.

We’ll use an example to explain this concept further. If the access sequence ZGM1 finds a record at the first step (table 7), it stops any further searching and applies this rate. However, it is possible that a certain customer could have two or more conditions applicable to it. For example, a customer could have a special discount specific to it (using table 7) and another discount for the Customer group of which it is a part (table 605). If you turn off the Exclusive indicator, the system will continue the search and pick up both the records. It is advisable to have the Exclusive indicator on for better system performance and to avoid reading multiple records.

The Requirement field allows you to add a custom routine for the access step. You can add a prerequisite condition that has to be fulfilled before a specific access is carried out. An example is the standard access sequence MWST, used in the determination of tax conditions (Figure 5-7). The access sequence looks up tables for domestic and international tax rates. In this example, MWST has requirement routine 8 at the first step. This code checks whether the destination is an international address. If this prerequisite requirement is fulfilled, the system carries out the search for a tax record. Otherwise, this step is skipped, and the next access (for domestic taxes) is carried out. Requirement routine 7 checks for domestic destination. This way, you can improve the efficiency of the access sequence by checking prerequisites.

We will discuss how to set up a pricing requirement routine later in this chapter.

Step 3: Set Up the Condition Types

Pricing conditions are the basic pricing elements used in the pricing schema. Therefore, we’ll start by showing how to set up a condition type to meet your requirements.

Define Condition Types

To define condition types, follow the path IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Pricing ⇒ Pricing Control ⇒ Define Condition Types ⇒ Maintain Condition Types (V/06).

On the overview screen, you can find a list of condition types that already are in the system. To define a new condition type, you can use the New Entries option or copy one from a reference condition type. You can specify a four-character alphanumeric name for the condition type. The following are the critical settings on the Details screen, as shown in Figure 5-8.

Access Sequence If the condition type is to be linked to an access sequence, you can specify it in this field.

Records For Access This link displays all the pricing records that have been maintained in the various tables listed in the access sequence.

Control Data 1 Tab: These fields are on the Control Data 1 tab:

Condition Class This is the categorization of the condition that is being set up. It could be a price, a discount, a tax, and so on. It is also used to decide which condition types should be redetermined when copying from one document to another.

Calculation Type This guides the system in calculating the value of a condition. For example, you can specify whether the value of a condition should be considered as a fixed value or a percentage based on quantity, volume, or other attributes.

Condition Category This further classifies the condition into categories such as freight-related charges, taxes, and so on. This field also plays a key role in controlling which price conditions are copied from one sales document to another and which conditions need to be redetermined. The “Update Pricing” section in this chapter will explain this concept in detail.

Rounding Rule This controls how SAP should apply the rounding rules to the condition calculations. Choose A for rounding up or B for rounding down, and keep this field as blank for commercial rounding.

Plus/Minus This controls whether the resultant condition value will have a negative or positive impact on the value. Choose A to have positive impact, or choose X to have a negative impact; leave the field blank if you want the condition to leave both options open. For instance, a discount condition type would have a negative sign, whereas a surcharge condition type would have a positive sign.

Structure Condition The field (Struc.Cond) controls the condition cumulation and duplication in case of structured materials such as a bill of materials and configurable materials. Choose A if you want to duplicate the condition to all the lower-level items in the structure, or choose B if you want the condition to contain the cumulative value from all the lower-level items. We will discuss this later in the chapter when we talk about cumulating conditions.

Below the Control Data 1 tab is the Group Condition tab. The following settings appear in Figure 5-9.

Group Condition: This field should be selected only if you want the system to calculate a condition value on the basis of more than one item in the order, grouped together by a certain criteria (such as a material group). You will study the application of this field later in the chapter, when we talk about condition types that use group condition functionality.

Changes Which Can Be Made: This section governs whether manual changes to the condition value should be permitted.

Manual Entries This setting decides which entry gets precedence. If, for example, the system determines a value of $100 for a price condition and you want to override it manually and make it $120, you can control it by specifying which value should take precedence. You can also prevent manual intervention altogether. The other fields in this section control other aspects of permitting changes.

Master Data: This section allows you to control default values such as validity dates when creating pricing master data (condition records).

Valid From, Valid To If a user does not specify any validity period, you can default these settings to Valid From Today and Valid To December 31, 9999.

Pricing Procedure This field (PricingProc in Figure 5-9) is used to specify a pricing procedure for determining condition supplements. We will discuss it later in the chapter.

Reference Condition Type The field RefCondType is useful when you have a reference condition that is similar to the one you are setting up. If a pricing record has been set up for the reference condition, the same will be copied over. This avoids multiple records to be maintained.

Reference Application Here you can specify a reference condition type from an application other than sales.

Delete From Database If a user wants to delete a condition record, you may want to warn him before deleting it from database. It is always a safe practice not to delete the records but to flag them as deleted. Thus, you still have traceability. You can specify this in the Delete Fr. DB field.

Next on-screen are the Scales and Control Data 2 tabs, as shown in Figure 5-10.

Scales: Sometimes you have scales in pricing, also known as price slabs. For example, from 1 to 49 pieces, the price is $50 apiece. From 50 to 99 pieces, it is $45 apiece. You manage this type of requirement using scales. We will show how to use this functionality later in this chapter. For now, we’ll review some key settings on the Scales tab:

Scale Basis This setting controls how the system interprets the scales. It can be a quantity-based scale (as in the previous example), or it can be based on weight, volume, distance, and so on.

Check Value Here you can specify whether the scales have been entered in an ascending or a descending order.

Scale Type You can specify a Scale Type such as a from-scale or a to-scale. This field is left blank to indicate that you can specify it in the condition record itself.

Scale Formula If you have a complex formula to arrive at the scale base value, you can attach the formula routine here.

Control Data 2: These fields are on the Control Data 2 tab:

Currency Conv If the currency of a condition record (say EUR) varies from the document currency (say USD), the system applies the exchange rate (EUR to USD) to bring it to the document currency. The condition value is multiplied by the quantity to arrive at an amount. In this computation, you can control whether the currency conversion is to be done before or after the multiplication.

Accruals This flag marks the value determined for this condition as statistical and posts it to financial accounting as accruals.

Pricing Date This controls which date is used to check the condition record’s validity at the time of pricing. By leaving this field blank, the system uses the standard pricing date. For tax conditions, it is the date on which the service was rendered.

Text Determination This controls the text procedure and text ID that is to be associated with this condition type. Please refer to Chapter 4 for details.

Define Upper/Lower Limits for Conditions

The path here is IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Pricing ⇒ Pricing Control ⇒ Define Condition Types ⇒ Maintain Lower/Higher Limits For Condition Values (OVB2).

With this setting, you can specify limits on the value of a pricing condition (Figure 5-11). As you have seen earlier in the settings for condition types, you can allow manual changes to be made to the value of the condition. By limiting the value range, you can control the manual changes and help avoid human errors. At the time of the creation of condition records or in the sales order, the user will get an error message if she enters a value beyond the limits for the condition (Figure 5-12).

Check Settings for Condition Types

Follow this path: IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Pricing ⇒ Pricing Control ⇒ Define Condition Types ⇒ Check Settings For Condition Types (VCHECKT685A).

It is advisable to run this report for any new condition types that you may have defined. It does not check all aspects of customization, but it does some critical checks on the use of scale types for group conditions, and so on.

Step 4: Define the Pricing Procedure

The pricing procedure is a sequential arrangement of a group of condition types. When you define a pricing procedure, you arrange various condition types in the sequence in which SAP should access them. Then you make settings that control the following:

• The way the values are calculated in the schema
• When the condition type should be accessed for reading the underlying price value
• Whether a condition type should be mandatory, statistical, or manually maintained during sales order processing
• Whether a pricing condition type is relevant for posting to accounting as revenue or as accruals

To set up a pricing procedure, follow the path IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Pricing ⇒ Pricing Control ⇒ Define And Assign Pricing Procedures ⇒ Maintain Pricing Procedures (V/08).

Standard SAP provides a variety of pricing procedures. RVAA01 is a versatile standard procedure. SAP also provides some country-specific pricing procedures such as RVAAUS (Standard – USA w/out Jurisdiction Code) and RVAJUS (Standard – US w. Jurisdiction).

You can create your new pricing procedure by copying it from the existing pricing procedure that is the closest match to your requirements. You can also define a pricing procedure from scratch. We’ll now show the pricing procedure customizing elements in detail, moving from left to right on the screen (shown in Figure 5-13).

Since the steps in the pricing procedure cannot fit in a single screen, you have to scroll down to see the other steps, shown in Figure 5-14.

Step This represents the sequence in which the condition types will be accessed within the pricing procedure. Here you can assign first condition type at step 10, the second at step 20, and so on. It is advisable to use a spacing of 10 between steps in case you have to change the pricing procedure at a later date and then insert steps in between 10 and 20.

Counter This represents a substep.

Condition Type You must enter the condition type at each step. The system will read and compute each condition type in the sequence specified by the step number.

Description If you have entered a condition type, then the description of the condition type automatically appears here. If you are defining a step for the subtotal, you can enter a meaningful description here (such as Gross Value).

From, To These represent the basis of calculation for a step. For example, if the operation in step 30 is to be performed on the value appearing in line 20, then you specify From as 20. The From and To fields are also used in defining subtotals. Thus, if you want to compute the subtotal of all discounts, or all the tax conditions together, you can define a new step and enter the description of the subtotal in the Description column. For example, if you insert a subtotal at step 300 called Net Price and then specify that it will be the net of all values from step 101 to 299, the system will compute the subtotal, and it will appear at step 300 in the pricing procedure in the sales document.

Manual When this box is selected, the condition value for the condition type is either provided manually by the user or is provided by a process external to SD such as costing.

Required Selecting this box makes the condition mandatory. If SAP is not able to find a valid record for a condition type with the Req. check box selected, it issues an error message to the user that pricing is incomplete.

Statistical Selecting this box makes the condition statistical. It will be calculated just like any normal condition, but the value will not impact or roll up to the total.

Print This controls the printing of a condition line on printed outputs such as order confirmations and invoices. You can choose X to have condition lines printed at the item level, choose S to have condition lines printed at the total level, or choose to leave this field blank to skip the condition lines value being available for printing.

Subtotal We have already discussed using subtotals in a pricing procedure. The Subtotal field is used to indicate the fields where the subtotal value is to be parked. Use this to store the condition amounts, condition rates, and subtotals values into Subtotal fields for use in further user-defined calculations or for use in reports. You can store the value into the fields KZWI1 to KZWI6 of structure KOMP or to internal auxiliary variables XWORKD to XWORKM. By default, SAP adds up the condition amounts, which are transferred to the same Subtotal field.

Requirement This is a provision that attaches a routine before the value of a condition type is computed. It is like a prerequisite that has to be satisfied before you can proceed. If the requirement fails, the condition is not accessed. For example, requirement 2 in steps 11 through 110 tells SAP to access corresponding condition types only when the related sales line item in the sales document is relevant for pricing. If the sales-order line happens to be a free item, such as item category TANN, then SAP will not access PR00 for such line items.

Alternative Calculation Type Use this field (shown in Figure 5-14 as CalType) when you want to apply your own calculation formula as an alternative to the standard condition technique. You can create a customer-specific formula as an alternate calculation type and assign it to the condition type in the pricing procedure.

Alternative Formula For Calculation Of Base Value Use this field (shown in Figure 5-14 as BasType) when you want to change the calculation base value at the step. For example, for a condition type to compute a cash discount, the discount is to be applied on the net value (the amount less any taxes). A routine 2 is readily available to indicate this base value. Similarly, you can define your own custom routine, if required.

Accounting Key Use this field (shown as AccK in Figure 5-14) for posting the condition type value to a revenue account in FI.

Accruals Use the Accruals key (shown as Accru) to post the condition type value to an accrual or provision account in FI.

As you read the case study on maintaining the pricing procedure (“Galaxy Musical Instruments Configuration Analysis: Maintain Pricing Procedure”), please refer to Figures 5-13 and 5-14, and follow some of the key steps that we have defined.

Figure 5-15gives you an idea of what this pricing procedure looks like in action. Imagine you are selling an acoustic guitar. The system computes the price for the product as $3,000. The customer qualifies for two discounts because of different promotional schemes running in parallel. Hence, it takes off $435 from the total. The system then adds freight, based on the total weight, to arrive at a total price of $2,665 for the customer.

In a sales document, you can always study the pricing analysis log, which tells you how the system computed the total price. You can then drill down to study which condition types were accessed and what values were determined. Figure 5-16 shows you such a log for the acoustic guitar transaction just mentioned. You can drill down to each condition type and verify how the value was determined.

For example, if you click on condition type ZGM1, you will see further details as shown in Figure 5-17. The log tells you that discount ZGM1 was determined on the basis of access 30. The earlier accesses did not find any records. If you want to find the details of access 30, simply click it, and the details of the exact access appear on the right (Figure 5-18). The log reveals that the Sales Org (9090) + Customer Group (G1) was the key used and the value was 5 percent.

Finally, we captured the subtotals for this sales transaction to the database tables as subtotal fields and costs, as shown in Figure 5-19.

This completes the setup of a pricing procedure. At this stage, you may want to go back to Figure 5-1 to review the concepts discussed so far.

The pricing procedure is now ready for assignment!

Step 5: Assign the Pricing Procedure

The last step in the pricing setup is to define the determination rule to govern which pricing procedure will be used. The system determines the pricing procedure based on sales area, sales document type, and customer master record. You use the fields Customer Pricing Procedure and Document Pricing Procedure to control the determination.

Define the Document Pricing Procedure

Document Pricing Procedure (DoPP) is a one-character field that can be alphabetical or numeric. It serves as the link between a document and pricing. The menu path is as follows: IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Pricing ⇒ Pricing Control ⇒ Define And Assign Pricing Procedures ⇒ Define Document Pricing Procedure (OVKI).

You can use the standard options (Figure 5-20) or create a custom entry.

Assign the Document Pricing Procedure to Various Documents

Once defined, the DoPP has to be assigned to sales document types and billing document types. This allows you to have different pricing procedures assigned to different sales documents. For example, an inquiry or quotation may have a different pricing procedure than a regular sales order for the same customer.

The menu path is as follows: IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Pricing ⇒ Pricing Control ⇒ Define And Assign Pricing Procedures ⇒ Assign Document Pricing Procedure To Sales Document Types (OVKJ).

Figure 5-21 shows the assignment screen.

To assign a pricing procedure to billing documents, use the path IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Pricing ⇒ Pricing Control ⇒ Define And Assign Pricing Procedures ⇒ Assign Document Pricing Procedure To Billing Document Types (OVTP).

Define the Customer Pricing Procedure

The Customer Pricing Procedure (CuPP) field specifies which pricing procedure should be determined for a customer. It’s a one-character field with a description that can be numeric or alphabetical. You can define a CuPP using transaction code OVKP or by following the menu path IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Pricing ⇒ Pricing Control ⇒ Define And Assign Pricing Procedures ⇒ Define Customer Pricing Procedure.

Figure 5-22 shows the customer pricing procedure screen. Once you’ve defined the customer pricing procedure, you assign this CuPP value to the respective customer master records. This field appears in the Sales view of the customer master. (Refer to the discussion on the customer master in Chapter 3, “Master Data in SD.”)

Define the Pricing Procedure Determination

The last step is to link all the pieces together and define the determination. The transaction code is OVKK, and the menu path is IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Pricing ⇒ Pricing Control ⇒ Define And Assign Pricing Procedures ⇒ Define Pricing Procedure Determination.

As shown in Figure 5-23, you can set up a pricing procedure to be a combination of Sales Area + Customer Pricing Procedure + Document Pricing Procedure.

Figure 5-23: Pricing procedure determination

Maintaining Price Records

After configuring the pricing procedure, you have to maintain the master data for the pricing condition records. The system will read the actual values of the pricing conditions from these master data records.

Follow this path: SAP Menu ⇒ Logistics ⇒ Sales And Distribution ⇒ Master Data ⇒ Conditions ⇒ Select Using Condition Type ⇒ Create (VK11).

When you specify the condition type, you will get a list of condition tables to choose from. This list depends on the access sequence that you have used for the condition type. Choose the table and proceed.

Each condition record contains its condition value and validity period. In addition to this, you can maintain other additional information in the record (Figure 5-24).

In the pricing scenarios we explain later in the chapter, we will discuss some of the other information that can be updated using this transaction code.

Also note that you can check the change log for any condition record from the transaction to change the condition record (VK12) or display the condition record (VK13) using the menu path Environment ⇒ Changes.

Other Key Settings in Pricing

In this section, we will discuss some of the other settings that influence how a pricing procedure works. We will cover some of the master data fields that are useful in the determination of pricing records. We’ll also discuss the functionality of condition exclusion and how to set up pricing routines.

Maintain Price-Relevant Master Data Fields

Based on the requirements of your organization, you can use certain fields in the customer master and material master to determine the correct prices.

Define Price List Categories for Customers

Use the menu path IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Pricing ⇒ Maintain Price-Relevant Master Data Fields ⇒ Define Price List Categories For Customers. You can set up a list of categories for the customers and then control the price determined in each price list category. To do this, create a two-character code and a brief description (Figure 5-25). In the customer master, this field appears in the Sales view. Choose the appropriate price list category from the drop-down menu. You can freely use this field to point to certain pricing condition records by using it as a key field in a condition table.

Define a Pricing Group for Customers

Follow this menu path: IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Pricing ⇒ Maintain Price-Relevant Master Data Fields ⇒ Define Pricing Groups For Customers.

If you have to offer a special price to customers who meet certain grouping criteria, consider using a pricing group. It is another two-character field that can be used to determine prices.

Define Material Groups

Follow this menu path: IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Pricing ⇒ Maintain Price-Relevant Master Data Fields ⇒ Define Material Groups.

Here you can define a two-character alphanumeric code and a brief description. You can use this grouping term in the material master and then determine the pricing condition on its basis.

This field appears in the material master in the Sales: Sales Org 2 view.

Condition Exclusion

In certain transactions, the system may determine records for more than one condition type in the pricing procedure. You saw this in Figure 5-15, where two discount condition types (HI01 and ZGM1) were applicable to the customer. As a result, the customer enjoyed a bigger discount. If you do not want this to happen, you can set up conditions or a group of conditions to be mutually exclusive. You can set up rules so that the system chooses one of them and ignores the other. This is called condition exclusion.

The following are the steps to set up a condition exclusion.

Define a Condition Exclusion Group

Follow this menu path: IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Pricing ⇒ Condition Exclusion ⇒ Condition Exclusion For A Group Of Conditions ⇒ Define Condition Exclusion Groups.

Condition exclusion groups house the condition types that are to be used in condition exclusion. To set up a group, click New Entries. Enter a four-character alphanumeric name and a meaningful description (Figure 5-26).

Assign a Condition Type to an Exclusion Group

In the next step, you assign condition types that are to be compared to the condition exclusion groups.

Follow this path: IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Pricing ⇒ Condition Exclusion ⇒ Condition Exclusion For A Group Of Conditions ⇒ Assign Condition Types To Exclusion Groups.

Click New Entries. In each row, enter the condition exclusion group and the condition that you want to include in that group. If more than one condition type is to be included in the same exclusion group, set up separate records for each (Figure 5-27). When you have finished, you will have exclusion groups each containing condition types to be compared.

Maintain a Condition Exclusion for the Pricing Procedures

Before you can use a condition exclusion, you have to mark it relevant to your pricing procedure. Thus, if the same condition type (for example PR00) is used in several pricing procedures, you can still use it in a condition exclusion in a certain procedure without disturbing the others.

Use this menu path: IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Pricing ⇒ Condition Exclusion ⇒ Condition Exclusion For A Group Of Conditions ⇒ Maintain Condition Exclusion For Pricing Procedures.

From the list of pricing procedures, select the one to be activated, and click the Exclusion option in the left window. You can now set up the condition exclusion procedure in the right window (Figure 5-28).

At each step, you can specify the condition exclusion groups to be compared and the rule for comparison. In the Condition Exclusion Procedure (CPr) field, choose from the list of rules offered in Figure 5-29. The options are as follows.

Choose favorable condition between condition types (options A and L) Within a group, select the most favorable condition type within the group. Choose option A if you need the best value or option L for the least value. (If a group has two condition types, PR00 and ZPR0 and if PR00 has value $100, and ZPR0 has $200, you have to choose the most favorable. If the rule is A, ZPR0 will be retained. If you opt for L, PR00 will be retained.)

Choose favorable condition within the condition type (options B and E) Select the most favorable (specify either the best with option B or the least with option E) condition record for a condition type, when more than one record has been determined. (If PR00 has two records found, choose the better of the two.) The access sequence should have its Exclusion indicator turned off so that it keeps on reading all records.

Choose favorable condition between two exclusion groups (options C and F) Compare and select the more favorable value between two condition exclusion groups. (Add group A and group B, compare the totals, and choose the more favorable.) Choose option C if you want the best value or option F for the least value.

Exclusive (D) If any one condition type from a group A has been selected, ignore all the condition types from group B.

Now, if you carry out the same transaction of selling an acoustic guitar, you will see a different price (Figure 5-30) because HI01, with a 10% discount, has been chosen over ZGM1, which offered 5%. Both condition types are still displayed in the pricing procedure, but only one is applied.

Pricing Requirements and Formulae

During the discussion of setting up a pricing procedure, we came across certain types of routines (or program codes) that are attached to the procedure at various stages. You will also come across other routines used in other areas of Sales and Distribution.

You can check and configure these routines centrally using the menu path IMG ⇒ Sales And Distribution ⇒ System Modifications ⇒ Routines ⇒ Define Formulas For Pricing (VOFM).

The top-level menu will have the following:

Requirements We have covered the use of requirements in pricing. Similarly, there are requirement routines in other areas such as output determination, material determination, and so on. The setting basically checks whether certain prerequisites are met before a function can be performed.

Formula This setting is used in pricing to define how to do a calculation as per a custom formula. The alternative condition base value and alternative condition base type are also types of formulae.

Copying Requirements This routine checks certain prerequisites before copying data.

In subsequent chapters—specifically, Chapter 7, “Sales,” as well as Chapter 8, “Shipping and Transportation,” and Chapter 9, “Billing”—we will cover how data is transferred between orders and deliveries and billing documents.

Data Transfer During copying, the actual data transferred between documents can be controlled by data transfer routines.

Each menu has further classification, based on usage in various functionalities such as pricing, output, account determination, and so on. For example, if you choose Requirements ⇒ Pricing, you will see a list of routine numbers used in pricing, along with brief description (Figure 5-31). Select a routine you want to study. The Source Text button on the top will take you to the code in the routine. The Documentation option will give you some detailed documentation on the content and applicability of the routine.

To define a custom routine, you can copy data from a standard routine and make the requisite changes. The number range for custom routines is from 601 to 999. It is a recommended best practice to document the number of the reference routine from which you cloned your custom routine.

Pricing Scenarios and Notes

So far, you have seen how to configure a simple pricing procedure. You have also seen the various fields and settings that you can control. In real-world situations, pricing scenarios can be varied and complex. We’ll discuss some of these scenarios and business requirements here. We will also cover how you can implement the various concepts and settings that you have studied so far to meet these pricing scenarios.

Use of Header Conditions and Group Conditions

You can enter pricing conditions at the header level (applicable to all the line items in the order) or at the item level (specific to one item).

Conditions that are applied at the header level are automatically distributed to the items. In case of a header condition with a fixed amount (calculation type B), there can be two kinds of requirements: applied to all line items equally or divided proportionately:

• If the header condition should be applied to all line items, use condition type RB00. This condition type has been specified as a header condition, allowing manual entries.
• If the header condition should be divided proportionately over the line items, use the concept of group conditions. Refer to condition type HB00. It has been flagged as a group condition (Figure 5-32). This automatically divides the amount proportionately over line items, based on the net value of each line.

Let’s look at a sample order that has three items with same unit price:

• Item 10: 20 pieces
• Item 20: 10 pieces
• Item 30: 20 pieces

Applying header condition RB00 = $100, $100 will be added to each of the three line items. Therefore, $300 will be added to the total.

Applying header condition HB00 = $100, the amount is divided proportionately as $40, $20, and $40, respectively, so that only $100 will be added to the total.

Rounding differences can occur during the distribution of absolute amounts. The system automatically evens these out by proposing the remainder to the largest item so that the value in the header is identical to the total of the values in the items.

Use of Cumulating Conditions

Some products have a complex structure in the sales order, with subitems arranged in multilevels. The pricing requirement may require computing the net value of an item and all the subitems belonging to it.

In such cases, consider the condition type KUMU. It can aggregate the net values of all subitems and add them up at the parent item level. In the definition of the cumulating condition (V/06), the StrucCond field (as shown earlier in Figure 5-8) comes into play.

Use of Condition Supplements

In some scenarios, you may want to apply a certain set of supplementary conditions (for example, discounts), whenever a certain condition (for example, a price) has been determined. In such cases, you can use condition supplements.

Suppose you want to apply discounts RB00 and RA00 every time you use the pricing condition PR00. First, when you define the condition type PR00 (in V/06), you specify the condition supplement pricing procedure PR0000 on the Master Data tab (Figure 5-9).

This pricing procedure lists the supplementary condition types (RA00, RB00) that you want to apply along with PR00.

To maintain the condition records for PR00 and the condition supplement, use VK11 (Figure 5-33). From the overview screen, select Goto ⇒ Condition Supplement to set up the condition records.

When PR00 is determined in a pricing procedure, the system will also check the supplementary pricing procedure and pick up the discounts defined there. As shown in Figure 5-34, the order has picked up all the conditions we had maintained along with PR00. The pricing analysis too explains the fact that these conditions (such as RB00) are in fact condition supplements (Figure 5-35).

Use of a Cost Condition

One of the common pricing requirements is to have the cost of the product added to the pricing procedure. This enables you to compute the profit margin on the sale.

The system provides condition type VPRS for this. It is defined by condition category G (Cost). This condition picks up the value from the valuation segment in the material master. You can control this further by opting to use condition category S (to pick up the standard cost) or T (to pick up the moving average cost).

The cost is captured in a subtotal B in the standard pricing procedure. It is passed to the database table VBAP as the cost (WAVWR). Further, you can use formula 11 to compute the profit margin by subtracting the cost (subtotal B) from the net value (subtotal 2). Refer to Figure 5-14, step 950, where you are computing the profit margin using formula 11.

In a sales order costing scenario, you can transfer the cost to the pricing procedure by using condition type EK01. If you want it at a statistical level, choose EK02. These conditions are in condition category C (Costing).

Free Goods

It’s a common business requirement to offer free goods as an incentive to customers. There can be two scenarios:

Inclusive The customer pays for only a part of the goods he has ordered. For example, the customer buys 10 music CDs for the price of 8. (In other words, if a customer buys 10, he gets 2 of them free, included in the order quantity).

Exclusive The customer orders a certain quantity and gets additional items free. For example, the customer buys 10 music CDs and gets 2 extra for free. (In other words, if a customer buys 10, she gets 2 more, hence receiving a total of 12 CDs.)

You can map either case in SAP using the free goods functionality. Both scenarios rely on the same condition technique, following the five-step approach used for pricing procedures. However, the transaction codes and menu paths are different, as shown in Table 5-1.

Table 5-1: Configuring Free Goods

Menu Path	Transaction Code	Action
IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Free Goods ⇒ Condition Technique For Free Goods ⇒ Maintain Condition Tables	V/N2	Create a condition table by selecting fields from the field catalog. Save and generate the table. (Similar to V/03 of pricing.)
IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Free Goods ⇒ Condition Technique For Free Goods ⇒ Maintain Access Sequence	V/N1	Create an access sequence by adding condition tables in the required order. Save and generate the access sequence. (Similar to V/07.)
IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Free Goods ⇒ Condition Technique For Free Goods ⇒ Maintain Condition Types	V/N4	Define a condition type. Assign an access sequence to it. (Similar to V/06.)
IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Free Goods ⇒ Condition Technique For Free Goods ⇒ Maintain Pricing Procedure	V/N5	Define a pricing procedure. Add condition types in the desired sequence. (Similar to V/08.)
IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Free Goods ⇒ Condition Technique For Free Goods ⇒ Assign Pricing Procedure	V/N6	Assign a pricing procedure for a combination of sales area, document pricing procedure, and customer pricing procedure. (Similar to OVKK.)

The transaction to create free goods condition records is VBN1. Here, you can specify whether an incentive is inclusive or exclusive. As shown in Figure 5-36, you can choose from three options. In the case of inclusive goods, you can choose option 1 (an inclusive rebate with item generation) if you want a separate line item to be generated for the free goods. The other alternative is option 3 (an inclusive rebate without item generation). Option 2 is for exclusive free goods.

Here are the standard settings you can use:

• Condition tables:
  • 010: Customer/Material
  • 017: Campaign ID/Material
• Access sequences:
  • NA00: Free Goods (SD)
• Condition types:
  • NA00: Free Goods
• Pricing procedure:
  • NA0001: Free Goods (SD)

Use of Condition Updates

Some organizations offer special prices or discounts limited to the first few orders or up to a limited quantity, weight, volume, or certain budget. Any order that comes in after this limit is reached should not qualify for the pricing condition.

To map this requirement, make sure that the condition type you are using has Condition Update marked on in the settings in V/06. In such cases, the system keeps track of all orders or billing documents that have availed of this special price. Once the limit is reached, the condition is no longer applied to subsequent documents.

When you maintain the record using VK11, you can specify the limits (Figure 5-37). Galaxy Musical Instruments has set such a limit using the special pricing condition ZGMP. In this case, the first two orders for a particular customer will get the benefit of the special price.

At any point you can check the cumulative value of orders/weight/volume sold until date. On the VK11 overview screen, select Extras ⇒ Cumulative Values.

Use of Pricing Scales

It is a common scenario to have a tiered pricing structure. To map these requirements, you can set up scales in pricing conditions. Earlier in this chapter, in our discussion of V/06, we described the fields related to scales.

Galaxy Musical Instruments has set up pricing based on scales for one of its products. For an order quantity up to four pieces, the price is $899. When five to nine pieces are ordered, the price is $850, and so on.

To maintain scales in pricing records, use VK11. On the overview screen, use the path Goto ⇒ Scales. Then you can set up the pricing scales as required. Refer to Figure 5-38 for details.

Update Pricing

During a sales process, you create delivery and billing documents with reference to sales documents. You can also create new sales documents with reference to old orders. Sometimes the billing document is created days or months after the order was originally placed. During this time, the prices may have changed. Some organizations retain the old prices unchanged, whereas others need to carry out fresh pricing to pick up the latest prices. Others may choose to retain some price condition types and redetermine others, such as tax conditions. The functionality of Update Pricing caters to different business needs.

In Chapters 7 and 9, we will use this functionality in copy controls.

The users can also update pricing during sales order processing via VA01 or VA02. They can carry out fresh pricing using the Update Prices option in the Conditions tab. Sales orders can also be mass-updated for pricing via VA05.

The following are the some of the update rules you can choose from, as shown in Figure 5-39.

A: Copy Pricing Components And Redetermine Scales The system does not determine any new condition types; it redetermines the scale prices for changed delivery quantities.

B: Carry Out New Pricing The system carries out a completely new pricing (manually entered pricing elements are not copied from the reference document). It redetermines the taxes.

C: Copy Manual Pricing Elements And Redetermine The Others The system carries out a new pricing, copies the manually entered pricing elements, and redetermines the taxes.

D: Copy Pricing Elements Unchanged The system copies the pricing elements unchanged with automatically determined or manually entered surcharges and discounts from the reference document.

G: Copy Pricing Elements Unchanged And Redetermine Taxes The system redetermines the following condition types: taxes (condition class D), rebates (condition class C), intercompany billing conditions (condition category I), invoice list conditions (condition category R), condition types with condition category L, cost conditions (condition category G), and cash discount conditions (condition category E).

H: Redetermine Freight Conditions The system redetermines the following condition types: freight conditions (condition categories B and F) and condition types with condition category L.

As you can see, the condition categories can play a key role in controlling which conditions are copied over or redetermined.

Tax Determination

Any sales transaction has to take into account the taxes applicable. The key factors that determine taxes are the location of the delivery plant, the country and region of the customer, and the material and customer tax classifications. There is a lot of variation in tax laws and schema across the world. Therefore, it is important to document the exact requirements during business blueprinting, while working with your finance team.

Tax determination, like pricing, follows the condition technique. A tax condition appears in the pricing procedure as a condition type along with an account key, just like any other condition. This account key further maintains the link between SD and FI for tax posting to a tax GL account. Once customizing is done, you assign the tax classifications to customer and material master records. You set up the tax rates in the condition tables.

When a user creates a sales document, SAP reads the following:

• Customer tax eligibility from the customer master
• Material tax relevance from the material master
• Departure country and location from the plant used in the sales document at the item level
• Destination country and location from the ship-to party record

SAP then determines the applicable tax percentage and tax code from the master records and applies this percentage to the sales document.

During billing creation, SAP reads the pricing information from the sales document and service rendered date (Post Goods Issue date) from the delivery document and redetermines the applicable tax, based on settings. During the accounting posting of this billing document, the tax code and the account key determine the GL account to which the tax posting can be made.

Setting Up the Tax Determination

Following are the steps in the configuration of tax in SAP:

Step 1: Define Tax Determination Rules

The menu path is as follows: IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Taxes ⇒ Define Tax Determination Rules (transaction OVK1).

In this setting, you assign a tax category by country. Maintain the settings only for those countries that are relevant to your business scenario. This category is the pricing condition type that will be used for taxes in your pricing procedure. Only those condition types classified as tax (in the condition class) can be used here. Some countries can have more than one tax category assigned. In this case, you can use the sequence field.

Check whether the country appears in the list. To do this, click New Entries, and enter the country code and tax category, along with the access sequence number (Figure 5-40).

Step 2: Define Regional Codes

Some countries have regional taxes. Hence, it is necessary to define all the counties or cities in a country. Use this path: IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Taxes ⇒ Define Regional Codes ⇒ Define County Codes. Specify the Country and Region entries, and then divide them into county codes as applicable (Figure 5-41).

If you need to set up taxes at a city level, you can specify Country and Region and then divide them into city codes as applicable. To do this, the path is IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Taxes ⇒ Define Regional Codes ⇒ Define City Codes.

Step 3: Assign Delivering Plants for Tax Determination

Since the delivering plant determines the source address, it is important to set up the address details.

Follow the path IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Taxes ⇒ Assign Delivering Plants For Tax Determination (OX10).

Double-click the chosen plant. Specify the complete address, including the country, region, county code, city code, and jurisdiction code, as required. We covered this when we defined plants in Chapter 2, “Enterprise Structure.”

Step 4: Master Data Classification

You next have to set up customers and materials so that the system determines the appropriate tax in a transaction. You can group your customers and materials into groups and control the tax by each group. Follow the path IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Taxes ⇒ Define Tax Relevancy Of Master Records ⇒ Customer Taxes (OVK3).

For material taxes, follow IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Taxes ⇒ Define Tax Relevancy Of Master Records ⇒ Material Taxes (OVK4).

In either case, specify the tax condition type (tax category), and define the tax classification codes (Figures 5-42 and 5-43). For example, materials in your product range could have no tax, half tax, or full tax. In this case, you would set up three material tax-classification codes and maintain them in the material master.

When you maintain the customer master data, you enter the tax classification on the Billing Document tab in the Sales Area Data section. As shown in Figure 5-44, for customer 10028, we have entered tax classification 1 (taxable). Note that the tax category (UTXJ) that appears on this screen is controlled by the tax determination rule maintained for the country (U.S.).

In the material master (using MM01 or MM02), you enter the tax classification on the Sales: Sales Org 1 tab. As shown in Figure 5-45, we have classified the material 1628 as taxable.

Figure 5-44: Maintaining the customer tax classification in the customer master.

Figure 5-45: Maintaining the material tax classification in the material master.

Step 5: Maintain Sales Tax Identification Number Determination

In this step, you can specify a rule to determine the VAT registration number in a sales order or billing document. The path is IMG ⇒ Sales And Distribution ⇒ Basic Functions ⇒ Taxes ⇒ Maintain Sales Tax Identification Number Determination.

Leaving the Tax Number field blank leads you to a default priority rule. You can specify other rules, such as A (determined from the sold-to party) or B (determined from the payer).

Step 6: Maintain Tax Codes

This is a setting in the FI domain. Always set up tax codes in consultation with your FI team.

Tax codes represent a tax category. You can define tax rate calculation rules for each tax code using this path: IMG ⇒ Financial Accounting ⇒ Financial Accounting Global Settings ⇒ Tax On Sales/Purchases ⇒ Calculation ⇒ Define Tax Codes For Sales And Purchases (FTXP).

For a combination of country, tax code, and jurisdiction code, you can specify the tax percentage rate for each tax type.

Figure 5-46 shows that we are maintaining tax rates for the tax code S1 for the United States. In this example, we’re showing the jurisdiction code for Colorado. We’ve set the sales tax at 3%.

Step 7: Maintain Tax Condition Records

You use the transaction VK11 to set up tax records, just like any other pricing record. Besides the tax rate, you also specify the tax code in the condition record.

Figure 5-47 shows the example with condition type UTXJ. You can set up a condition record for a combination of country, customer tax classification, and material tax classification. In this case, for country US, customer tax classification 1 (taxable customer), material tax classification 1 (taxable material), we have maintained the tax code as S1. The system then uses this tax code to determine the exact tax rates.

Note that we have not maintained any tax rate in the Amount field. The reason is that the exact tax rates will be picked up from tax code S1, based on the rates set up in the previous step (FTXP).

During pricing, the system picks up the tax rate and calculates the tax amount. Figure 5-48 displays the tax amount below the Net value. The value is also stored in the VBAP table in the field MWSBP.

Figure 5-48: Tax amount on the conditions screen in the sales order

The tax determination case study (“Galaxy Musical Instruments Configuration Analysis: Tax Determination”) puts Figures 5.46 through 5.48 in a practical context.

Summary

Pricing and taxes are two of the most important areas in the SD application. In this chapter, we covered the steps to set up pricing, including how to use the condition technique to set up and determine pricing procedures. Then we discussed how to apply the concepts presented to some pricing-related requirements. We also discussed the basic concepts of tax determination and setup in this chapter.

In the next chapter, we will study availability check, transfer of requirements, and backorders.