Automatic pricing in sap sd

Prerequisites for Automatic Pricing
For the system to automatically determine pricing, the following prerequisites must be met:
Condition records must already exist in the system for each of the condition types that you want the system to apply automatically. For further information about creating and maintaining condition records, see Condition Records.
Where necessary, data must be maintained in the corresponding customer and material master records. If, for example, you want to apply discounts to special groups of customers or materials, then the system can only carry out automatic pricing when the groups are specified within the relevant customer or material master records.
Material Master Data
The price-related fields in the material master record can be found in the Sales: SalesOrg 1 and SalesOrg2 screens.
Tax classification: Indicates to what extent the material is liable for sales taxes.
Price material: In this field you can specify another material as a reference for pricing information. If you specify a reference, the system, uses all the condition records that apply to the reference material during automatic pricing.
Material group: Defines a group of materials for which you want to apply the same condition record. For example, using a material group, you can specify a discount that applies to a particular range of products.
Cash discount: In this field you can specify whether or not the material qualifies for a cash discount.
Customer Master Data
Most fields in the customer master record that relate to pricing appear on the Orders tab page under sales data.
Customer pricing procedure: Here you specify the pricing procedure for a customer. You create and maintain pricing procedures in Customizing for Sales and Distribution. During sales order processing the pricing procedure determines the kinds of pricing element you can use and in which sequence they are processed.
Price list: Price list types allow you to apply a material price in a particular currency to a group of customers. For example, you can specify a price list type that applies to all wholesale customers in one of your export markets.
Price group: Price groups let you apply a discount to a particular group of customers.
Tax classification: (You can find tax classification on the Billing tab page.) You can maintain tax classifications for your customers here.

Header and Item Conditions
Use
The standard system includes condition types that you can only apply at the header level, the header conditions. Condition types that you can only use for items are called item conditions. The standard system also includes some condition types that can be used both at header and item level: Percent from gross (RA01) Absolute discount (RB00) Weight discount (RD00).
Header Conditions
Automatic pricing does not take header conditions into account; you can not create condition records for them in the standard system. Header conditions are entered manually in order processing. R/3 includes the following header conditions:
Percent discount (HA00)
Absolute discount (HB00)
Freight (HD00)
Order value (HM00)
Item Conditions
In the standard system, most condition types are defined as item conditions. Examples of item conditions are:
Material discount (K004)
Customer/Material (K005)
Customer discount (K007)
Material price (PR01)
Displaying Header and Item Conditions
From the header and item pricing screens, you can branch to detailed information about each condition type that appears. From the header pricing screen, place the cursor on the condition for which you require detailed information.
In the header price screen, choose Condition detail. The system displays data it uses to calculate the amount of the condition (for example, the kind of pricing scale, quantity conversion, the scale base value, the document currency, and so on). From the details screen, you can choose Goto ® Condition record to see the specific condition record that the system accesses. From the item pricing screen, select the condition for which you require detailed information.
Accordingly choose Condition detail in the item price screen. To see the specific condition record that the system accesses, choose Goto ® Condition record.

Manual Pricing
Use
During sales order processing, you can manipulate pricing at both the header and item level. The options for manual processing of a price screen depend on the individual condition types. In Customizing the level of manipulability for each condition type is precisely defined. The following definitions are possible:
A condition type is not restricted with regard to its manual processing (for example, the entry of freight costs).
Manual entries have priority over results of pricing determined automatically or vice versa.
A condition type cannot be changed manually (for example, in the case of automatically determined sales taxes).
Making Changes During Manual Processing
Depending on the extent to which manual processing is allowed for a condition type, you can perform the following activities during sales order processing:
You can change a condition amount.
You can delete a pricing element.
You can enter additional pricing elements.
If you want to add pricing elements to a sales document, you can only enter pricing elements for which corresponding condition types are defined and for which manual processing is allowed.
Adding Pricing Elements Manually
You can enter pricing elements manually at both the header and item level.
Adding an Item Condition Manually
To enter a customer discount manually in the pricing screen of a sales order item:
In the pricing screen of the sales order, choose Add line.
You reach the data screen where you can enter an additional condition.
Enter the customer discount K007 in the Condition type field.
Enter a percentage rate in the Rate field.
Select ENTER.
The system automatically inserts the new condition according to the sequence specified in the corresponding pricing procedure.
You can choose Update prices on the pricing screen for a document item. To do this, you must select a pricing type. The prices will be updated according to the pricing type you selected.
Adding a Header Condition Manually
When including header conditions in the header pricing screen, proceed in the same way as described for item conditions. Afterwards you must activate pricing, by choosing Activate. When you activate the header condition, the system distributes the condition value proportionally among the various items in the sales document. This distribution can be based on the order value of each individual item or on other criteria specified in Customizing for Sales. For further information on header conditions, see Requirements for Automatic Pricing.
Changing Pricing Elements in Pricing Screens
Depending on how the condition types in your system have been configured, you can change automatically determined prices in the item pricing screen. If changes are allowed, you may be able, for example, to change the following data:
The rate (for example, the amount of a price or the percentage of a discount).
The currency in which the amount is calculated.
The units of measure used to calculate the amount.
Some condition types (for example, sales taxes, and cash discount) cannot usually be changed manually.
Header conditions cannot be entered or changed at the item level, and item conditions cannot be entered or changed at the header level. Conditions that are defined as both header and item conditions can be edited at both levels.
Deleting Pricing Elements in the Header and Item Pricing Screens
You can delete most conditions in the pricing screens. Whether a condition type may be deleted is determined by the condition type set in Customizing for Sales.
To delete a condition, position the cursor on the corresponding condition and choose Delete line.
The system automatically recalculates pricing for the entire document.

