Price determination condition technique

HELLO
Please explain the above procedure with the explaination for each step and indicators
Thanks
P.S.P

Hi,
Path: IMG -- Material management -- Purchasing -- Condition -- Define price determiantion procedure.
1. Crate the condition type (Copy from the standard one)
2. Create the calcualtion schema (Pricing Procedure) using the condition type wat u have created
3. Create the schema vendor and schema purchasing organisation
4. Assign the schema pur.org to your pur.org
5. Assign the schema vendor to your vendor
6. Assign the calculation schema (Pricing procedure) to your scheam purchase org and schema vendor combination.
At the time of creating PO system will find the price based on the below steps
1. First it will search the is there any schema pur.org assigned to the pur.org
2. Then it will search is there any schema vendor assigned to the vendor
3. Then it will serach is there any Pricing procedure linked to it.
4. Then it will serach is there any Access seq assigned to that condtion
5. Then it will search the condtion record created for this condition type
6. From the condition type it will pick the price.
Regards
Karthick

Similar Messages

Fetching prices from price list without condition technique

Hi,
I have a situation where i need to create a price list of materials which will not be used in my regular sales process pricing.
I would require these prices to send the data to an external interface.
As per my understanding the price list is used to get the customer specific prices and will be used in sales processing for automatic pricing. Kindly let me know how to use the price list without using condition technique.
As i need to create a condition table, Access sequence, condition type to use the price lists, kindly suggest how to avoid the regular process and directly fetch the price of the material from the price list.
Is this possible, if so do let me know the steps.
Regards,
K.Byla

hi,
this is to inform you that,
PRICE LIST:
it is applicable for a list of Customer's which are under the same group and share same pricing requriments.
With out using Condiiton Technique we are not able to do anything.
this is one of the important field which plays a very important role in pricing determination through CONDITION RECORDS.
you can go through PRICING REPORT, even this does not give any solution to this issue.
you can go for ENHANCEMENT, by creating a Z table with the fields:
KSCHL, AMOUNT & OTHER fields into condideration.
or
use SM30 and update into the tables - which is not suggested.
please test and confirm.
HOPE THIS CLEARS your issue.
balajia

How to determine the process alias using condition technique in Transportation & Shipment Scheudling?

Dear All,
I am trying to use the functionality Transportation and Shipment Scheduling in GATP.
I would like to know that how the sytem determines the process alias using condition technique in Transportation & Shipment Scheudling?
As the Transportation & Shipment Scheduling functionality can be extended further by using the configurable process to overcome the complex scenario. But it needs that process alias should not be determined by using the condition technique.
Moreover, is it possible to use both functionality simultaneously in the system. i.e. Transportation and Shipment Scheduling using condition technique and Transportation and Shipment Scheduling using configurable process?
Thanks & Regards
Piyush Ranpura

Hi Piyush,
I have added a small overview in the SCN WIKI which shows you the two ways for the process alias determination and also here as attachment:
http://wiki.sdn.sap.com/wiki/display/SCM/Time+and+Scheduling+Functions
Yes, depending on your customizing you can use both scheduling methods in parallel. e.g. you activate CPS just for a specific ITEM category or product and/or customer and/or....what ever you want.
best regards,
Michael

The Condition for service price determination incomplete

Dear experts,
I run the System with EC&O Best Practice. Howerver, I can not enter Services on tab Service of Sales Order: Short text of Service, Quantity, UOM, Gross Price. the error "Condition for service price determination incomplete" occours when I press Enter key.
Conditions for service price determination incomplete
Message no. SE477
Diagnosis
Either the calculation schema for services does not exist or the condition types have not been defined correctly.
Procedure
Please check your Customizing settings for service conditions.
If you have not yet defined any conditions for services, you can adopt the standard SAP settings from client 0.
Please help me check this issue on the attached file.
Thank you very much.
Thanks,
Binh Tran
<Personal details shared by OP is removed by Moderator. >
Message was edited by: Jyoti Prakash

Hi All,
Thank you very much for your inputs.
I checked all the notes, 25357, 27024 and 1383066. Everything is ok in the system. and these notes explained more on the MM part not on the SD- BOS. However, still i am not able to complete the Inquiry, same error exists.
This error is in SD not in MM, while i am creating the inquiry BOS.
If any one come across it and solved it, please let me know.
Regards,
Suresh

