Sunday, 17 July 2016

Condition Base Value useages in priceing routine

Condition base value formulas can be used to influence the condition basis to which the pricing condition rate will be applied. In standard pricing, the system will apply the condition rate to the quantity in the sales document. For example, the price determined by the system is $45 per case for Product A. 100 cases of Product A have been ordered. The system would then multiply $45 times the number of cases of Product A ordered. Using a condition base value formula, it is possible to alter the condition base, in our example 100, prior to the calculation taking place. A condition base value formula is commonly used to determine the base for distributing header discounts / surcharges to the sales document line items. A condition base value formula is assigned to a condition type in the pricing procedure.

When looking at the code for the standard delivered condition base value formulas or when writing your own, XKWERT is the field name that the condition base value should be assigned to.
Following is a description of the condition base value formulas delivered in the standard system. CONDITION BASE VALUE FORMULA 1: VOLUME
Formula '1' uses the volume of the sales document line item as the condition base value.
Example:
A company regularly applies fixed amount header discounts to a sales order. For example, the user may apply a fixed discount of 500 USD to the header of the sales order. Fixed header conditions are always distributed
across the line items in the document. In this case, the company would like to distribute the fixed amount



                                                                                                                                                                



based on the volume of the line items. To accomplish this, the user would assign condition base value formula
'1' to the header discount condition type in the pricing procedure.

CONDITION BASE VALUE FORMULA 2: NET VALUE
Formula '2' uses the net value of the sales document line item as the condition base value.

Example:
Reference example for formula 1

CONDITION BASE VALUE FORMULA 3: NET PRICE
Formula '3' was delivered to support net price processing. For additional information on the use of this formula along with examples, please refer to Note 80183.

CONDITION BASE VALUE FORMULA 4: NET VALUE PLUS TAX
Formula '4' uses the net value plus tax of the sales document line item as the condition base value. Example:
Reference example for formula 1

CONDITION BASE VALUE FORMULA 5: KZWI1
Formula '5' uses the value determined for subtotal '1' in the pricing procedure as the condition base value. Example:
A company regularly applies fixed amount header discounts to a sales order. For example, the user may apply
a fixed discount of 500 USD to the header of the sales order. Fixed header conditions are always distributed across the line items in the document. In this case, the company would like to distribute the fixed amount based on a subtotal derived based on certain values in the pricing procedure. The user has assigned subtotal '1' to the relevant pricing procedure value(s). In addition, the user would assign condition base value formula '5' to the header discount condition type in the pricing procedure.

CONDITION BASE VALUE FORMULA 6: KZWI2
Formula '5' uses the value determined for subtotal '2' in the pricing procedure as the condition base value. Example:
Reference example for formula 5

CONDITION BASE VALUE FORMULA 7: KZWI3
Formula '5' uses the value determined for subtotal '3' in the pricing procedure as the condition base value.

Example:
Reference example for formula 5

CONDITION BASE VALUE FORMULA 11: CASH DISCOUNT BASE
Formula '11' can be used with the cash discount condition type. This formula reads the indicator for the company code to determine if the cash discount is based on the net value of the item. If it is not, then the system bases it off of the net value plus the tax.

CONDITION BASE VALUE FORMULA 12: GROSS WEIGHT
Formula '12' uses the gross weight of the sales document line item as the condition base value. Example:
Reference example for formula 1



                                                                                                                                                                  4\15



CONDITION BASE VALUE FORMULA 13: NET WEIGHT
Formula '13' uses the net weight of the sales document line item as the condition base value. Example:
Reference example for formula 1

CONDITION BASE VALUE FORMULA 14: SET EXCLUSION INDICATOR
Formula '14' is an example of how a programmer can dynamically set the condition exclusion indicator based on certain values. This condition exclusion indicator can then be checked in subsequent condition base value formulas (reference formula '15') to exclude certain condition types.