Distribution Between Header and Items
Use
Header conditions apply to all items in the document and are automatically distributed to the items. A header condition can be based on either a percentage or on an absolute amount. If you enter a header condition that is based on a percentage (for example, a discount of 2%) the system automatically applies this percentage to all items in the document. If the header condition is an absolute amount, there are two different ways in which the system can distribute the amount among the items in the document:
The condition value of a header condition is either
distributed proportionally among the items or
the amount entered at header level is duplicated for each item.
You control the distribution of absolute header conditions in the group price field per condition type. In the standard version, condition type HB00 is marked as a header condition and as group condition. Condition type RB00 is only marked as a header condition:
Condition type
Description
HB00
Header discount distributed as percentage because it is marked as a header condition and as a group condition
RB00
Assigns the header discount to every item, because it is only marked as a header condition
Example
The following figure illustrates examples of the two variations. If you enter an absolute discount with condition type RB00, the system takes the amount you enter as a header condition and copies the identical amount for each item in the document. In the example, the absolute discount of USD 90 appears in each item. The total condition value for the document is USD 270. However, if you enter an absolute discount with condition type HB00, the system distributes the amount proportionally among the various items, in this case, according to value of the items. In the example, the absolute discount of USD 90 is distributed proportionally among the items. The total condition value for the document is USD 90.
The distribution of an absolute header condition need not be based on value. For example you can specify in Customizing for Sales that the distribution is based on the weight or volume of the different items. You specify the basis of the distribution in the Alternative condition base value field in the pricing screen.
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.
Example:
A position has a net value of 200 USD, the second item has a value of 100 USD. A header surcharge of 10 USD should be allocated. The system sets a surcharge of 6.67 USD in the first item and 3.33 USD in the second item.

Implementing a New Pricing Procedure.
Use
You can implement a new pricing procedure in a sales or billing document. on the condition screens at item and header level.
In many cases, you may only want to redetermine tax or freight or you may want to receive manual conditions in spite of the revaluation. You can therefore agree a pricing type for a new pricing procedure in the dialog box.
The ‘Update prices’ function can also be implemented in the menu without a dialog box via Edit - > New pricing document (Transaction VA01 and VA02). In this case the pricing type which has been assigned to the pricing procedure in Customizing is valid. If no value is given, the pricing type "B" applies.
Selecting a pricing type is also possible for collective changes using transaction VA05.

Pricing Analysis
Use
When you are working in a sales or billing document, you can branch from the item pricing screen to a pricing analysis. You receive a list of all conditions for an item and a short overview of the transaction in automatic pricing. This information allows you to check how the system calculated the various pricing elements for an item.
Information in the Pricing Analysis
The analysis screen is divided into three.
In the left-hand side of the screen, an overview tree shows the four levels of pricing. These are:
the pricing procedure
condition types
accesses
any condition records found
In the upper right-hand side of the screen you receive more detailed information for the level of the overview tree that you have selected.
At condition type level you receive information on the number of accesses and why accesses have not been implemented. If a requirement for a condition type in the pricing procedure has not been met, you have the option to display routines by selecting Information.
At the access level you receive information on which fields work with an access. By selecting the technical view you can see the field names for an access.
At condition record level you can branch into the relevant condition record.
In the lower right-hand side of the screen you receive additional documentation for the access and condition levels. You can use this if the information in the detail screen is not enough.
Creating Promotions and Sales Deals
Steps:
You create promotions and sales deals in the same way. To create a new sales deal:
Choose Logistics ® Sales/distribution ® Master data in the main menu screen.
You reach the Sales Master Data screen.
Choose Agreements ® Sales deal ® Create.
You reach the Create Sales Deal screen.
Enter a sales deal type (for example, 0101) and choose Continue.
The Overview Agreement screen will appear. The system will propose a validity period.
Enter the optional data, such as:
– Short description of the sales deal
– An external reference (from the customer)
– The number of the promotion, if any, to which the sales deal is assigned
– Special payment terms
If you assign the sales deal to a promotion, the system proposes any special payment terms that you have defined for the promotion.
If you do not want to create condition records for the sales deal at this time, save your data. If you want to create condition records immediately, go to the next procedure.

Creating Condition Records Within a Sales Deal
You can create condition records for a sales deal in the following ways:
At the same time as you enter the master data for the sales deal in the system. (In this case, the system automatically creates the link between the condition records and the specific sales deal.)
By creating a new sales deal with reference to an existing sales deal and copying some or all of the condition records over
By adding new condition records into an existing sales deal.(In this case, you enter the number of the sales deal manually.)
By copying existing condition records into a sales deal you have already created.
For further information about copying condition records, see Copying Condition Records.
Steps:
To create condition records directly from within a sales deal:
Choose Pricing in the overview screen of the sales deal.
The system displays a list of valid condition types for this type of sales deal.
Select the condition type for which you want to create a condition record and enter your data.
If you want to create additional condition records for the sales deal, choose Back to return.
The system returns you to the dialog box that lists the valid condition types you can use.
After you have created the condition records you want, choose Back and save your data.