Condition Types in Price Determination Process

Hi
Can any one explain me about in Detail about the VARIOUS TABS that work in the CONDITION TYPE of PRICE DETERMINATION PROCESS
Thanks & Regards,
Senmani.

hi
hi
control data 1 :
Condition Class is a grouping that lets you control each condition type differently.
For example, the condition type "taxes" defines that the taxes in a document must be recalculated if the country of the ship-to party changes.
Condition category (examples: tax, freight, price, cost)
A classification of conditions according to pre-defined categories (for example, all conditions that relate to freight costs).
Condition category basically identifies the type pf cost the Condition type is being used for & can be used for .
Calculation type
Determines how the system calculates prices, discounts, or surcharges in a condition. For example, the system can calculate a price as a fixed amount or as a percentage based on quantity, volume, or weight.
The calculation type can be set when generating new condition records. If this does not happen, the calculation type maintained here is valid for the condition record
Rounding rule
The rule that determines how the system rounds off condition values during pricing. The last digit will be rounded.
Example
In the standard rounding rule '_', values are rounded off according to business standards:
10.454 -> 10.45 DEM
10.455 -> 10.46 DEM
In rounding rule 'A', values are always rounded up:
10.459 -> 10.46 DEM
10.451 -> 10.46 DEM
In rounding rule 'B', values are always rounded down:
1045.9 -> 1045 LIT
1045.1 -> 1045 LIT
In this example, the currency of the condition rate is Italian Lira. The Italian Lira does not have any places after the point.
Structure condition
controls whether the condition type should be a duplicated condition or a cumulated condition.
This control is only helpful when you use bill of materials or configurable materials.
Aduplicated condition is duplicated into all assigned items.
A cumulated condition contains the net value of all assigned items.
control data 2 :
promotions
Specifies that the condition type in question is only valid for Promotions.
Use
Conditions for which this indicator has been set can only be maintained via the 'Promotion' menu - not via the Purchasing menu.
Accrual (e.g. Freight)
Indicates that the system posts the amounts resulting from this condition to financial accounting as accruals.
Use
If you mark this indicator, the condition appears in the document as a statistical condition.
Before Release 4.0 variant conditions (VA00) had to be created with the condition category 'O'
Problem: It was not possible to indicate a 'Variant condition' at the same time as 'Internal costing condition' and 'Freight'.
Solution: For this reason more indicators are being set up in 4.0 for the condition type:
'Variant condition' (KVARC)
'Internal costing condition' (KFKIV)
The characteristic values O and I for the condition category must no longer be used.
For more information, see the note 93426.
inv.list condi
Condition for invoice list
Marks the condition type as relevant for internal costing.
Quantity conversion
This field controls the quantity conversion during determination of the condition basis.
The field is only relevant for calculation rule 'C' (quantity- dependent.
It is relevant if the sales quantity unit and the condition quantity unit are identical (and is different to the basis quantity unit).
Deactivated: The condition basis quantity is converted via the quantity to the stockkeeping unit. This means that the condition quantity is determined for planned factors. This means that a change to the conversion factors in the delivery or the order are not taken into account.
Rounding errors can occur during quantity conversion.
Activated: If the sales quantity unit and the condition quantity unit are identical, the quantity of the document item is used, i.e. the actual quantity.
Condition for inter-company billing
Conditions for Internal Costing, for example PI01 and PI01 were defined before Release 4.0 by KNTYP = I (Price for internal costing).
Problem: It was not possible to indicate 'Freight condition' at the same time as 'Internal costing condition' and 'Variant condition'.
Solution: Therefore a new indicator 'Internal costing condition' (KFKIV) has been set up. You can use this to indicate a freight condition as an internal costing condition. For more information, see note 93426.
Scale :
Scale basis indicator
Determines how the system interprets a pricing scale in a condition. For example, the scale can be based on quantity, weight, or volume
Checking rule for scale rates
Indicates whether the scale rates must be entered in ascending or descending order.
Scale Type
Indicator that controls the validity of the scale value or percentage:
From a certain quantity or value (base scale)
Up to a certain quantity or value (to-scale)
Alternatively, it is possible to work with interval scales. Interval scales must be stored in the condition type, that is, the scale type "interval scale" cannot be changed in the condition record. The reason for this is technical restrictions resulting from the programming within pricing.
Formula for scale base value
Formula for determining the scale base value.
Use
You can use this formula to specify calculation methods that are not provided in the standard system.
reward points if helpful
thanks and regards
ravikant dewangan

Conditions for service price determination is incomplete.

Dear Gurus,
I am facing an error in Bill of services like "Conditions for service price determination is incomplete".In bill of services when am trying to enter the services in service entry sheet the system through the above errorr.S o can any one rspond immediately.
Thanks in advance
Rams

Hey
While creating Service PO
mainatain account assignment category
Maintain item category
Then enter the material description.
Automatically service tab will populate.
In this maintain service no ( the same can be created in AC03)
For the service maintain the conditions in ML33 or ML39 or ML45
Then create PO, The conditions will come automatically.
Regards,
Raman

Conditions for service price determination incomplete

Hi All,
While doing the VA11 through SD-BOS, I am getting the following.
Conditions for service price determination incomplete
Message no. SE477
Diagnosis
Either the calculation schema for services does not exist or the condition types have not been defined correctly.
Procedure
Please check your Customizing settings for service conditions.
If you have not yet defined any conditions for services, you can adopt the standard SAP settings from client 0.
Please let me know did you anyone got the same kind of error.
Thanks,
Suresh.

Hi All,
Thank you very much for your inputs.
I checked all the notes, 25357, 27024 and 1383066. Everything is ok in the system. and these notes explained more on the MM part not on the SD- BOS. However, still i am not able to complete the Inquiry, same error exists.
This error is in SD not in MM, while i am creating the inquiry BOS.
If any one come across it and solved it, please let me know.
Regards,
Suresh

Condition techniques/ TAX Vat

Hello Sapients
We have a sales company in Europe, and we are selling goods in multiple european union countries.
Now we have just started selling goods in couple of other EU Countries. I need to configure Tax (VAT) for those transactions. I have Tax codes that I need to create. I know I can create new tax codes using FTXP. But I need to know who what other configuration I need to do. I am not SD consultant so I do not have good idea on condition technique. We also do not have any SD person in ur team, so i need to do that.
Can somebody please send my steps on configuring this new tax codes, with some explanations.
Thank you
naman

Hi,
Steps:
Creation of pricing procedure Steps:
(1) V/03 = Create condition table
(2) V/07 = Create access sequence
(3) V/06 = Define condition type
(4) V/08 = Define pricing procedure
(5) OVKK = Define pricing procedure determination
(6) VK11 = Maintain condition records
Explanation:
in V/06 you need to create a condition type for VAT.
and Access sequence according to the requirement. and see that the same will be taken in the Condtion tables.
Add this condition type in the pricing procedure.
Maintain the condition record for the same.
FTXP: create the tax code for the same.
Pricing is the combination of creating correct pricing procedures that map the business needs and processes such as
correct pricing and discounting, and keeping to the legal requirements placed on the business, such as adhering to
the tax laws of the respective country.
A pricing procedure consists of a list of condition types in defined orders, such as price, less (u2013) discount, plus
tax. Some controls exist in the pricing procedure.
Pricing is the calculation of costs (for internal purpose) and revenues (for external purpose) by following tax class
of a particular country.
The pricing procedure is also used in account determinations. This determines the general ledger (GL) accounts to
which type prices, discounts, and taxes must be posted. The condition types in the pricing procedure are linked to an
account key. This key in turn is linked to the GL Accounts. This shows the integration between the pricing in the
invoice and the Financial Accounting (FI) Module.
Best Regards
SRI

Pricing procedure(Condition technique)

Hi All
Can someone provide me all the configuration steps in pricing procedure in MM...

Select the pricing procedure which is the standard and copy it and create our own pricing procedure.
Highlight it and double click the Control icon in the LHS screen.
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.
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.
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.
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.
Description:
System copies description of condition type from its description (V/06).
From and To:
1.From: This can be used as a base to the condition type for calculating further value.
1.{+}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.
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 un-check the box, in VA01 when we go to conditions at the header/item level, the condition type will be listed.
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.
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).
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.
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.
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.
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.
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.
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.
or
Hi,
Pricing Procedure in MM
The steps are:
SPRO->MM->Purchasing->Conditions->Define Price dertermination process
1. Define Condition Table:
2.Define Acces Sequence,
3.Define Condition Type,
4.Define Claculatin Schema,
5.Assign Calulation Schema,Acces Sequence and Condition Type,
6.Define Schema Group Of Vendor,
7. Define Schema Group Of Purchasing Organisation,
8.Assign Schema Group Of Vendor to Purchasing Organisation,
9.Assignment of Schema Group Of Vendor ,Schema Group Purchasing Organisation and Calculation Schema.
10.Assign Vendor to Schema Group Of Vendor (XK02)
11.Maintain Condition record(MEK1)
Edited by: MANI ROOPA SD/MM on Apr 17, 2008 8:44 AM