CONDITION BASE VALUE FORMULA 15: CHECK EXCLUSION INDICATOR
Formula '15' is an example of how a programmer can check the value of the condition exclusion indicator and then influence certain values. In this example, if the exclusion field is set to '$', the condition base value is set to zero and the condition is marked inactive. This example is provided in combination with formula '14' which shows how to dynamically set the condition exclusion indicator.

CONDITION BASE VALUE FORMULA 16: NET VALUE MINUS CASH DISCOUNT
Formula '16' uses the net value minus the cash discount value as the base value. This can, for example, be applied to a tax condition type that should use this value as a basis.

CONDITION BASE VALUE FORMULA 17: NET PRICE
Formula '17' was delivered to support net price processing.

CONDITION BASE VALUE FORMULA 18: NO QUANTITY CONVERSION
Formula '18' is used to avoid rounding errors that can occur for quantity dependent condition types where the sales unit and the pricing unit are one unit of measure and the base unit of measure is another. Using formula
'18', no conversion is done to base unit of measure when the sales unit of measure and pricing unit of measure are identical.

NOTE: The user can achieve the same result by setting the "quantity conversion" indicator in condition type configuration.



Example:
A company uses KG as their base unit of measure, but chooses to quote prices and sell products in pieces (PC). A quantity conversion has been maintained to indicate that 3 PC correspond to 1 KG. A pricing record has been created to price 1 PC of product at 1 USD. If a customer orders, for example, 1 PC of product, it is possible that the system returns back an item value of 0.999 USD. To avoid this, the user assigns condition base value formula '18' to the price condition type as well as other quantity dependent condition types in the pricing procedure.

CONDITION BASE VALUE FORMULA 19: KZWI4
Formula '19' uses the value determined for subtotal '4' in the pricing procedure as the condition base value. Example:
Reference example for formula 5

CONDITION BASE VALUE FORMULA 20: KZWI5
Formula '20' uses the value determined for subtotal '5' in the pricing procedure as the condition base value.


                                                                                                                                                                  5\15



Example:
Reference example for formula 5

CONDITION BASE VALUE FORMULA 21: KZWI6
Formula '21' uses the value determined for subtotal '6' in the pricing procedure as the condition base value. Example:
Reference example for formula 5

CONDITION BASE VALUE FORMULA 22: WHOLE NUMBER
Formula '22' is used to convert the basis to a whole number. For example, a basis of 300.153 would be converted to 300. Formula '22' is delivered in R/3 along with the condition type KP00 which can be used to compute pallet discounts.

Example:
A company sells their products in cases. Each of their materials has a conversion factor to pallets. When an order is placed by a customer, the user would like the system to calculate the number of full pallets for each
line and to offer a 5 USD discount per full pallet ordered. The user sets up condition type KP00 in the pricing
procedure and assigns condition base value formula '22'. Within the condition records for condition type KP00, the user maintains the 5 USD per pallet discount rate. If an order line item is placed that contains 5.5 pallets, the system will adjust the base value to 5 and compute a discount of 25 USD for the sales line item.

CONDITION BASE VALUE FORMULA 24: 1 IF PARTIAL QUANTITY
Formula '24' is used to convert the basis to a quantity of 1 if a partial quantity is involved, otherwise the basis is set to zero. For example, a basis of 300.153 would be converted to 1. As a second example, a basis of 300 would be converted to zero. Formula '24' is delivered in R/3 along with the condition type KP01 which can be used to calculate an incomplete pallet surcharge.

Example:
A company sells their products in cases. Each of their materials has a conversion factor to pallets. When an order is placed by a customer, the user would like the system to calculate the number of full pallets for each line and to charge a 5 USD surcharge to the item if a full pallet quantity is not ordered. The user sets up condition type KP01 in the pricing procedure and assigns condition base value formula '24'. Within the condition records for condition type KP01, the user maintains the 5 USD surcharge. If an order line item is placed that contains 5.5 pallets, the system will adjust the base value to 1 and compute a surcharge of 5 USD for the sales line item.