Release Status
Use
The release status for condition records in a sales deal enables you to limit the use of records that have already been created.
Release status has the following characteristics:
no entry: released
A: blocked
B: released for price simulation
C: released for price simulation and planning
The amount and significance of individual characteristics is defined using domain fixed values and can not be maintained.
Maintenance of the release status is carried out in the sales deal itself (in the proposed values block), is transferred over to the condition records concerned and can then not be changed for these records.
When setting up a new sales deal (with copy), a proposed value is suggested for the release status, which can be set up in Customizing for the agreement type.
A record blocked for an application is treated in the access, as though it has been identified with a deletion indicator. It can however be recognized and displayed as such via the log functionality in Pricing.
The characteristic Pricing Simulation is only used in the report SDNETPRO, which gives a net price list.
If when maintaining individual condition records a sales deal is assigned to the condition record using the transaction VK12, the release status from the sales deal is used for this record. When changing the release status using this sales deal or changes to the sales deal, the user will be notified of any changes to the status.

The release status of conditions in an agreement can only be changed, if
the condition record has release status in the key
the agreement has the release status released
Otherwise the condition record always has the release status of the agreement.
The processing status is always directly assigned to a release status. If conditions are assigned to an agreement, the agreement passes the release status on to all related conditions. The related processing status is then set accordingly.
If you have several processing statuses assigned to a release status, the condition record receives the first (alphabetical) suitable entry as a processing status.
The processing status, which the conditions have received indirectly from an agreement via the release status, can only be changed in the case of released agreements.
Budget Assignment in SD
Working with sale promotion and SD budgets can be split up into three stages:
Budget planning in CO-PA
Budget assignments in SD (condition record maintenance)
Passive availability check in CO-PA
Prerequisites
You must activate transferal of assignments to CO-PA per condition type. You carry this out in Customizing for CO-PA, under Flow of actual values ® Transfer of sales agreements.
Activities
Budget planning in CO-PA
A budget is planned within manual planning. You can use several planning functions to help you carry out manual planning. It is a good idea if you define your own plan version for a budget.
Budget assignments in SD (condition record maintenance)
Budget assignments can be made during condition record maintenance, as well as within sales promotions, sales deals and rebate agreements.
To maintain a budget assignment, select Logistics ® Sales and distribution ® Master data. Under Agreements, select either Rebate agreements, Promotion or Sales deal. Go to the condition screen for the required condition and display the detail screen for the required characteristic.
This is where you enter the Condition amount and the Planned basis. The system uses this to calculate the value that is filled in the relevant field in CO-PA.
Rule
Condition type
Planned basis
A
percentage
planned sales volume
B
fixed amount

C
quantity-dependent
planned quantity
etc.



You want to maintain a budget assignment, in which you grant a price reduction of 20% of the planned sales revenue of 100,000 USD for material A1.
In SD sales deal maintenance, you select the condition screen for the ‘price reduction’ screen. You then select the detail screen for material A1. Calculation rule ‘A’ - percentage is maintained. You enter 20 in the condition amount field and 100,000 in the planned basis field. Save your entries.
The system automatically calculates a planned value of 20,000 USD. This value is transferred (according to value field assignment) to the corresponding value field in CO-PA ‘Sales deductions’.
You can also maintain the planned values for all conditions in an agreement. You do this in the overview. In the agreement, select: Goto ® Overview ® Planned values.
Passive availability check in CO-PA
Using reporting in CO-PA, you can carry out a passive availability check. During this check, the planned version in which the budget was planned (in manual planning) is compared with the assignments from SD (via transaction type G).

Selecting Variable Views of Condition Records
Steps:
To select the variable views of condition record data:
Choose Logistics ® Sales/distribution ® Master data in the main menu screen.
You reach the Sales Master Data screen.
Choose Conditions and select the change or display mode for the type of condition record (price, discount, surcharge) you want to work with.
You reach the selection screen for the condition records.
Enter your selection data and choose Execute .
The system displays a list of the condition records which meet your selection criteria.
Choose Goto ® Overview ® Condition Records.
You reach the condition record overview screen.
Choose one of the dynamic push-buttons at the bottom of the screen.
Additional Functions
You can branch into individual records to display or change them. You can also select records for collective change. For example, you can select a number of records and change the validity period for all the selected records in one step.


Cost
Use
In Pricing, you may want to compare the prices with costs or even implement contribution margin accounting.
To do this, you can use the condition type VPRS as the cost price.
The condition type VPRS goes into the valuation segment in the material master and determines from this the standard price or average price.
Settings in Customizing
The condition type VPRS is labeled as a statistical condition in the pricing procedure.
Using the condition category G, the condition type VPRS goes into the valuation segment of the material master and determines from here the standard or average price.
The condition category S always accesses the standard price whereas condition category T always accesses the average price.
The profit margin is determined using the calculation formula 11 assigned in the pricing procedure. In this calculation formula the cost price is subtracted from the subtotal of net value 2.
For Pricing, the costs from a calculation can also be determined:
Sales order calculation for pricing
For a third-party business transaction, the costs are determined from the purchase order:
Cost