What is a condition technique?

Hai Guys,
Do help me out in getting informations about the
following.
What is a condition technique?
detailed answers or links for this pls...
Thanku
Regards
Jino

Hi,
A hierarchy of components that define data combinations designed to trigger an action.
The constellations defined by SAP and the customers are searched for according to a specific hierarchy.
The condition technique is used, for example, in pricing, account determination and messaging.
most of the saps functionalites use condition technique to get the value or determiantion of particular functionalities like price of a good , free goods, etc they all use condition technique.
it is nothing but mainataining of
1) condition records of a condition type
2)creating of condition types like PR00,K004,k005 etc
3)creating and assignning an access sequnce to a condition type
4)placing the condition types in a procedure
5)determination or assigning a procedure
all the above 5 steps constitutes as a condition technique
Please check this link also.
Regards,
Rakesh
http://www.sapscene.com/sapscene/condition.htm

Functions which uses condition technique in SD

Hai Guys,
   Do help me out in getting informations about the
   following.
pls tell the functions which uses condition technique in SD
detailed answers or links for this pls...
Thanku
Regards
Jino

Hi Jino,
ntroduction to the Condition Technique Locate the document in its
Use
This section describes the elements within the condition technique. It is organized to reflect the likely sequence of events that you go through when you implement pricing in Customizing. The standard R/3 System includes predefined elements for routine pricing activities. For example, the standard system includes condition types for basic pricing elements, such as material prices, customer and material discounts, and surcharges such as freight and sales taxes. In the case of each element, you can use the standard version, modify the standard version, or create entirely new definitions to suit your own business needs. The sequence of activities is generally as follows:
   1. Define condition types for each of the price elements (prices, discounts, and surcharges) that occur in your daily business transactions.
   2. Define the condition tables that enable you to store and retrieve condition records for each of the different condition types.
   3. Define the access sequences that enable the system to find valid condition records.
   4. Group condition types and establish their sequence in pricing procedures.