CONDITION BASE VALUE FORMULA 26: BOLLO IN FATTURA
Formula '26' was provided to support the Italian Bollo in Fattura. Using this formula will set the condition to inactive if the VAT value is not zero. This formula can be assigned to the R/3 delivered condition types BOLL and MWBO in the pricing procedure.

CONDITION BASE VALUE FORMULA 27: XWORKK DEACTIVATE CONDITION
This formula was delivered to support tax exemption licenses in Italy. The condition base value formula '27' is assigned to the tax condition type in the pricing procedure. The formula is used to deactivate the tax when a valid license exists..

CONDITION BASE VALUE FORMULA 28: 100% DISCOUNT
Formula '28' sets the rate of the condition to a 100% discount.


                                                                                                                                                                  6\15



Example:
A company has a free goods agreement with their customers. For every 10 cases of Product A that the customer buys, the customer receives 2 cases of Product B for free. From a pricing perspective, the user wants to track both revenue and sales deductions for the free items since Product B is also sold by itself sometimes
in the sales process. To do this, the user flags the free goods item category with the pricing indicator 'B'. In addition, the user adds the R/3 delivered condition type R100 to the pricing procedure at the point at which the
100% discount should be applied. Condition base value formula '28' is assigned to condition type R100 in the pricing procedure to apply the 100% discount rate.

CONDITION BASE VALUE FORMULA 29: FREE GOODS / INCLUSIVE
Formula '29' was delivered along with condition type NRAB to support Release 4.5 Inclusive Free Goods agreements where the user would prefer to have a discount applied to the ordered item rather than having a sub-item generated for the free quantity.
Example:
A company has a free goods agreement with their customers. If the customer orders 100 cases of Product A, they receive 10 of these cases free of charge. Instead of having a free sub-item generated by the system to
represent the free 10 cases, the user would like a discount applied to the 100 case line item equal to the value
of 10 cases. To accomplish this, the user assigns the NRAB condition type to the pricing procedure and assigns the condition base value formula '29'.

CONDITION BASE VALUE FORMULA 44: VAT FRANCE
This formula was delivered to support tax exemption licenses in France. The condition base value formula '44' is assigned to the tax condition type in the pricing procedure. The formula is used to deactivate the tax when a valid license exists. For additional information on tax exemption licenses, please refer to Note 72040.

CONDITION BASE VALUE FORMULA 50: QUANTITY ACTIVE INGREDIANT
Condition base value formula '50' was delivered to support pricing based on active ingredient quantities. This formula is assigned to the condition types in the pricing procedure for which you work with proportion quantities. Using this formula, the system can carry out billing at the main item level where the system
cumulates the quantities from the batch split items.

CONDITION BASE VALUE FORMULA 51: SHIPMENT COSTING -TAXES
Formula '51' was delivered along with shipment costing in the shipment cost document. This formula assigns the tax indicator from the tax condition record to the shipment cost document item. This condition base value formula should be assigned to tax condition types in the shipment cost document pricing procedure.



CONDITION BASE VALUE FORMULA 61: PREFERENCE
Condition base value formula '61' was delivered to solve a field overflow problem that can occur when working with preference determination. This can occur due to the quantity dependency. Formula '61' is
assigned to the preference condition type in the pricing procedure (R/3 delivered condition type PREF).

CONDITION BASE VALUE FORMULA 202: PRICE BOOK FACTOR
Formula '202' can be used to offer a price that is a percentage of a predefined price. For additional information on this Release 4.5 feature, please refer to the R/3 Library documentation on Price Book, which can be found in the Special Pricing Functions (Data Determination in the Access) section of the Sales & Distribution
Pricing Guide.


                                                                                                                                                                  7\15



Example:
A company would like to define a pricing agreement with their customer whereby the customer should pay
90% of the material price from the previous year. This agreement can be stored using R/3 Price Book functionality and the pre-delivered condition type PBUD. 90% is entered as the condition value in the PBUD
condition record and the pricing date is defined using the data determination in access functionality. In the