Gross Prices
Use
The gross price is relevant when selling goods to an end customer.
The pricing procedure RVAB02 is available as a reference for these sales processes.
The pricing procedure RVABB02 is, however, so flexible that it can also be used for a net price calculation. This means that you don’t have to maintain condition records twice.
Features
The pricing procedure RVAB02 has the following functions:
Entry of gross prices and discounts
Separate transfer of the new prices and discounts into the profitability analysis
Determination of net prices from gross prices for customers not subject to tax
Structure of the pricing procedure
The pricing procedure RVAB02 is divided into the following areas:
Prices:
Gross price determination (condition type PR01) or gross price entry (PB00)
Displaying the gross price in a subtotal
Discounts
Gross discount determination and entry
Displaying the cumulated discounts in a subtotal
Taxes:
Determination of tax amount, contained in the price (condition type MWI1)
Determination of tax amount, contained in the discounts (condition type MWI2)
Determination of the whole tax amount (condition type MWIS in the case of a gross sale)
Net prices and discounts
Option of transferring net prices and discounts into the profitability analysis separately
Rounding correction
The correction with the condition type NETD is necessary, as there may be differences between the total of MWI1+MWI2 and MWIS.
Net sale
In the case of a net sale (customer not taxable or foreign business), the condition type MWIG is used instead of MWIS. A net goods value is determined. If you wish to, you can calculate tax on the net value (condition type VAT)
Requirements 70 and 71 in the pricing procedure control whether a sale is net or gross. The requirements take into account things such as the customer tax code and the departure country and destination country.
You may want to print out different lines for the net and gross sales. Different subtotals have been set up for this in the pricing procedure RVAB02 with requirements 70 and 71.
You can copy the pricing procedure RVAB02 and enhance it.
Condition Exclusion
Use
I In pricing for sales and billing documents, more than one condition record may apply to a particular item at any one time. You can use the condition exclusion process to compare possible conditions in order to determine such things as the best price for a customer.
The Condition Exclusion Procedure
First of all, you create exclusion groups. An exclusion group is a list of condition types that is identified by a three-digit number. Exclusion groups are defined in Customizing for Sales. You also assign exclusion groups to a pricing procedure and to determine how the condition exclusion is to be carried out.
You then assign the exclusion groups to a pricing procedure, thus defining the condition exclusion.
Depending on how you configure exclusion groups in the pricing procedure, the system can use condition exclusion to select the best price or discount in six different ways:
Selecting the best condition record of a particular condition type from within one exclusion group
Selecting the most unsuitable condition from within one exclusion group
Selecting the best condition record for a condition type
Selecting the most unsuitable condition record for a condition type
Selecting the best conditions from different exclusion groups
Excluding all condition types in the second exclusion group if a particular condition type in the first exclusion group exists in the document
Determining Best Price From Condition Types
During automatic pricing for a sales order item, the system may find a number of valid condition records that apply to the same item. If the competing condition records belong to a variety of condition types, the system selects the record with the best price and excludes the other condition records. Condition records that the system ignores are not deleted from the sales order but are simply deactivated. You can still see the excluded condition records on the pricing screen in the sales order.
In condition exclusion in the standard system, a condition record with a zero value is not taken into consideration. It is treated as though it doesn’t exist.
If you want to take a zero value into consideration, enter the standard calculation formula 038 in the pricing procedure for one of the conditions to be compared.
The following is an example of a situation where a zero value should be taken into consideration:
A company has two condition types in the pricing procedure for surcharges. A condition exclusion group with these two condition types has been defined and shows that the lower of the two should be applied. In some cases the surcharge could be zero. The reason for this may be a condition record found or a manual entry. In order that the system takes zero into consideration as the lowest surcharge for the customer, the formula ‘38’ must be assigned to one of the condition types in the pricing procedure.

Determining Best Price Within One Condition Type
If the access sequence for a particular condition type does not specify exclusive accesses, it is possible for the competing condition records to exist within the same condition type. For example, the system may find two valid condition records for a material discount (K004) - one a material discount, the other a customer-specific material discount. The system determines the record with the most favorable discount for the customer.
If the Exclusive access indicator is set, the system looks no further after it finds the first valid condition record. In this case, the system cannot determine a best price.
Determining Best Price from Different Exclusion Groups
This method allows the system to check between exclusion groups for the most favorable price or discount. In this case, the system totals the condition values for each group, compares them, then selects the most advantageous group for the customer.
Excluding the Conditions in an Exclusion Group
In the fourth alternative when the system selects one particular condition type that exists in the first exclusion group, it excludes all the conditions in the second exclusion group from pricing.
After you have defined the exclusion groups you want to use, you can enter them in the pricing procedure. The following example shows how exclusion groups can be used in the pricing procedure. In this case, the exclusion procedure selected is the best condition type within one exclusion group.
TTh Pricing procedure
Exclusion group
Condition type
RVAA01
001
KA00 Sales promotion
RVAA01
001
K005 Customer/Material
RVAA01
002
KF00 Freight
RVAA01
002
KF01 Freight
RVAA01
002
KF02 Freight

You process a sales order item to which the following condition records apply:
Condition type
Rate
Value
Currency
PR00
100 USD/KI
100
USD
KA00
20%
20
USD
K005
10%
10
USD
KF01
1 USD/KI
1
USD
KF02
2 USD/KI
2
USD
In this example, exclusion group 001 deactivates condition type K005. (The system determines that the KA00 condition record is the best discount and ignores the other condition types defined in the group.) Exclusion group 002 deactivates condition type KF02 for the same reason. (The system determines that the KF01 condition record has the lowest freight cost and ignores the other condition types defined in the group.) The final price in this example is calculated this way:
100 USD – 20 USD + 1 USD = 81 USD/KI
Further Information
For further information on defining exclusion groups in Customizing for sales and distribution see the online implementation guide.