For more information about implementing and customizing pricing in sales order processing, see Customizing for Sales and Distribution.
For a more technical description of how the condition technique works, see the Business Workflow documentation for Message Control.
Elements Used in the Condition Technique
Condition Types
Condition Tables
Access Sequences
Pricing procedures
Condition Types Locate the document in its SAP Library structure
Use
A condition type is a representation in the system of some aspect of your daily pricing activities. For example, you can define a different condition type for each kind of price, discount or surcharge that occurs in your business transactions.
Example
Example of a Condition Type
You define the condition type for a special material discount. You specify that the system calculates the discount as an amount (for example, a discount of USD 1 per sales unit). Alternatively, you can specify that the system calculates the discount as a percentage (for example: a 2% discount for orders over 1,000 units). If you want to use both possibilities, you must define two separate condition types. The following figure illustrates how condition types can be used during pricing in a sales document.
This graphic is explained in the accompanying text
In the example in the preceding figure, two discounts apply to the item in the sales order. The first discount is a percentage discount based on the quantity ordered. The second discount is a fixed discount based on the total weight of the item.
Note
You determine the calculation type for a condition type in Customizing. This determines how the system calculates prices, discounts and surcharges for a condition. When setting up condition records, you can enter a different calculation type than the one in Customizing. At present all available calculation types are permitted. The field Calculation type can however not be accessed if this field is left empty. After the data release has been printed, if the field has not been completed manually, the proposal is automatically taken from Customizing. After this it is no longer possible to make manual changes.
If you use different calculation types for what are otherwise the same conditions (for example, percentage, as a fixed amount or quantity-dependent), you do not have to define different condition types in Customizing. You can set a different calculation type when maintaining the individual condition records.
Condition Types in the Standard R/3 System
The standard system includes, among many others, the following predefined condition types:
Condition type
Description
PR00
Price
K004
Material discount
K005
Customer-specific material discount
K007
Customer discount
K020
Price group discount
KF00
Freight surcharge (by item)
UTX1
State tax
UTX2
County tax
UTX3
City tax
Creating and Maintaining Condition Types
You can change and maintain condition types provided in the standard version of the SAP R/3 System or you can create new condition types to suit the needs of your own organization. You create and maintain condition types in Customizing.
To reach the condition type screen from the initial Customizing screen for Sales and Distribution:
   1. Basic Functions
      ® Pricing ® Pricing Control ® Define condition types.
      A dialog-box appears, listing the transaction options. Select the corresponding transaction for defining the condition types.
   2. In the Conditions: Condition Types view, you can change existing condition types or create new ones.