Price Book pricing procedure, condition type PBBS is then used to determine the base price from last year. Next in the pricing procedure is condition type PBUP which is used to determine the gross price which should be 90% of last year's price. To perform this calculation, condition basis formula '202' is assigned to condition type PBUP in the pricing procedure.

Fields in Pricing Procedure

Define Pricing Procedure

A pricing procedure is a procedure by where in which you control the execution of condition tyoes in a sequence you would like . It not only executes the condition types but also controls the execution of condition type by the use of requirements , altcv. altcbv, account key.

In other words, Pricing procedure is a systematic and sequential use of condition types to arrive at a right value of the product.

To determine the pricing procedure SALES AREA (Sales Organization + Distribution Channel + Division) + CUSTOMER PRICING PROCEDURE (from Customer master) + DOCUMENT PRICING PROCEDURE (from Sales Doc type)


To view a select the pricing procedure in SPRO which is the standard and copy it and create our own pricing procedure.

 We can see that there are 16 columns in the pricing procedure, these are going to be used by the system to control the condition types.


The detail description of each column is given below:


1. Step:

· Number that determines the sequence of the conditions with in a procedure.

· It indicates the position of the condition type in pricing procedure.

· Ex.: 10, 15 etc.

2. Counter:

· System uses the counter to count the steps and also it can be used to count mini steps of same condition types. So that number of steps can be reduced in the pricing procedure and hence enhancing the system performance.

· Access number of the conditions with in a step in the pricing procedure.

· During automatic pricing, the system takes into account the sequence specified by the counter.

3. Condition Type:

· It represents pricing element in pricing procedure as a base price, discount, freight and tax.

· The condition type is used for different functions. In pricing, for example, the condition type lets you differentiate between different kinds of discount; in output determination, between different output types such as order confirmation or delivery note; in batch determination, between different strategy types.

· Ex.: PR00 - Price, K004 - Material Discount, K005 - Customer/Material Discount, K007 - Customer Discount.

4. Description:

· System copies description of condition type from its description (V/06).

5. From and 6. To:

1. From: This can be used as a base to the condition type for calculating further value.

2. From and To: The range between the steps from and to can be used to specify the range between same condition types. So that depending upon the condition type, the system deducts or adds the total value of those condition types from specific common source.

7. Manual:

· This indicator specifies whether the specific condition type can be determined manually during sales order processing.

· If we check the box then the entry is going to be manual, if we uncheck it, it is going to be automatic.

· For Base Price and Taxes, the entry should be automatic.

· For Discounts and Freights, The entry should be manual.

· If we check the box, in VA01 when we go to conditions at the header/item level, the condition type will not be listed. If we require we will have to manually enter it.

· If we uncheck the box, in VA01 when we go to conditions at the header/item level, the condition type will be listed.

8. Mandatory:

· This indicator specifies that particular condition type is mandatory in the pricing procedure.

· If we check the box, then in VA01 at the header/item level in the conditions tab, if we delete the value in the condition type and try to save the document then system will not allow us to do it and throws an error.

· If we uncheck the box, then in VA01 at the header/item level in the conditions tab, if we delete the value in the condition type and try to save the document then system will allow us to save it, without giving any error.

· Mandatory check box should be checked in condition types which are compulsorily required in pricing procedure. Ex.: PR00, MWST.

· If the condition type is checked with mandatory option, then value should be maintained for that condition type, otherwise the system will not allow the user to process the document.

9. Statistical:

· This indicator if it is activated will not allow the value of the condition type to be taken into net value calculation.

· It is used only for information purposes only.

· This indicator causes a surcharge or discount to be set in the document statistically (that is, without altering the value).

· This is commonly used for condition types

SKTO - Cash Discount

VPRS - Cost (Moving average price/Standard Price).

10. Print:

· The value of this field specifies whether line item can be printed or not in the sales document and at what level it is to be printed.