Variant Conditions
Definition
You can use variant conditions to influence the price of a configurable material depending on the characteristic values assigned.
Use
You can use variant conditions in Sales and Distribution and Purchasing to define surcharges and discounts for the basic price.
Structure
Variant conditions consist of a variant key and an amount that is identified by the variant key.
Minimum Order Value
Use
You can specify a minimum order value for sales order processing. The following example illustrates how this function is used:
You specify a minimum order value of USD 200.
During sales order processing, the net value (after discounts and freight, before taxes) of an incoming order is USD 190.08.
During pricing, the system determines that the net value falls below the minimum order value and calculates a minimum-order-value surcharge. In this example, the surcharge equals USD 9.92.
The minimum order value and the surcharge appear as separate lines in the pricing screen. The minimum value is for information purposes only, and does not affect pricing. The system automatically adjusts the net value of the order (before taxes) to the minimum value allowed.
Condition Types for Minimum Order Value
The standard R/3 System includes two condition types for processing minimum value requirements:
Condition type
Name
AMIW
Minimum order value
AMIZ
Minimum value proposal
Creating Condition Records for Minimum Order Value
If you use minimum-order-value requirements, you must create condition records for condition type AMIW. In these condition records, you specify customers and the corresponding minimum order values. During pricing, the system automatically uses these condition records as a reference for determining the relevant minimum order surcharges (condition type AMIZ). In the standard version, condition type AMIZ refers to AMIW. This means that the system automatically calculates values for AMIZ conditions; you do not need to create separate condition records.
You may want to specify minimum order values by sales organization or division instead of by customer. In order to do this, your system administrator must define a new condition table with the appropriate fields in the table key. The condition table can then be included in the access sequence for condition type AMIW.

Sales Order Costing in Pricing
Use
You can carry out costing for a sales document item (item in an inquiry, quotation or an order) to find out the planned costs for this item. This is called sales order costing.
Sales order costing can be carried out using the following methods:
Product costing
Product costing calculates the cost of the sales order item on the basis of the sales order BOM. A sales order BOM could be part of a super BOM and the configuration object dependencies.
Unit costing
Unit costing is used if the system cannot access a sales order BOM. You enter the items to be costed manually in unit costing.

The system determines the prices of the materials and services involved according to the valuation variants saved in the costing variant.
You can use sales order costing to determine the manufacturing costs and total production costs of a material managed as sales stock. As well as the direct material costs and the direct costs of production, you can also determine material overhead costs, production overhead costs, distribution and administration costs or transportation and insurance costs.
Sales order costing is controlled mainly via the costing variant. The costing variant is stored in the requirements class as a proposal value. In the requirements class, you also store the costing method and the costing sheet.

Copying Sales Order Costing to the SD Conditions
You can copy the results of sales order costing to the SD conditions. Copying can be carried out:
as a basis for pricing
If you want to use sales order costing as a basis for pricing in SD, you can use the standard SAP condition type EK01.
at a statistical level
You can copy sales order costing at a statistical level, if you do not wish to determine the price on the basis of this costing, but you wish to use the costs determined to calculate the profit margin in SD. EK02 is the condition type provided for this in the standard system.
You can save the condition type in the sales and distribution document type. If you want to define the condition type with reference to the sales document item, then you can also save the condition type in the requirements class.
In the requirements class, you can also store a condition type for the transfer of the fixed costs proportion of the planned costs. EK03 is the condition provided for this in the standard system.
For further information on sales order costing, see:
Sales order costing
For more information on Customizing for sales order costing, see the online Implementation Guide.
Controlling ® Product Cost Controlling ® Cost Object Controlling ® Product Cost by Sales Order ® Control of Sales-Order-Related Controlling and Preliminary Costing

Duplicating Conditions
Use
In the standard system, you can use condition type DUPL, which is copied during pricing to all of the sub-items assigned to the item.
For this reason, it only makes sense to use duplicated conditions for bills of materials and configurable materials.
A duplicated condition of 10% is specified for material 4711. The material has components 4712 and 4713. During pricing in the sales order, the duplicated condition of 10% is displayed in components 4712 and 4713.
Constraints
There are several limitations to duplicated conditions: Duplicated conditions can only be percentage rate conditions.
Duplicated conditions cannot be used as header conditions.
The condition value of a duplicated condition cannot be changed manually in the pricing screen.
When you copy a sales document to a billing document, the condition rate of a duplicated condition is frozen. This means that the condition is not redetermined when it is copied regardless of the pricing type.

Cumulating Conditions
Use
The standard system condition type KUMU enables you to display the total of the net values of an item and all the sub-items belonging to that item.
Item
Main item
Item net value
Net value
0010

0,00
355,00
0020
0010
100,00
320,00
0030
0010
35,00
35,00
0040
0020
80,00
80,00
0050
0020
140,00
140,00

Constraints
Cumulative conditions cannot be used as header conditions.
Cumulative conditions cannot be processed manually.
When you copy a sales document to a billing document, the condition rate and the condition value of a cumulative condition is ‘frozen’. This means that the condition is not redetermined when it is copied regardless of the pricing type. The net value of the total is not redetermined even if the individual net values have changed.