Leaving content frame
Condition Tables Locate the document in its SAP Library structure
Use
A condition table defines the combination of fields (the key) that identifies an individual condition record. A condition record is how the system stores the specific condition data that you enter in the system as condition records. For example, when you enter the price for a product or a special discount for a good customer, you create individual condition records.
Example
Example of a Condition Table
A sales department creates condition records for customer-specific material prices. The standard R/3 System includes condition table 005 for this purpose. The key of table 005 includes the following fields:
Sales organization
Distribution channel
Customer
Material
The first two fields identify important organizational data and the last two fields express the relationship between customers and specific materials. When the sales department creates a condition record for a material price or discount that is specific to one customer, the system automatically uses condition table 005 to define the key and store the record.
The following figure illustrates the connection between the condition table and the subsequent condition records.
This graphic is explained in the accompanying text
Condition Tables in the Standard Version
The standard system includes predefined condition tables and specifies them for each access in each predefined access sequence.
Creating or Maintaining Condition Tables
You can change and maintain the condition tables in the standard system. You can also create new condition tables to meet the needs of your own organization. You create and maintain condition tables in Customizing.
From the initial screen of Customizing for Sales and Distribution, you reach the condition table screens by choosing Basic functions ® Pricing ® Pricing Control ® Define condition tables. Then select the mode you want to work with (create, change, display).
Information About Fields
The fields that you choose to make up the key are called the selected fields. The fields from which you can make your selection are called the allowed fields.
Selected Fields
The preceding figure shows the fields that make up the key for condition table 005 (the table for customer/material condition records in Sales). The selected fields show organizational data, such as Sales organization.The fields Customer and Material define the relationship between a particular customer and material.
Field Catalog (Allowed Fields)
When you select fields for the key, you must choose the fields from the list of allowed fields.
Making Changes to Condition Tables
You can make limited changes to existing condition tables. For example, you can change the name of the table or the format of the fast entry screens for the condition records. (Fast entry screens are screens where you can quickly, on a single screen, create and maintain the condition records that refer to the condition table).
Format of a Fast-Entry Screen
The screen consists of header and item lines. Each item line represents a separate condition record. The header lines include the fields that are general to all item lines. When deciding on the format of the fast-entry screen, you can determine whether each field in the key appears as a line in the header or as an item line.
Changing the Format of a Fast-Entry Screen
To change the format of the Fast-Entry screen, choose F6 (Technical View) on the screen where you create or maintain a condition table.
When you determine the format, you have the following possibilities:
If you want the...
Do the following...
Field to appear as a header line
Leave the line field blank
Field to appear as an item
Mark the line field
Text for an item line to appear
Mark the text field
After you make changes to a condition table, choose F16 Generate) to regenerate the table.
Creating a New Condition Table
You can create new condition tables to meet the pricing needs of your organization. When you create a new condition table, you select a combination of fields from the list of allowed fields. The selected fields define the key for the subsequent condition records.
Before you select the fields for the key, there are two things to consider:
The sequence (or hierarchy) of the fields
Which fields you want to appear in the header and item areas of the corresponding fast-entry screens
Important Fields
In sales, the fields you should take into consideration are Sales organization and Distribution channel. The sales organization is nearly always used as a criteria in pricing, because different sales organizations often want to use their own prices, discounts, and surcharges. If you use the sales organization as a criterion in pricing, you should also use the distribution channel. If you do not want to establish different prices, discounts, and surcharges for each distribution channel, use the field anyway. In Customizing for Sales, you can use one distribution channel as a reference for all others (thereby sharing the same pricing data).
Deciding the Sequence of Fields
The order of the fields in a condition table affects the performance of the system during pricing. Two general guidelines will help you create an efficient condition table:
   1. If you select fields that are connected to the structure of your organization (for example, sales organization and distribution channel), assign the fields according to the level of general applicability: Put the most general field, for example, the sales organization in the highest position and the most specific field in the lowest.
   2. After organizational fields, place fields from the document header before those that come from the item level. (For example, Customer comes before Material)