11. Subtotal:

· The value of this field determines where the values of subtotals to be captured i.e. in which table and which field.

· Controls whether and in which fields condition amounts or subtotals (for example, a customer discount or the cost of a material) are stored.

· If the same fields are used to store different condition amounts, the system totals the individual amounts.

· These condition amounts or subtotals are used as a starting point for further calculations. You may, for example, want a subtotal of all the discounts included in the pricing of a sales order.

12. Requirement:

· It is a routine that is written by an ABAP consultant according to the business requirement.

· By defining Requirement in condition technique we can restrict the access of condition type.

· To understand the concept, we will take the example of the Rebates. Rebates are to be included during the billing document processing and not in the sales document processing. As rebates are given on the delivered quantity and not on the ordered quantity (in case of cut-off period for rebates).

· For rebates we use the condition types BO01 to BO05, and in the Requirement column we give the value 24 which is "Only in Billing Document".

· This Requirement will ensure that these condition types will appear only during the billing document processing.

· If new Requirements are to be defined we follow the procedure given below.

Go to T.Code: VOFM. - Maintain Requirements & Formulas

Click on the "Requirements" in the top menu and then click on "pricing".

We have a list of requirements, we can ask ABAP consultant to create new requirement based on the client requests.

And we assign the application type like V - Sales/Distribution etc.

14. AltCty - Condition formula for alternative calculation type:

· It is again a Routine that is written by ABAP Consultant.

· It is an alternative formula for the condition type that can be used instead of standard formulas.

· For example, let us take the Profit Margin which can be both + / - , so here this routine will help us in generating the value which can be either + or -. Profit margin is not a condition type so it cannot be classified as +ve or -ve in the V/06.

· Ex.: 950 0 Profit Margin 11.

· So we assign 11 - Profit Margin.

· If new routines are to be defined we follow the procedure given below.

Go to T.Code: VOFM. - Maintain Requirements & Formulas

·

Click on the "Formulas" and then on the "Condition Values".

We have a list of routines, we can ask ABAP consultant to create new routines based on the client requests.

And we assign the application type.

15. AltCBV - Alternative formula for condition base value:

· Formula for determining the condition basis as an alternative to the standard.

· It is again a Routine that is written by ABAP Consultant.

· It is used as a basis to calculate value of the condition type instead of using it from the "FROM" column.

· Ex.: Freight - KF00.

· Freight is calculated based on weight, volume etc. and not on the base price. In pricing there is no entry of weight from which the value can be referred like we do for discounts using base price. We have to get the value from the Material master.

· In this column we can mention the value as 12 - Gross Weight or 13 - Net Weight.

· During pricing, the system will consider the value that is mentioned in this column and determine the freight based on this value.

· Suppose we have Net weight: 100 kgs and Gross Weight: 150 kgs. And if we mention 13 in this column then the Freight condition KF00 will be calculated using the weight as 100 kgs.

16. AcyKy - Account Key/ Accrls - Accruals:

· The values of the Sales Revenues, Sales Deductions, Freight Revenues, Tax Revenues, and Rebate Accruals etc. are going to be posted in the respective G/L accounts in Fi Module.

· In order to do this we assign account keys/ accruals to the different condition types based on their classification. The classification shown below.

ERB Rebate sales deduct.

ERF Freight revenue

ERL Revenue

ERS Sales deductions

ERU Rebate accruals

· For Ex.,

For all Price condition types like PR00 etc. we assign ERL - Revenue.

For all Discount condition types like K004, K005 etc. we assign ERS - Sales Deductions.

For all Freight condition types KF00 etc. we assign ERF - Freight Revenues.

For all Rebates condition types BO01 to BO05 we assign in Account key ERB - Rebates Sales deductions and for Accruals ERU - Rebate Accruals.

· This account keys and accruals are in turn assigned to respective G/L accounts. So the system posts respective values in respective G/L accounts in Fi-Co Module.