Group Conditions
Use
You want some conditions to be used as the basis for determining scale values from several items.
You have assigned materials to a material pricing group. You want a quantity-based discount to be assigned to these materials. You want the quantity scale to be read cumulatively with the cumulated quantity of all materials in the sales order that are assigned to this material pricing group:
Condition record with reference to a material pricing group:
From 1 KG
- 2,-USD / KG
From 100 KG
- 4,-USD / KG
From 500 KG
- 6,-USD / KG
Pricing in the order for two materials from the material pricing group:
Item 10
Material 1
60 KG
-20,- USD discount
Item 20
Material 2
70 KG
-20,- USD discount

Prerequisites
You must mark the condition type as a group condition in Customizing
If you want the system to carry out cumulation across all items, but to read a separate condition record with this cumulated quantity for each item, you must make the following additional entries for the condition type:
Quantity unit for cumulation
Group key number

Pallet Discounts
Use
The pallet discounts should make it possible for you to assign conditions for whole units of measure only. There are the following requirements:
Surcharges and discounts should be calculated.
Quantities should be cumulated for all items.
There are condition types available in the standard system for the different requirements. These will be explained later on using examples.
Condition Type KP00
The aim of the pallet discount is to give a discount only for whole units, e.g. whole pallets.
This is controlled using the base value calculation formula 22 from the pricing procedure, after the total amount of quantities has been taken into account.

Condition Type KP01
The aim of the surcharge for an incomplete pallet is to assign a surcharge for
This is controlled in the pricing procedure using the base value calculation formula 24. This checks the partial quantity.


Condition Type KP02
The aim of the mixed pallet discount is to cumulate the quantities for individual items, but only to calculate the discount for whole pallets.
This is controlled using the condition type KP02 (Group cond. = X and unit of measure = PAL) and the corresponding condition record.

Condition Type KP03
The aim of the surcharge for an incomplete mixed pallet is to cumulate the quantity of items. If there is a partial pallet quantity for a total quantity, a surcharge should be charged.
This is controlled using the condition type KP03 (Group cond. = X, unit of measure = PAL and scale formula 23, which calculates the partial pallet quantity from the total quantity).



Hierarchical Accesses
Use
Hierarchy accesses are used to optimize pricing for hierarchical data constellations such as a product hierarchy. When using hierarchies of this kind, it may be necessary to use any number of partial quantities (taken from the specified quantity of characteristics) to define the keys of the condition tables. A simple example of this would be a price that is fixed for sales organization and distribution channel but otherwise depends upon either customer, material or both.
Without hierarchy accesses, you would need to create a condition table for every combination and assign all accesses to this table in a hierarchy within an access sequence. This would not only take a great deal of time, but it would also reduce system performance and force the system to use a rigidly fixed sequence of accesses.
This represents a major drawback, especially for hierarchical data such as that representing a product hierarchy or a customer hierarchy.
Using the hierarchy access function, the system can find variants of this kind with a single access to a condition table containing all the necessary fields in the variable key. It can then determine the required condition record according to the relevant criteria.
Prerequisites
When creating an access sequence in a condition table for the fields of an access, the user has the option of defining which part of the key remains fixed and which part can vary (these are the free fields and the optional fields in condition maintenance). During access sequence maintenance, you assign priorities to the fields in the variable part of the key. These priorities are used to evaluate the relevance of the condition records determined using the fixed part of the key.
In Customizing for Pricing, you need to make the following settings in the access at field level:
Processing type in access (AType field): By entering A, you indicate that it is a free field. Free fields are optional fields during condition record maintenance, so that any combination of characteristics can be created for an access.
Evaluation of characteristics (Prio field): You can assign a priority from 01 (high) to 99 (low).

The records with the highest priorities are then made available in pricing.
The quick entry screen for the condition records is not used. Mandatory entry is not used for the optional fields.
When using hierarchical accesses, you should always use physical deletion and not the deletion indicator. This is because condition records are determined using the priority for hierarchical conditions before Pricing takes place. However the deletion indicator is not checked until Pricing has begun. This can lead to the following:
A condition record may have top priority for the hierarchical accesses and be transferred to Pricing. Using one of the deletion indicators however, the condition record is then sent out of Pricing without a replacement.
You can find more information on deletion in the unit Deleting condition records.
Example of Pricing with Free Fields
You want to set up Pricing for materials that are assigned to a product hierarchy. You mark the hierarchy levels as free fields and enter a priority. As a rule, the priority should increase as you move from general to more specific criteria:


Field
Processing type in access
Evaluation
Sales organization


Material group
A
5
Main group
A
4
Group
A
3
Sub-group
A
2
Material
A
1

The advantage of this is that only one access needs to be created in the access sequence during master data maintenance. This is because the free fields represent optional fields during condition record maintenance, allowing any number of combinations of characteristics for an access.
You also get a much better overview of master data maintenance, because the different condition records can be created for a condition type in the condition maintenance quick entry screen.

Example Data in the Standard System
You can use condition type K148 with access sequence PRHI to test hierarchy accesses.


Data Determination for Sales Deals
Use
A special data transfer technique is used for sales deal data determination. You enable this by assigning condition class H (sales deal determination) in the condition type.
The data used in the following example are provided in the standard system as example data.
Sales Deal Example
You want to determine one or more sales deals for customers within a customer group. You want to use these sales deals to determine material prices.
The following condition types must exist in the pricing procedure:
Conditions in the pricing procedure:
Condition type
Condition class
Access sequence
Requirement
PB1 (used for data determination)
H
PBD