After you have selected the fields for the key on the screen where you maintain and define condition tables, choose F16 Generate to generate the table in the system. Generation prepares the condition table for storing condition data.
Access Sequences Locate the document in its SAP Library structure
Use
An access sequence is a search strategy that the system uses to find valid data for a particular condition type. It determines the sequence in which the system searches for data. The access sequence consists of one or more accesses. The sequence of the accesses establishes which condition records have priority over others. The accesses tell the system where to look first, second, and so on, until it finds a valid condition record. You specify an access sequence for each condition type for which you create condition records.
Note
There are some condition types for which you do not create condition records (header discounts that you can only enter manually, for example). These condition types do not require an access sequence.
ExampleA sales department may offer customers different kinds of prices. The department may create, for example, the following condition records in the system:
A basic price for a material
A special customer-specific price for the same material
A price list for major customers
During sales order processing, a customer may, in theory, qualify for all three prices. The access sequence enables the system to access the data records in a particular sequence until it finds a valid price. In this example, the sales department may want to use the most favourable price for a certain customer. For this reason, it ensures that the system searches for a customer-specific price. The following figure shows how the system searches for the relevant record.
This graphic is explained in the accompanying text
Access Sequences in the Standard R/3 System
The standard R/3 System contains access sequences that are predefined for each of the standard condition types. The names of the access sequences often correspond to the condition types for which they were designed. For example, the access sequence for a material discount (condition type K004) is also called K004.
Creating and Maintaining Access Sequences
You create and maintain access sequences in Customizing. For more information, see the online Implementation Guide for Sales and Distribution.
To reach the access sequence screen, go to the initial screen for Sales and Distribution Customizing and choose:
   1. Basic Functions
      ® Pricing ® Pricing Control ® Define access sequences
Select the transaction that you want to execute (Maintain access).
Leaving content frame
Pricing Procedures Locate the document in its SAP Library structure
Use
The primary job of a pricing procedure is to define a group of condition types in a particular sequence. The pricing procedure also determines:
Which sub-totals appear during pricing
To what extent pricing can be processed manually
Which method the system uses to calculate percentage discounts and surcharges
Which requirements for a particular condition type must be fulfilled before the system takes the condition into account
Example
Example of a Pricing Procedure
If a sales department processes sales orders for a variety of foreign customers, the department can group the customers by country or region. A pricing procedure can then be defined for each group of customers. Each procedure can include condition types that determine, for example, country-specific taxes. In sales order processing, you can specify pricing procedures for specific customers and for sales document types. The system automatically determines which procedure to use.
Pricing Procedures in the R/3 System
The standard system contains pre-defined pricing procedures, which contain frequently used condition types along with their corresponding access sequences. You can, of course, modify these procedures or create your own from scratch.
Creating and Maintaining Pricing Procedures
You create or maintain pricing procedures in Customizing for Sales. For more information on creating pricing procedures, see the online Implementation Guide for Sales and Distribution.
To reach the pricing procedure screen from SD Customizing:
   1. Choose Basic Functions
   2. ® Pricing ® Pricing control ® Define and assign pricing procedures.Select the transaction that you want to execute.
Thanks&Regards,
Phani,
Points If helpful.

MIGO : Price determination