· This also one of the areas of SD - Fi Integration. SD consultants assign the account keys and Fi Consultants assign the respective G/L accounts in T.Code:VKOA.

Movement Type in sap

When a goods movement in the system, we must enter a movement type to differentiate between the various goods movements. A movement type is a three-digit identification key for a goods movement.

In this step, we can change the setting of existing movement types

When you enter a goods movement, you must always enter the movement type. The movement type has important control functions in Inventory Management. It is essential for updating the quantity fields updating the stock and consumption accounts selection of the fields used for entering documents printing goods receipt/issue slips


How to create movement types? What are the steps involved? When will you recommend a new movement type?
Companies may request a new movement type to differentiate between the inventory posting transaction. For example, 551 scrap movement type. Some company may request to have it as 551 for Internal Scrap and Z51 for External Scrap.

Copy, Change Movement Types

Assuming I want to create another movement type Z01.
Transaction OMJJ
Select the standard movement type 201
Click copy, then overwrite the 201 with Z01
Click the Enter button, then click Copy all
Select the new movement type Z01
On the left hand column screen, click Reversal/follow-on movement
Fill in the reversal movement type

For the rest of the options, you can leave it alone or change it depending on your requirement

Movement Type and GL Account Determination

Any report to show which account with what movement type? As we have too many movement type with different account, we want to download it from system and check.

In transaction OMWB (it require to input material no.), go to the simulation mode, then in menu Simulation --> Go to Report. There, you can give the plants, valuation classes and movement types and execute the report. Then you can download it to excel and analyze.

or

In the initial screen input the plant, material number and movement type and then go to simulation --> report. It will take you to simulation of automatic account assignments : Inventory Management which is independent of materials and there you can get the desired report.

Account no. with movement type

Different materials will use different accounts during movement. This is defined by the Valuation Class the material is assigned to. Also, movement definition also differs with the type of movement, i.e., a consumption on a production order has a different movement than a consumption on a sales order. These movements are therefore linked to Transaction/Event Keys, which are the accounting reflection of the movement.

Call transaction OMWN, Account Grouping for Movement Types. This table will provide you with the Transaction/Event Keys for the movement. Withine a movement type, these will differ based on the movement, consumption type, etc. The tables behind this are T156X and T156W.

With this Transaction Key information, read the table T030 (OBYC) using the Val Class and the Chart of Accounts to get the GL Accounts.


How to find out how G/L account is determined with respect to movement type for various material types?

G/L a/c is decided not only by Movement type, but also material master/plant/type of transaction(transaction key). Movement type in OMJJ is contains transaction key / Account modifier which is the link for GL a/c.


In material master we maintain valuation class. Hence when we do let us say GR for Purchase order(101), the G/L account is decided as below:


Let us say movement type 101

Account modifier = space

Check in OBYC

As you are aware for any transaction there will be +ve and -V entry in GL a/c

Which a/c has to be -ve and which has to be + is decided by posting key depending on transaction. Hence When we do GR...Stock a/c will be +, GR/IR will be -Ve and any price difference(if price control is -S) will be posted to price difference account.

Inventory posting is done through BSX

Price difference will goto PRD

GR/IR will goto WRX

In OBYC, check the transaction BSX, for a given Chart of A/c, for a given valuation modifier(it is nothing but plant grouping) and valuation class, you can see the G/L account. This data is available in table T030


You can see the posting key for debit and cr. That means when we do 101, then Stock will be credited and that posting key is used, if you do reverse GR-102, then same stock a/c will get debited with that posting key


For the transaction PRD, you will get addition to the above, one more column General modifier, this is nothing but the account modifier in OMJJ for that movement type, i.e. Same transaction i.e. GR, if i define a different account modifier, I can change the G/L account so that new movement type PRD (variance) can be collected at different G/L account.


Like that WRX, in which it is maintained at client level no a/c modifier, no valuation class etc...that means GR/IR account determination will not depend on movement type/material/plant etc.