PB1D (used for data application)
A
PBUD
062 (used for completing internal tables for several determined sales deals)
(The standard system provides sales deal type PRB1, to which these condition types are assigned).

Data Determination

Condition type PB1 and access PBD are used to determine one or more sales deals.
You may want to determine several sales deals, since more than one may be relevant for the customer. In this case, you can not use the data determination methods using processing type C, as described above, because a condition with the same key can only occur once. Here, you can use data determination B, which marks a key field for data determination. This allows for several records with identical customer data but different sales deal numbers.
You specify data determination B for a field in the access of an access sequence.
Access Sequence for Data Determination:
Access sequence PBD with the following access:
Field
Field description
Processing type in access (field PType)
KNUMA_AG
Sales deal
B (key field for data determination)

This access reads the following condition record and determines sales deal numbers 01 and 02:
Condition record
For condition type PB1:
Sold-to party
Sales deal

0001
01

0001
02


Data application:
Condition type PB1D has access sequence PBUD, which contains the sales deal in its key:
Access sequence PBUD with the following access:
Document structure
Document field
Processing type in access (field AType)
KOMP
KNUMA_AG


The following condition records are read using this access. Different discounts can now be granted, depending on where the sales deals apply.
Condition record for condition type PB1D:
Sales deal
Material group
Discount
01
01
- 2,00 %
02
01
- 3,00 %


Data Determination using Routines
Use
The previous unit describes data determination for fields within accesses using communication structure KOMPAZD. You can not use communication structure KOMPAZD to determine data for fields that are not used in accesses, such as the scale quantity or the pricing date. In these cases, you must carry out the data transfer using routines.
First of all the data is determined using a condition type such as PBUD, for example. This includes the access sequence PBUD assigned to the condition type PBUD and the pricing date field, which is indicated as a data determination field.
Afterwards a routine can be assigned to the discount, which uses the data for pricing.
Prerequisite: Indicate a field as a data determination field
Data determination in the access for pricing takes place at field level. A field is selected for this. It is used for data determination, not pricing. This is carried out as follows:
When maintaining a condition table, you can choose a field from the key in the Technical Settings field. It is then designated as a data field and is automatically indicated with C in the access. This is only possible when creating. In exceptional cases you can use it when changing: delete – add new one
In the pricing procedure, condition type PBUD is used for data determination. You can then assign as many discounts/surcharges for use in pricing to the following routines:

Conditions in the pricing procedure:
Condition type
Requirement in the
the pricing procedure
PBUD (Data determination)

KXXX (Use of data)
202 (used to apply the pricing date determined using condition type PBUD for pricing)


The data used in the following example are provided in the standard system as example data.
Pricing Date Example
You want to grant prices from a previous year to customers in a certain customer group. These prices are however no longer valid. You enter pricing date 12.31 from the previous year for pricing.
To do this, data must be determined and applied to pricing again. In this example, condition type PBUD is used for determining the data. Pricing then uses this data to determine a suitable discount. In the following example the condition type KXXX is specified. Both conditions must be copied to the pricing procedure.

Data Determination
The access sequence PBUD contains the field KDATU.
The field KDATU is indicated as the data determination field.
Access sequence PBUD with the following access:
Field
Name
Processing type in access (field AType)
KDATU
Pricing date
C (data field for data determination)
This access can be used to read a customer specific condition record, which determines a pricing date as the date from the previous year.

Using the Data for Pricing
You can now assign requirement 202 to a discount in the pricing procedure. This ensures that the pricing date from the previously determined field KDATU is used for pricing.

Price Book
Use
The term ‘Price Book’ is used to describe a pricing determination strategy:
Material prices form the basis of the price book.
These prices are first determined via customer-specific data and then adapted according to special agreements determined via material-specific data.
Pricing procedure RVAA02 is provided in the standard system as an example.
This pricing procedure is described below. Make sure that you are familiar with the different types of data determination, as described in the previous units, before reading this example.

Example of a Price Book (Pricing Procedure RVAA02)
You want to grant special prices to customers in a certain customer group. You want special, material-dependent agreements (e.g. fixed scale quantities) to be applied to these prices during pricing, however.
You arrange this via data determination in two stages:
Level 1: You determine the sales deal number with reference to the customer group.
Level 2: You determine the special agreements, dependent upon the material group and with reference to the pricing date, the scale quantity and the item price list.

Data determination in two stages:
Condition type
Name
Function
Data determination technique
PBU
Price book determination
Determination of a sales deal number (depends on customer data)
Data determination with condition class H for sales deals (see the unit on data determination for sales deals)
PBUD
Price book basis
Determination of the following data (material-dependent) for the sales deal number determined.
Pricing date
Scale quantity
Item price list
The sales deal is in the access key
The data determined have processing type C (data determination fields) in the access (see the unit on data determination with routines).

The special agreements determined are used in pricing for the following condition.

Data application:
Condition type
Name
Function
Data transfer
PBBS
Base price
Use of the data determined:
Pricing date

Scale quantity


Item price list

Requirement 202 in the pricing procedure
Scale basis formula 202 in the condition type
(see the unit on data determination with routines)

Communication structure KOMPAZD
(see the unit on data determination with a communication structure)
PBUP
Gross price
You can use condition PBUP to make a percentage calculation for the preceding condition
Basis formula 202 in the pricing procedure



