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
Similar Messages
-
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 RanpuraHi 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 -
What are the Optimization Techniques?
What are the Optimization Techniques? Can any one send the one sample program which is having Good Optimization Techniques.
PhaniHi phani kumarDurusoju ,
ABAP/4 programs can take a very long time to execute, and can make other processes have to wait before executing. Here are
some tips to speed up your programs and reduce the load your programs put on the system:
Use the GET RUN TIME command to help evaluate performance. It's hard to know whether that optimization technique REALLY helps
unless you test it out. Using this tool can help you know what is effective, under what kinds of conditions. The GET RUN TIME
has problems under multiple CPUs, so you should use it to test small pieces of your program, rather than the whole program.
Generally, try to reduce I/O first, then memory, then CPU activity. I/O operations that read/write to hard disk are always the
most expensive operations. Memory, if not controlled, may have to be written to swap space on the hard disk, which therefore
increases your I/O read/writes to disk. CPU activity can be reduced by careful program design, and by using commands such as
SUM (SQL) and COLLECT (ABAP/4).
Avoid 'SELECT *', especially in tables that have a lot of fields. Use SELECT A B C INTO instead, so that fields are only read
if they are used. This can make a very big difference.
Field-groups can be useful for multi-level sorting and displaying. However, they write their data to the system's paging
space, rather than to memory (internal tables use memory). For this reason, field-groups are only appropriate for processing
large lists (e.g. over 50,000 records). If you have large lists, you should work with the systems administrator to decide the
maximum amount of RAM your program should use, and from that, calculate how much space your lists will use. Then you can
decide whether to write the data to memory or swap space. See the Fieldgroups ABAP example.
Use as many table keys as possible in the WHERE part of your select statements.
Whenever possible, design the program to access a relatively constant number of records (for instance, if you only access the
transactions for one month, then there probably will be a reasonable range, like 1200-1800, for the number of transactions
inputted within that month). Then use a SELECT A B C INTO TABLE ITAB statement.
Get a good idea of how many records you will be accessing. Log into your productive system, and use SE80 -> Dictionary Objects
(press Edit), enter the table name you want to see, and press Display. Go To Utilities -> Table Contents to query the table
contents and see the number of records. This is extremely useful in optimizing a program's memory allocation.
Try to make the user interface such that the program gradually unfolds more information to the user, rather than giving a huge
list of information all at once to the user.
Declare your internal tables using OCCURS NUM_RECS, where NUM_RECS is the number of records you expect to be accessing. If the
number of records exceeds NUM_RECS, the data will be kept in swap space (not memory).
Use SELECT A B C INTO TABLE ITAB whenever possible. This will read all of the records into the itab in one operation, rather
than repeated operations that result from a SELECT A B C INTO ITAB... ENDSELECT statement. Make sure that ITAB is declared
with OCCURS NUM_RECS, where NUM_RECS is the number of records you expect to access.
If the number of records you are reading is constantly growing, you may be able to break it into chunks of relatively constant
size. For instance, if you have to read all records from 1991 to present, you can break it into quarters, and read all records
one quarter at a time. This will reduce I/O operations. Test extensively with GET RUN TIME when using this method.
Know how to use the 'collect' command. It can be very efficient.
Use the SELECT SINGLE command whenever possible.
Many tables contain totals fields (such as monthly expense totals). Use these avoid wasting resources by calculating a total
that has already been calculated and stored.
These r good websites which wil help u :
Performance tuning
http://www.sapbrainsonline.com/ARTICLES/TECHNICAL/optimization/optimization.html
http://www.geocities.com/SiliconValley/Grid/4858/sap/ABAPCode/Optimize.htm
http://www.abapmaster.com/cgi-bin/SAP-ABAP-performance-tuning.cgi
http://abapcode.blogspot.com/2007/05/abap-performance-factor.html
cheers!
gyanaraj
****Pls reward points if u find this helpful -
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
namanHi,
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 -
VAT Configuration/ condition technique
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
namanHI
could u forward VAT configuration
my maild nsvshiva@gmail,com
Regards
siva -
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 Curreny Factoring Technique?
Hi Experts,
What is Curreny Factoring Technique? When is it used?
Thanks
~Sid
"Max Points Are Assured"Hi,
Currencies in Planning
In Profit Center Accounting, three currencies can be stored at once:
Transaction Currency
The transaction currency is the currency used for a specific transaction. You can choose a different currency from the list of valid currencies for each new transaction. The transaction currency is stored in the transaction data for Profit Center Accounting as the so-called "first currency".
Local Currency (Company Code Currency)
The controlling area currency is stored in Profit Center Accounting as the second currency.
Profit Center Local Currency
You need to set a special currency for Profit Center Accounting in Customizing for each controlling area. This currency is used in the standard reports, among other things. You can find more information about this currency in Customizing. The profit center currency is the third currency updated in the transaction data.
How Do I Plan Currencies in Profit Center Accounting?
You first plan a profit center in USD. Then you later plan the same profit center in DEM in a second planning session. This may be necessary if:
the planned costs for the profit center in a certain cost element consist of external invoices in the local currency and external invoices from abroad and
the external invoice from abroad was billed and paid abroad
The currencies which can be planned manually are defined in the Layout.
If the corresponding key figures are defined and ready for input in the planning layout, you can plan in any permissible transaction currency, the company code currency or the profit center currency. The planned amount is then immediately and automatically translated into the other currencies. Note, however, that the system can only translate into a transaction currency if you have explicitly specified a transaction currency.
If you want to want to plan data using different transaction currencies, you need to use a planning layout that contains the characteristic "Transaction currency".
Note that data can only be saved in the transaction currency if a transaction currency has been specified. Otherwise the data will only be saved in the other currencies without the transaction currency.
If you want to want to summarize data in the transaction currency, you need to use a planning layout that does not contain the characteristic "Transaction currency". You can then:
change the summarized values, in which case the changes are not updated in the transaction currency, and
add any combinations of objects that have not already been planned.
If you
enter one transaction currency, the system only displays the amounts planned in that currency. You can
change these amounts
plan in the currency specified
enter a number sign (#) to represent the value " " (no value), the system only displays those values that were planned without the transaction currency. You can
change these amounts
plan amounts without a transaction currency
specify more than one currency or all currencies (*), the system displays all the planned values. You can
change these amounts
can plan as yet unplanned combinations of your planning objects in any valid currency.
Planned currency amounts are translated using
the value date you entered in the planner profile for your area
a translation factor entered in the currency table for the exchange rate type entered in the planner profile
You will find further information about the currency table and currency translation in the documentation FI Configuration and Organization.
Transfer Pricing Using the Conditions Technique
The term "transfer pricing" is used to describe the calculation of prices for internal exchanges of goods between profit centers. Conditions are the individual steps carried out during price calculation. When a goods movement takes place between two plants, the price can depend on a number of factors, such as the material involved, the sender plant, the profit center, the partner profit center, and so on. The information on these variable factors is stored as master data in the form of condition records. There the transfer price can be defined as a fixed price or a percentage increase or reduction.
This section describes the steps necessary to define transfer prices. You define these transfer prices in Customizing. There you will also find a detailed description of how to proceed.
Define condition tables, which you use to store condition records for each condition type.
Here you define the price dependencies for transfer prices. You can make the transfer price found dependent upon a combination of fields. For example, if you want your transfer prices to be defined for a combination of material and partner profit center, you need to define a condition table that contains these key fields. The condition records then contain the individual prices for each combination of material and profit center. You maintain the condition records when you define the individual condition types.
Define access sequences that the system should use to search for valid condition records.
An access sequence is a search strategy that the system uses to find valid data for certain condition tables. Each access sequence consists of one or more steps, which the system processes in the order specified. The order determines where the system should look first for a valid condition record. You can specify an access sequence for any condition type for which you create condition records.
Define condition types for all the pricing elements (fixed amounts, markups and markdowns) that occur in your daily business operations.
In Profit Center Accounting, a condition type represents a component of a transfer price. You can define condition types for every type of fixed price, markup or markdown that occurs in your internal goods movements. If you define a percentage markup or markdown as a condition type, you also need to define another condition type to serve as the basis for this percentage. This can be a price stored in the material ledger. The relationship between these two condition types is then defined in the pricing procedure.
In some condition types you need to specify an access sequence. In this way you determine which fields the system should use to search for a valid condition record.
Define condition records that determine the amount or percentage to be applied for each set of values in the condition table (such as "fixed price of USD 100.00 for material 01, profit center ABC, and plant 0001").
You can maintain condition records directly from within the definition of the condition type. Or you can define them from the application menu by choosing Master data ® Transfer prices ® Conditions. It is also possible to copy existing condition records to create new ones. This is especially useful if you want to change the currency of the condition record. You can maintain condition records either in Customizing or in the application menu, under Master data ® Transfer prices.
Define a pricing procedure to group together condition types and determine how they relate to one another.
In addition to the selection and order of condition types, a pricing procedure determines
which subtotals should be calculated
what base value the system should use for calculating percentage markups or markdowns
what conditions must be met in order for a certain condition type to be calculated
The base value for markups and markdowns can be either a fixed price or a value from the material ledger. Using a routine supplied in the standard R/3 System, you can have the system read the legal, group, or profit center price from the material ledger and calculate the markup or markdown on this basis.
Define condition exclusions, which let you determine which condition type should be used in a given situation.
In transfer pricing for goods movements, it often happens that a number of different condition records are valid. Using condition exclusions, you can compare conditions with one another and use, for example, the most favorable price for the partner profit center.
For different condition exclusion methods are available:
· The most favorable condition in an exclusion group
· The most favorable condition record for a condition type
· The most favorable condition among different exclusion groups
· Exclusion of those conditions in an exclusion group when a condition type that belongs to another exclusion group appears
Define transfer price variants, which let you specify which pricing procedures are relevant for actual data and which for plan data.
To valuate different datasets, such as plan and actual data, using different conditions, you can define variants with an assignment to a specific pricing procedure. The system processes the specified procedures in order until it finds a valid transfer price.
In transfer pricing for goods movements, only actual data is valuated (variant 000). However, you can also create additional variants if you want to calculate plan prices on the basis of pricing data.
Define pricing reports, which determine the structure of lists of conditions.
A pricing report lets you analyze condition records according to certain criteria and define the structure of these lists. You can define pricing reports either in Customizing for Profit Center Accounting or in the application menu, under Master data ® Transfer prices ® Pricing reports.
Regards -
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
JinoHi 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. -
What is the best technique for resetting a view?
I was wondering what is the best technique for resetting the initial state of a view?
I am creating a form and want to provide a reset button for the user. I could write an initialize() method that my action handler calls, but I am wondering if the framework already provides this functionality in a more elegant way.
If I write an initialize method, then I have to manually populate my fields with my context mappings in my initialize() code to mimic what happens automatically by the framework the first time the view is called. This seems prone to error since this is duplicating the mapping logic.
MichaelHi,
Even though it boils down to the same logic, for consistency sake it is good to have the initialization logic coded in the inbound plug method and then to call the outbound plug on reset.This make more sense when you have multiple navigation possible to the same view through multiple inbound plugs.
Else, have an initialization method.
PS: check whether the reset() method of IWDContext make sense. This is helpful when you have remove dynamically added nodes and attributes.
Thanks and Regards,
Sam Mathew -
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.Bylahi,
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 -
Transportation time using condition technique!!
Hi All,
Can anyone tell how transportation time is calculated using condition technique (APO)? we have defined following in access sequence for scheduling
Plant
Destination country
Spd trans. zone
Shipping Conditions
Weight group
Factory Calendar ID
Now if no transportation lane is defined between plant A and ship to party B. Then how system is going to calculate the delivery date? where do we define transportation time between A and B or how it is getting calculated?HI,
You can define a specific transporation duration in the condition technique per chracteristic (e.g. Shipto, plant, etc.).
Create new condtion records via TA /sapCND/AU11. Create a entry for TRAN and choose a access sequence. There you define a duration e.g. for a ship-to, etc.
Three options to find a transporation duration:
1. Directly from the transportation lane (TA /SAPAPO/SCC_TL1)
2. Estimated by the system if the transporation lane does not contain any duration (except if the Fix-Duration Indicator was set, note 1464309)
(The system calculates the transportation time based on the distance between the start and destination location and the average speed of the means of transport used.)
3. from the contion technique (TA /SAPCND/AU11)
(A Transportation calendar can be defined just via scheduling userexit 002 for the condition technique.)
Further details in the SAP Help Docu:
http://help.sap.com/saphelp_scm50/helpdata/en/3a/92e217b3f54a5eae7a4ac8a99e5e87/content.htm
Hope it helps.
regards,
Michael
Edited by: Michael Thinschmidt on Aug 31, 2010 3:41 PM -
What is the best technique to resize a clip and overlay it on a difficult shape, like a broken piece or mirror?
Best would be cutting a matte in Photoshop, or as Mr. Grenadier suggests, using Motion or After Effects - but here is a way to do it staying within FCP - see if this helps:
http://vimeo.com/34973575
MtD -
Help regarding Scheduling date calculation in APO using Condition Technique
Hi Team,
The below is the issue I am facing. Could you please help me regarding this?
For a material MAT1, a stock of 15 is available today i.e. on 15/05/2014 and a Planned Order of 35 is available on 01/08/2014. I have created a Sales Order of 50 today i.e. 15/05/2014 for this material with a RDD of 20/05/2014. I have maintained the LEAD and the TRAN times as 5 days and 10 days respectively. These are maintained for a particular Route. LOAD, PICK, and UNLD are 0. In the Location master, I haven't defined any Calendar. So, it has to consider all days as working without any holidays.
For the given RDD of 20/05/2014, system performs the backward scheduling and arrives at a past date of 05/05/2014(20/05/2014-5D-10D) for the MBDAT. Since this date is in the past, the system should set the MBDAT to the current system date i.e. 15/05/2014. Since PICK is 0, the Loading Date also should be 15/05/2014. Since LOAD is 0, the Goods Issue Date also should be 15/05/2014. Since LEAD and TRAN are 5D and 10D, the Delivery Date should be 15/05/2014+5D+10D=30/05/2014.
But, in the Sales Order, I am getting a different date. For MBDAT, Loading Date, and Goods Issue date, the dates are 05/07/2014. Transportation Planning Date is 25/06/2014 and Delivery Date is 01.08.2014. During the GATP check, I am getting only a partial confirmation of 15 and the planned order of 35 is not being considered.
The material is APO relevant and the Scheduling using Condition Technique is being used.
Kindly help me regarding this and let me know if I am missing anything here.
Thanks in advance for the help.
Thanks & Regards,
Srikanth.Hello Srikanth,
Let us differentiate the problem into two pieces.
1) Incorrect Scheduling
2) Future receipts not being considered.
For the second problem, future reciepts not being considered, which is on 01/08/2014, please check if your system is allowing you to go further and do the confirmation. How long is your Checking Horizon ? Is your checking horizon configured enough to go ahead and pick this reciept element to give the confirmation by creating a second schedule line ?
For the first problem, LEAD to the best of my knowledge is transportation planning time which means, the MBDAT would be shifted to the extent of the LEAD time to be able to manage the truck though the stock is available today. However, the dates mentioned by you seems to be completely different. Hence, I suggest you to take the ATP check on this line item, go to Delivery proposal screen and click on the graphical representation of the Scheduling results. There you should be able to understand how the calculation is actually happening. Perhaps, there are some calendars that are being used which you'd not be knowing ? May be the condition record has different times maintained in the condition table ? Check the condition table that the system is picking up ? May be you have maintained the route and transportation scheduling in "X" condition table, however system was able to identify a different detailed level table which satisfied the condition and due to which system got the scheduling calculated accordingly ?
May be it is a good idea to investigate this way. Hope this helps.
Babu Kilari -
What is the condition for using 'for all entries' and why?
what is the condition for using 'for all entries' and why? can any body tell the reason for this ? its a big favour of me .
regards,
ravi.hi,
for all entries is used to join two or more tables.
It is same as join but performance wise for all entries is more effective.
You can only use FOR ALL ENTRIES IN ...WHERE ...in a SELECT statement.
SELECT ... FOR ALL ENTRIES IN itab WHERE cond returns the union of the solution sets of all SELECT
statements that would result if you wrote a separate statement for each line of the internal table replacing the symbol
itab-f with the corresponding value of component f in the WHERE condition.Duplicates are discarded from the result
set. If the internal table itab does not contain any entries, the system treats the statement as though there were
no WHERE cond condition, and selects all records (in the current client).
for example:
SELECT * FROM sflight INTO wa_sflight
FOR ALL ENTRIES IN ftab
WHERE CARRID = ftab-carrid AND
CONNID = ftab-connid AND
fldate = '20010228'.
this condition, return all entries of the sflight
hen using FOR ALL ENTRIES the number of matching records is restricted to the number of records in the internal table. If the number of records in the database tables is too large then join would cause overheads in performance. Additionally a JOIN bypasses the table buffering.
So for all entries is used for filtering out the data from the two tables based on the entries in them.
Advantages:
1) For all entries avoids inner join & so the performance increases.
2) For specified values in 1 itab, if you to fetch values from other table you can use it.
3) Use of select stmt in loop is gets avoided, as u can use read statement on the the new itab. -
Hi experts in ale what is change pointers technique , how we will use ,
hi experts in ale what is change pointers technique , how we will use , & when plz explain
Hi,
Refer the Below links
[http://articles.techrepublic.com.com/5100-10878_11-1048973.html|http://articles.techrepublic.com.com/5100-10878_11-1048973.html]
[http://abapprogramming.blogspot.com/2008/01/ale-change-pointers.html|http://abapprogramming.blogspot.com/2008/01/ale-change-pointers.html]
Regards,
SB
Maybe you are looking for
-
I had a virus on my Windows Vista PC so I had to reinstall the whole system. With this I also got an upgrade to Windows 7. Now I want to use the iPod classic to put the music back on the PC. According to the explanations on Apple support you have to
-
Duplicate songs in Itunes.....
somehow my songs have all been duplicated in Itunes. how do i delete the duplicated songs without doing one at a time ?
-
T520 - Supports 2 external displays?
I was wondering if could inform me if my Lenovo T520 (Intel HD 3000 GPU) laptop supports 2 external displays (inc. internal laptop display). So the setup would be 2 LCD monitors, one using VGA (currently attached) and the second one will be connecte
-
Iphoto 11 can't read my nikon D7000 raw files, why?
I bought the latest Macbook air 13 inches and the Nikon D7000. I tried to import the raw files (NEF) from the Nikon d7000, but it show can't read the files type, or unsupported image file. It works fine with my nikon D5000, why? anyone can help?
-
Disable ICE (Interactive Connectivity Establishment) protocol in Lync 2013 via ClientPolicy
Hi, is the DisableICE clientpolicy parameter still valid in Lync 2013, or it has been deprecated since Lync 2010? Lync 2010: its listed here: http://technet.microsoft.com/en-us/library/gg398300%28v=ocs.14%29.aspx Lync 2013: its missing from here: htt