Hi all,
I got a problem when I try to do the good receipt for a purchse order in MIGO. SAP occures an error :
"Transaction cannot be posted due to errors in price determination
[X]Error during maint. of delivery costs in master conditions
Delivery cost conditions in different validity periods not identical "
What does it mean ? Where can I find the place where those validity periods are customized ?
I've already checked in the RFQ, and the period value of the delivery cost condition seems to be OK for all the costs...
Someone got another idea ?
Thanks all !

Hi Prasad,
Indeed this PO already has a GR, but this GR was cancelled.
Now when we try to do again the GR, we get that error.
But I check the PO and the delivery costs are still here. If I erase the delivery cost from the PO, I can do the GR. If I put back manually the delivery costs, I get the error during the GR.
So, do you have a solution ?
Thanks,
Mathieu

Price determination date control in Scheduling agreement (ME33)

<<Do not ask for or offer points>>
Dear SAP chams,
I have one doubt at the time of scheduling agreement creation. I am creating scheduling agreement trough t'code ME33. In the same, Select line item, go to item data, go to Additional data. Here the field Pr. Date Cat (Price Determination (Pricing) Date Control) contains the value "5" (i.e. GR date). I want to change this value. How can i change this determination ??...
Helpful answers will surely be awarded by points.
Thanks and regard,
Tarpan Vadaliya
Edited by: Matt on Feb 27, 2010 10:47 PM

Hi
Price determination category 5 cannot be change in scheduling agreement if your document type is time dependent. (See config spro>mm>purchasing>scheduling agreement>define document type. In that you will see a tick for time dependent condition)
If the config tick is removed then you can change price determination to any other option.
Regards
Antony

Price determination after historical simulation

I am confused about price determination after value at risk historical simulation run, my evaluation day is 2014.March.31, for commodity forward, the floating leg is based on price 42.17286 (the eighth shift for VaR calculation, my holding period is 10 days), which is shown in the attached picture, but my commodity price curve is showing 41.***,if I click "commodity price" under calcuation basis tab, it shows in March.31.2014, my commodity price is 41.57 USD. thus I will like to know how 42.17286 derived, is it from commodity price curve or commodity price? at which point of time? and the difference between commodity price curve and commodity price, if in March.26 , commodity price curve show 42.68, but commodity price shows 41.57, is it inconsistent?

hi,
it s really interesting issue!
this may not be the right solution but i ve tried and it worked right.
1-go to ME12 click the conditions tab on header line.
2-click the scales and click the details for scale type and choose "B" "last scale" for the scale type.
save and exit..
you ll be able to do PO-migo-and miro.
i hope it ll help.
regards.

Price Determination (Pricing) Date Control - Purchase Order

Hi,
We are exploring the Price Determination (Pricing) Date Control in the Purchase Order.
Clientu2019s requiring is, correct me if it is a wrong requirement:
We have created Tax Codes:
C2 - CST 2% valid from 01.04.2010
C3 - CST 3% valid from 01.04.2010
We have created a purchase order with Tax Code C2 - CST 2% on 30.03.2010 as we are in doing back log entries. Since the tax code is valid from 01.04.2010 only , the purchase order is not displaying the Tax Code Value .
Now we are doing the Goods Receipt on 01.04.2010, the system will not pass the entry for the CST as at time of GR, the System picks up the Tax data from the Purchase Order.
Now we want that the System should pick up the Data at the Goods Receipt, not from the Purchase Order. Some one advised me to use put GR Date in Pr. Date Cat. Under Item-> Condition Control tab. We are able to view the Pr. Date Cat by changing the Screen Layout of ME21N.
We want to know what use of the same & under what condition is, we use this.
Our suggestion:
1. We are of the view that we should create the Tax Codes with Valid Date from 01.01.2010 (not from 01.04.2010 as currently maintained)
2. Or since we are doing the back log entry, we should create all the Open Purchase Orders dated 01.04.2010.
Is this the correct way which we are suggesting?
Please note that we are dealing with Excise Materials also?
Please guide.

Thanks for the reply,
While testing the same, I also encountered the somewhat same problem.
You are suggesting that we should change the Tax Code Valid From Date.
What do mean by the follwoing:
Pricing date category "GR date" can't be set in PO if price is entered manually (with condition type PBXX). This also means manually entered conditions at Po will not be used.
Regards,

Price determination condition technique

Similar Messages

Maybe you are looking for