Condition Interchange
Use
You want to interchange conditions with other SAP systems or with external systems.
Examples of Inbound Processes:
Provides R/3 with data from the old or external system, for example, in the introductory phase
Transfers the stipulated retailed prices from a vendor
Transfers the individual retail prices from a wholesale customer
Examples of Outbound Processes:
Provides price information for new materials from the subsystems
Provides a new subsystem with price information
What are the New Developments in Outbound Processing?
Automatic selection and distribution using change documents from price and condition maintenance
Manual selection and distribution without the need for change documents (for condition maintenance this can be done in Condition Info)
Idoc modification option via Customer Functions
What are the New Developoments in Outbound Processing?
You can transfer Idocs into the master conditions (tables: Axxx, Konh, Konp, Konm/Konw)
this also applies to purchasing info records
document-related conditions (contracts)
and purchasing rebates (agreement)
but not for other agreements (KONA reference)
and not for free goods
You have the option of modifying Idocs via Customer Functions


Creating Pricing Reports
Use
You can create your own pricing reports in Customizing for Sales and Distribution under Sales and Distribution ® Basic Functions ® Pricing (Transaction V/LA). Technically speaking, pricing reports represent ABAP/4 programs.
The SAP Standard System contains pre-defined pricing reports, that can be started via the application menu (Choose Logistics ® Sales and Distribution ® Master Data ® Information system ® Conditions and Pricing ® Pricing Reports). Pricing reports can also be used for maintaining conditions. Read Maintaining Condition Records.
Procedure
Check the extent to which the pricing reports in the SAP Standard System can be used. You can also display the defined pricing reports.
Create new pricing reports (in Customizing under Sales and Distribution ® Basic Functions ® Pricing, transaction V/LA). Proceed as follows:
Enter a short text name, consisting of two characters, the first of which must be a letter, and the title of a pricing report that you would like to create. On the next data screen you will see all key fields used in conditions, listed in alphabetical order. Select all key fields that should be taken into consideration in the pricing report.
If you choose "Edit -> continue with AND", all condition tables are evaluated, that contain at least one of the selected key fields. If you choose "Edit -> continue with AND", all condition tables are evaluated, that contain at least one of the selected key fields. In the next dialog box, mark all condition tables that are to be evaluated.
Choose "Continue to list structure" to define the screen structure for the pricing report. Make sure that on the next screen all key fields from the selected tables appear. Fields, that are not used as selection criteria when displaying the list later, can be removed by undoing selection in the "Selection" column. Fields can be marked as obligatory fields on the selection screen. The structure of the pricing reports means that information can be placed in different places in the list. The layout contains the following elements:

This layout element...
has the following function in the list...
Page header
Information that applies to each report page
Group header
Subdivides information into categories
Item
Specific information from a condition record

Example
The following figure illustrates a section from a sample pricing report that provides information about customer-specific prices but does not include details of pricing scales. The different layout elements are indicated in the figure.

Running a Pricing Report
Steps:
To run a pricing report:
In the initial screen choose Logistics ® Sales and Distribution ® Master data ® Information system ® Conditions and pricing ® Pricing Reports (Transaction V/LD).
You reach the Execute Pricing Report screen.
Enter the name of the pricing report you want to run.
If you do not know the name, choose Possible entries. A dialog box appears, in which you can search for a report either by the report name or by the descriptive title or by both. You can also search generically by entering *. If you choose Continue, the system lists all the available pricing reports.
If you leave both fields blank and choose Continue, the system displays all available pricing reports.
Choose Execute.
You reach the selection screen for the pricing report you want to run.
The screen sections in the selection screen detail how the list is structured. The fields in the areas Page header, Group header and Items specify where the fields are placed in the pricing report. An arrow in the lower right section of the screen means that there are more fields in the pricing report than displayed on the current data screen.
Limit the report by specifying selection criteria so that you obtain the relevant information.
You can use Free accruals to enter additional selection criteria, that is not displayed on the selection screen. You can, for example, assign the order taker to a condition as a selection criteria.
Choose Execute.
The system displays the pricing report.
The more information the list contains, the more complex the handling of the list. You can display wide lists using the horizontal screen strip? You can also work with a larger window.
Printing the Pricing Report
To print out a pricing report, choose Prin t . on the Pricing Report screen. On the following screen, enter the output device and the specifications on spool control and choose Output ® Print.
Working with Variants of Pricing Reports
If you frequently use pricing reports with the same selection criteria, you can store the pricing reports as variants and use them again later. When you run the pricing report, you can then call up the variant and the system automatically enters the selection criteria for you. To create and maintain variants from the selection screen of a pricing report, choose Goto ® Variants.



Net Price Lists
Use
The net price list allows you to provide your customers with pricing information on materials.
Features
In the menu, choose: Sales and distribution ® Master data ® Pricing reports ® Net price lists.
Enter the sales area, the sold-to party and the plant.
Enter the data that influences pricing (such as order type and pricing date).
After starting program SDNETPRO a billing document is simulated and the system issues the result.
The net price list works with the ABAP List Viewer.
You can define your own display variants using the ABAP List Viewer. All fields of table VBRP are also available. Subtotal fields KZW11 to KZW16 can be used to create customer-specific information.
You can find more information on the ABAP List Viewer in: Cross Application Components ® General Application Functions