Controlling fields in CMD for Pricing

Hi
In Customer master data -sales area data-sales tab there are 3 different controlloing fields used for grouping customers for pricing purpose( used in V/04)
A. Customer Group
B. Price Group
C. Price List
wahat are the difference between these 3 and what could be the different scenerio in which we will have to maintain these fields.
Regards
Jyoti

Hi Jyoti,
Customer group:A definable grouping of customers for pricing or statistical purposes.For example, a customer group can be made up of wholesalers or retailers
Price group: Price groups let you apply a discount to a particular group of customers
Price list type: Price list types allow you to apply a material price in a particular currency to a group of customers. For example, you can specify a price list type that applies to all wholesale customers in one of your export markets.
One can use these fields in maintaing automatic pricing procedure.
Regds,
Rupali

Similar Messages

Mandatory Fields for IDOC ORDERS01 for Pricing Condition EDI1 to trigger

Hi ,
I'm Testing an Inbound ORDRSP using we 19 for Pricing Conditions EDI1. What are the Mandatory Fields for IDOC ORDERS01
Thanks

hello,
I think it's better to execute VA01 to create a sales order; in that way you should have an idea of mandatory fields.
Thanks.

New field (Customer group 5) to be added to the Catalog for Pricing.

Hello friends,
For the creation of a new Condition table, I require the field, KNVV-KVGR5 i.e Customer group 5 field present in Sales area data ->Extras -> Additional data in Customer master to be added to the Catalog of allowed fields since this field does not exist anywhere.
I have already gone thru the threads available on adding New field for Pricing which has an example/detailed explanation with the Item category (PSTYVV) field.
But the field I want i.e KNVV-KVGR5, is a part of Master data, so please guide me with the steps to follow to add this field in the field catalog and hence use it for creation of a new condition table.
1) Should i add this field in KOMP (i.e item) or KOMK ( i.e Header) or KOMG?
2) Should i include it in KOMKAZ or KOMPAZ?
3) Should i create this field as data element or structure and what should be the domain used?
4) For the value flow, should i use the Item -level user-exits or Header level mentioned in other threads?
Please guide for the same urgently.

Dear Friends,
I was finally able to create a new field for Cust.grp.5 i.e ZZKVGR5 and added to Catalog to be used for Pricing.
Then i faced a peculiar issue as below:
For the business requirement, we defined a new tax condition table for determination of tax rates. For this, we are using both standard and custom fields to derive the correct tax rates in sales/billing documents like below
A859: Country/Distr. Chl/Cust.grp.5/Material (Here Customer.grp 5 was added following the SAP Note: 531835)
The field was inserted in the communication structure KOMKAZ which is included in both KOMK and KOMP.
During the document processing, the pricing analysis view shows no value in the customer grp 5 field, though it is maintained for the customer used in the sales order. The code has been written in MV45 and RV60 both as guided in SAP Note: 531835. But the values are not flowing.
Solved the above problem as below:
M posting the answer to help the community for similar issue.
Also, the new field tat i had added was Customer Grp 5 field of Customer master ->Extras->Additional field and I wanted the value to flow in the ZZKVGR5 field before the Pricing for the sales order was called.
After trying all, we have finally fetched the value from KNVV-KVGR5 and got it moved to ZZKVGR5 field through ABAP coding.
After this when i select/click on Pricing for a particular item, it gets picked up correctly and properly.
Thanks to everyone for their valuable guidance and help.
Regards to all.

Fields in sales order item level for pricing

01.02.2011
Hi friends,
I have a requirement wherein i need at least 3 additional fields at the item level in the Sales Order for pricing determination i.e i want this field to be used in the condition table. Since these fields should have list of values also, I find the fields Material group1, material group2 and material group3 ideal ones. I wont be using this field in the material master but inputting some data in these fields through development at the sales order level. How can i get these fields in the catalog? Please suggest.
Regards,
Uday

The following communication structures are relevant in pricing:
KOMK (pricing communication header)
KOMP (pricing communication item)
KOMG (allowed fields for condition structures)
For technical reasons, communication structure KOMG is used. It combines the fields from KOMK and KOMP that are relevant for pricing in the standard system and are offered in the field catalog of condition tables. If you want to use a new field in the field catalog, you must add the field to KOMP or KOMK in the following INCLUDES:
header data in INCLUDE KOMKAZ in KOMK
item data in INCLUDE KOMPAZ in KOMP
When you use INCLUDES, the field is automatically added to KOMG and the field catalog.
The routines for assigning values to the new fields in order processing are found in member MV45AFZZ. Use the following user exits:
USEREXIT_PRICING_PREPARE_TKOMK (header fields)
USEREXIT_PRICING_PREPARE_TKOMP (item fields)
The routines for assigning values to the new fields in billing are found in member RV60AFZZ. Use the following user exits:
USEREXIT_PRICING_PREPARE_TKOMK (header fields)
USEREXIT_PRICING_PREPARE_TKOMP (item fields)
Examples for using new fields in pricing
Example 1
In the first example, parts of a document field are to be used in pricing. You want to use the first three digits of the product hierarchy (PRODH) for pricing, for example. Proceed as follows:
1. Check the data elements in the standard system.
2. Since there is no such data element you have to create the new data element ZZPRODH1. Also create a domain with the length "3" and the data type "CHAR" for the new data element.
Remember that new data fields must start with the letters "ZZ" or "YY", since SAP reserved these letters to protect them from being overwritten during a release upgrade.
3. Check whether the product hierarchy (PRODH) is found at header or at item level.
In table VBAP, document field PRODH is defined as an item field.
4. Integrate the field name ZZPRODH in the communication structure KOMP using the INCLUDE KOMPAZ and allocate the data element PRODH to it.
5. Activate the structure.
6. Check in which table the field PRODH exists.
The field is in table VBAP (sales document: item data).
7. Assign a value to the new field in the FORM routines for sales order processing and billing using the appropriate user exits:
In sales order processing the user exit is found in member MV45AFZZ. The complete statement is:
FORM USEREXIT_PRICING_PREPARE_TKOMP.
MOVE VBAP-PRODH(3) TO TKOMP-ZZPRODH.
ENDFORM.
The routines for assigning a value to the new fields in billing are found in member RV60AFZZ. The statement is as follows:
FORM USEREXIT_PRICING_PREPARE_TKOMK
MOVE XVBRP-PRODH(3) TO TKOMP-ZZPRODH.
ENDFORM.

Coding for giving 'find' functionality to a table control field

hi.
i want to give find functionality to a table control field.when ever i will select one field & i will enter 'find' icon one modal screen comes.when i will enter one value of that field it will highlight that field in the table control.

Hi,
FIND IN [SECTION OFFSET <off> LENGTH <len> OF] <text>
 [IGNORING CASE|RESPECTING CASE]
 [IN BYTE MODE|IN CHARACTER MODE]
 [MATCH OFFSET <o>] [MATCH LENGTH <l>].
The system searches the field <text> for the pattern . The SECTION OFFSET <off> LENGTH <len> OF addition tells the system to search only from the <off> position in the length <len>. IGNORING CASE or RESPECTING CASE (default) specifies whether the search is to be case-sensitive. In Unicode programs, you must specify whether the statement is a character or byte operation, using the IN BYTE MODE or IN CHARACTER MODE (default) additions. The MATCH OFFSET and MATCH LENGTH additions set the offset of the first occurrence and length of the search string in the fields and <l>.
Regards,
Priya.

Repricing of Custom Field used in Key combination for Pricing

Hi,
we have created a custom field and this field is being used in the Key combination for Pricing. For standard fields we all know that the pricing condition is repriced once the value of the key field is changed in the document automatically (not manual update)
The problem with this having the custom field in the Key combination is that when this fiel value is changed in the document the condition is not repriced automatically. We need to Do the price update manually for determining the new condition value.
Request you to help in solving the issue. Do explain the things to be carried out for automatic pricing for the Custom fields added.
Thank you in advancd.
Regard
Kula

Hi Kulasekar,
I think you have to implement Badi CRM_COND_COM_BADI, update communication structure with updated value from transaction should do reprice.
Hope this helps!!!

Crm mapping field for pricing

Hy Guy
In order to do download of pricing from erp to crm i have used the sap note 514952 - Download of customer-specific tables
I have a problem with a field MATKL that in CRM is ZMATKL; when i run the condition objet to update the custom table with this field, I don't have the complete field. In SAP the field is more long (mp00001).
I have other custom fields and I don't have this problem; the others fields are copied correctly.
Please, have you any advice to give me?
thanks in advance

Hi Valentina,
Not sure but the step 2 in the note says that the field name entered for remote field should be the field in structure CND_MAPT_ACS_REM , which you have set as MATKL and in structure you added ZMATKL which is wrong. Anyhow I think the field in the structure CND_MAPT_ACS_REM should be named as MATKL( note specifically speaks, the field name be the same as R/3 field name ) because in CRM field catalog you must have already created a new field as ZMATKL which is on CRM side.
component: R/3 field name.
component type : R/3 equivalent data element.
LFld: Field name you entered into field catalogue in step 2 .
FFld: R/3 field name you entered into structure CND_MAPT_ACS_REM_CUST in step 1.
May be this suggestion be helpful to you.
/Hasan

How do i display input values (POV) for a table control field

Hi guyz !
How do i display input values (POV) for a field in table control,
i mean when user presses F4 on a table control field.
Please help.
Thanks
jahan

PROCESS ON VALUE-REQUEST( F4 ) statement
Code to demonstrate how to perform a manual value help(F4) on a particular field using the PROCESS ON VALUE-REQUEST statement and how to return values back to a table control on the screen. For standard screen fields simply move the value to the appropriate screen field name.
* Screen flow logic........
PROCESS BEFORE OUTPUT.
*MODULE PBO_MODULE.
PROCESS AFTER INPUT.
*MODULE PAI_MODULE.
PROCESS ON VALUE-REQUEST. "F4
FIELD EKPO-EBELP MODULE help_ekpo.
MODULE help_ekpo INPUT.
**Transport values to table dynpro/screen table control
DATA: l_stepl LIKE sy-stepl,
        l_indx LIKE sy-stepl.
DATA: dynpfields        LIKE dynpread OCCURS 5 WITH HEADER LINE.
* Adjust for scroling within table control
CALL FUNCTION 'DYNP_GET_STEPL'
    IMPORTING
      povstepl        = l_stepl
    EXCEPTIONS
      stepl_not_found = 0
      OTHERS          = 0.
l_indx = tc_ekpotable-top_line + l_stepl - 1.
          "tc_ekpotable should already have been declared
REFRESH dynpfields.
CLEAR   dynpfields.
dynpfields-fieldname = 'EKPO-EBELN'.
dynpfields-fieldvalue = '00010'   "wa_ekpo-ebeln.
dynpfields-stepl      = l_stepl.
APPEND dynpfields.
dynpfields-fieldname = 'EKPO-EBELP'.
dynpfields-fieldvalue = '00020'   "wa_ekpo-ebelp.
dynpfields-stepl      = l_stepl.
APPEND dynpfields.
CALL FUNCTION 'DYNP_VALUES_UPDATE'
    EXPORTING
      dyname     = 'SAPLZZ_EKKO'    "Program name
      dynumb     = '0100'           "Screen number
    TABLES
      dynpfields = dynpfields
    EXCEPTIONS
      OTHERS     = 0.
ENDMODULE.                 " help_ekpo INPUT
reward points if it is usefull ..
Girish

Step by Step process for Pricing in SAP

Hello Experts,
Can any one please send me the documentation for whole process of pricing in SAP , So that it will explain me how it works in SAP.
I don´t need the steps for the configuration.
Thanks

Hi
Pricing and Conditions
The term pricing is used broadly to describe the calculation of prices (for external use by customers or vendors) and costs (for internal purposes, such as cost accounting). Conditions represent a set of circumstances that apply when a price is calculated. For example, a particular customer orders a certain quantity of a particular product on a certain day. The variable factors here - the customer, the product, the order quantity, the date - determine the final price the customer gets. The information about each of these factors can be stored in the system as master data. This master data is stored in the form of condition records.
refer link below
<a href="http://www.sap-basis-abap.com/sapsdlog.htm">PRICING</a>
PRICING:
Pricing is the combination of creating correct pricing procedure that map the business needs & processes, such as correct pricing & discounting, & keeping to the legal requirements placed on the business, such as adhering to the tax laws of the country.
SPRO- IMG- SD- Basic Functions- Pricing- Pricing Control
Create Condition Table: V/03, V/04, V/05
Define Access Sequence: V/07
Define Condition Types: V/06
Define & Assign Pricing Procedure
Maintain Pricing Procedure: V/08
Define CuPP: OVKP
Define DoPP: OVKI. The DoPP indicator is used to determine pricing in conjunction with the sales area & CuPP.
Assign DoPP to Order Types & Billing Types: OVKJ & OVTP
Define Pricing Procedure Determination: OVKK
Create Condition Table: V/03, 04, 05
Put the most general field for e.g., Sales Orgn in the highest position & the most specific field in the lowest. After organizational fields, place fields from doc header before those that come from item level (customer comes before material).
Sales Orgn, Distbn Channel, Div, Cust, Mat: Customer Specific Price
Sales Orgn, Distbn Channel, Div, Price List Type, Mat: Price List
Sales Orgn, Distbn Channel, Div, Mat: Material Price.
Maintain Access Sequence: V/07
Go to new entries, define 4-digit acc seq. Select acc seq, go to Accesses and place the cond tables and check exclusive indicator (which determines that if a cond record is successfully found, the system will stop searching further). Select each cond table and go to Fields.
There are some cond types for which you do not create cond records (header discounts that you can only enter manually). These cond types do not require an access sequence.
Define Condition Type: V/06
They are used in the pricing procedure to define how the cond is going to perform, such as either a %tage or a fixed amount. The cond type can be automatic or it can allow manual changes. Copy the required cond type and rename. Then assign acc seq to cond type.
If you use different calculation types for what are otherwise the same conditions (for e.g., %tage, as fixed amt, qty dependent), you do not have to define different cond types in customizing. You can set different calculation type when maintaining cond records.
Functionality of Condition Types:
Access Sequence
Condition Class: surcharge & discounts or prices
Plus/Minus: -ve, +ve or both
Calculation Type: fixed amt, %tage, qty, wt, voln
Rounding rule: commercial, round up and round down
Group Cond
Manual Entry: whether manual or automatic entry has priority
Header Cond: after entering the header cond type click on the button activate. The cond amt of the header conditon is copied as it is to all the line items in the doc.
Item Cond
Amount/ Percent: check & u can change the amount or % for the cond type during data processing
Delete: check & the cond record may be deleted from the doc.
Value: check & the value of the cond type can be changed during data processing
Calculation Type: check & the cal type can be changed during doc processing
Valid from & to
Scale Basis: determines how the system interprets a pricing scale in a cond, for e.g., the scale can be based on qty, wt, voln
Check Value: indicates whether the scale rates must be entered in ascending or descending order.
Define and Assign Pricing Procedure: V/08
A pricing proc consists of a lists of cond types in a defined order, such as price less discount plus tax. Go to new entries, define 6-digit pricing proc with descp. Select the 6-digit pricing proc and go to Control Data, you will be faced with an empty structure.
Step: the no that determines the sequence no of a cond type with in a procedure
Counter: second mini step with in an actual step
Conditon type: specify the cond type
From & To: if you specify the ref steps in these fields, the cond values of the 2 steps specified and steps in between are totaled
Manual:
Mandatory: whether a cond type is mandatory when system carries out pricing
Statistical: the value represented in this step will not alter the overall value
Print: which cond types should be printed on a doc (order confirmation, invoices)
Subtotal: controls whether & in which fields the cond amts or subtotals are stored
Requirement: for a cond type to be executed in the sales doc the requirement specified here must be satisfied. (It is a gateway)
Alternative Calculation Type: alternative formula to the formula in the std system that determines the cond. In the std SAP system for the cust expected price EDI1, the alt cal type is 9, which means it contains a routine with a logic which states that the difference between the customer expected price & the net value is zero.
Alternative Cond Base Value: alternative formula for determining the cond basis (amt to which the discount or surcharge in a scale refers)
Account Key: this field enables the system to post the sales value to different G/L accounts. ERL: sales revenues, ERS: sales deductions, ERF: freight revenue.
Accruals: this is exclusively for rebate cond types BO01 & BO02. Key, which identifies various types of G/L accounts for accrual postings.
TAX: MWST
Tax is calculated on the following parameters:
Plant
Ship to party region
Customer tax classification
Material tax classification
Pricing Procedure Determination: OVKK: Determination Rule
Before one can proceed with the determination rule, one needs to maintain the CuPP & DoPP. One needs to assign a single character alphanumeric key with a short descp. Then assign the DoPP to the sales doc types. This will ensure that for e.g., all sales orders created using order type OR, which has been assigned a DoPP of 1, will all use the same pricing proc if created in the same sales area & with the same CuPP. In some instances, you may not want to have the same pricing proc for a sales doc, as you may want in a billing doc. For this reason, you may allocate a different DoPP to a billing doc.
Do not forget to assign the CuPP indicator to your CMD in the Sales Screen
Sales Orgn + Distbn + Division + CuPP indicator + DoPP indicator = Pricing Procedure
To Create own Sales Doc Types:
SPRO- IMG- Sales Doc- Sales Doc Header-
Define sales doc types: VOV8. Copy std order type& rename
Assign Sales area to Sales Doc Types:
Combine sales orgn
Combine Distbn channel
Combine division
Assign sales order types to permitted sales area
To create Price List Types:
SPRO- IMG- SD- Basic Functions- Pricing- Maintain Price Relevant Master Data:
Define price list category for customers: OVSI: assign to CMD sales area screen in price list type field, in sales tab page in pricing and statistics section.
Define pricing group for customers: OVSL: assign to CMD sales area screen in price group field, in sales tab page in pricing and statistics section.
Define material group: OVSJ: assign to sales orgn 2 view of MMR in Mat Pricing Group Field.
2 digits character key with description
Cond Type Description Cond Class Calculation Type
BO01 Group rebate Exp reimbursement Percentage
BO02 Mat rebate Exp reimbursement Qty (fixed)
BO03 Cust rebate Exp reimbursement Percentage
BO04 Hierarchy rebate Exp reimbursement Percentage
BO05 Hierarchy rebate / Mat Exp reimbursement Percentage
BO06 Sales Independent Rebate Exp reimbursement Fixed amount
EDI1 Cust Expected Price Prices Quantity
HB00 Discount (value) Discount / Surcharge Fixed amount
HD00 Freight Discount / Surcharge Gross weight
K004 Material Discount / Surcharge Qty / absolute
K005 Customer / Material Discount / Surcharge Qty / absolute
K007 Customer discount Discount / Surcharge Percentage
K020 Price group Discount / Surcharge Percentage
K029 Material Pricing Group Discount / Surcharge Absolute discount by wt
K030 Customer/ Mat Group Discount / Surcharge Percentage
K031 Price Grp/ Mat Pr Group Discount / Surcharge Percentage
K032 Price Grp/ Material Discount / Surcharge Quantity / absolute
KF00 Freight Discount / Surcharge Gross weight
NRAB Free Goods Discount / Surcharge Quantity
PI01 Inter company price Prices Quantity (fixed)
PI02 Inter company % Prices Percentage
RB00 Discount / value Discount / Surcharge Fixed amount
PR00 Price Prices Quantity
VPRS Cost Prices Quantity
RL00 Factoring Discount Discount / Surcharge Percentage
MW15 Factoring Discount Tax Taxes Percentage
SKT0 Cash discount
Customer Specific Price: sales orgn, distbn, division, customer & material
Price List Price: sales orgn, distbn, division, price list type & material
Material Price: sales orgn, distbn, division & material
Customer discount: sales orgn, distbn, division & customer
Customer material discount: sales orgn, distbn, division, customer & material or sales orgn, distbn, customer & material.
Material discount: sales orgn, distbn, division & material or sales orgn, distbn & mat.
Condition Records:
Condition records allow you to store & retrieve pricing data in the system. Pricing elements are generally managed at the sales orgn & distbn channel level. There fore you always have to specify organizational level when creating cond records. In the case of cond records for price groups, freight charges, & cust specific prices & discounts you must also enter the division. As a result, you can create conditions according to product groups with these price elements.
Pricing Elements in Sales Order:
Price: the basis of pricing during sales order processing is the gross price of the mat. The system selects the most specific record- the cust specific price. If it does not exist, the system looks for price list type. If it also does not exist then system takes the basic material price. You can define price list types by customer groups (wholesale or retail) or by currency (price lists for each foreign country dealt with)
Surcharge & Discounts:
Freight Costs: you can create cond record either based on: the first part of the inco term (for e.g. FOB) or on the combination of part 1 & 2 (for e.g. FOB & Boston). There are 2 predefined freight conditions
o KF00: applies to each item in a sales doc.
o HD00: applies to entire document.
Sales Taxes:
Prerequisites for Automatic Pricing:
Necessary data must be maintained in MMR & CMD:
Material Master Data: the price related fields can be found in sales orgn 1 & 2.
Tax Classification
Price Material: you can specify another material as ref for pricing info
Material Group: defines a group of materials for which you want to apply the same cond record.
Cash Discount: whether or not mat qualifies for cash discount
Customer Master Data: the price related fields appear on sales data screen.
CuPP: specify the pricing proc for a customer
Price List: Allow you to apply a mat price in a particular currency to a group of customers e.g. wholesale customers.
Price Group: price group lets you apply a discount to a particular group of customers.
Tax Classification: billing tab page.
HEADER & ITEM CONDITIONS:
The standard system includes cond types that you can apply at only the header level, the header conditions. Cond types that you can only use for items are called item conditions. There are some cond types that can be used at both header & item level:
RA01: percent from gross
RB00: absolute discount
RD00: weight discount
Header Conditions: you cannot create cond records for it; it is entered manually in order processing. Automatic pricing does not take place for them.
HA00: percent discount
HB00: absolute discount
HD00: freight
HM00: order value
Item Conditions: in the std SAP most cond types are defined as item conditions:
K004: mat discount
K005: cust/ mat discount
K007: cust discount
PR01: mat price
KF00: freight
Distribution between Header & Item:
Header conditions apply to all items in the doc & are automatically distributed to all the items. It can be either percentage or an absolute amount.
If you enter a header cond that is based on a percentage (e.g., a dis of 2% ) the system automatically applies this percentage to all the items in the doc.
If the header cond is an absolute amount, there are 2 ways in which the system can distribute the amount among the items in the doc:
Distributed proportionally among the items
Amount entered at header level is duplicated for each item.
You control the distribution of absolute header condition in the Group Price Field per cond type.
HB00: header discount distributed as percentage because it is marked as a header cond & group condition. The system distributes the amt proportionally among the various items, in this case according to the value of the items. The distribution of an absolute header cond need not be based on value. For e.g. you can specify in customizing for sales that the distribution is based on weight & volume of the different items. You can specify the basis of distribution in the Alternative Cond Base Value field in the pricing screen.
RB00: assigns the header discount to each item identically, because it is only marked as header condition.

REWARD IF HELPS
Message was edited by:
SHESAGIRI GEDILA

Now to define new formulas for pricing?

can any one please tell me a business scenario where one needs to define a new pricing formula, and how can one can do that in the system?
points will be rewarded immediately.
thanks
PR

Hi,
As our friends suggested you can create new formulas for pricing with the Transaction code VOFM.
Process is use VOFM(Transaction code)------>in top menu you can see Formulas, select appropriate option in Formulas lke.. Condition base value, Condition Value etc.,
Please go through detail information:-
Formulas are represented as FORM routines. They are used in pricing and influence the determination of prices according to predefined rules. You can specify them in pricing control. The following groups of formulas exist:
Scale base value
The scale base value includes FORM routines which determine the scale base value according to criteria that are not defined in the standard system. You enter the scale base value in the Scale formula field. A formula for the scale base value can define, for example, that partial quantities are taken into account.
Condition base value
Formulas for the condition base value take into account criteria not defined in the standard system. You enter them in the Alternative formula for condition base value field in the pricing procedure. A formula for the condition base value can define, for example, that the condition determination is based on net value or volume.
Condition value
Formulas for determining of the condition value include routines which determine the condition value according to criteria not defined in the standard system. You enter the formulas for the determination of the condition value in the Condition formula for alternative calculation type field in the pricing procedure. A formula for the condition value can define, for example, that the system determines the best price for the customer.
Structure of group key
Using this menu entry, you can edit routines that determine the base value for the scale value if group conditions are used in pricing. The system then calculates the base for the scale value from more than one document item. You can enter the routines in the Group condition routine field on the screen for defining condition types. A routine for the determination of the scale valuecan define, for example, that only a particular condition type is taken into acount.
Rounding rules
Using this entry, you can create and edit FORM routines that carry out a particular type of rounding in the condition record during a price change. A rounding rule could round a price that was increased by 1% to the last two places behind the decimal point, for example.
Procedure
To define your own formulas, proceed as follows:
1. First check whether you can use the formulas delivered with the standard system.
2. Either overwrite an existing formula or select a group number from the number range reserved for customer modifications (600-699) and enter the corresponding description.
3. Program the formula in the editor.
4. Activate the formula.
5. Enter a long text that describes the meaning of the formula in more detail.
6. Enter an application if you want to use the formula in a particular application area only (pricing, for example).
7. Enter the formula in the appropriate place of the control
NOTE:- to create new routine get Access key from Basis.
I hope it will help you to define formulas for pricing.
Regards,
Venkat

How does the field ABGRU-Reason for Rejection get populated in routines

Hi All,
How does the field ABGRU-Reason for Rejection get populated in routines(VOFM)?
BELNR,KPOSN,etc...fields are populated through KOMK and KOMP structures, similar way what structure is used for ABGRU?
by the time the control from VA01 comes to routine the values of VBAK and VBAP are cleared, so these structures like KOMP and KOMK are used.
Thanks in advance.

You need to add rejection reason field ABGRU as a new field to pricing field catalog (KOMG structure) through APPEND structure KOMPAZ. KOMG inherits new fields from KOMKAZ (for header level fields) or KOMPAZ (for item level fields) structures and it is not directly modified but through KOMKAZ and KOMPAZ structures
Since VBAP-ABGRU can vary from item to item, add it to item pricing communication structure KOMPAZ in SE11. Once KOMPAZ is added with new ABGRU field and activated it will automatically appear in pricing field catalog (KOMG)
Afterwards the ABGRU field will then start to appear in the field catalog where you can create condition table (V/03) including the ABGRU as a field. Once done the rest is assigning the condition table to access sequence which is in turn assigned to the relevant condition type that you want to price based on partner function (all under IMG -> SD -> Basic functions -> Pricing -> Pricing control)
In the pricing user exit userexit_pricing_prepare_tkomp in include MV45AFZZ, you will need a few lines of coding to fetch VBAP-ABGRU for the item and pass it to tkomp-abrug field. This will then be used by system to read the new condition table that you created.
tkomp-abgru= xvbap-abgru
So if you populate special pricing based on ABGRU (with possibly other conditions) in the condition table then that condition record will be read for the corresponding condition type.
You would of course need a developer to modify KOMPAZ structure and code the user exit for moving the rejection reason to tkomp
That is in short how you can achieve this

Invoice split due to hierarchy type for pricing A

Hi,
Gurus
The invoice are getting splited. If i see the split analysis it tells that due to hierarchy Type for pricing A.
Guide me gurus.
Regards
Anand

Hi Anand,
>> ... any field will be there as hierarchy type for pricing A at delivery level?
I don't think so, Deliveries in SAP have usually no pricing information. Everything (except quantities) comes from the Sales Order.
>> I can also tell to my technical person to write one routine to not consider hierarchy type for pricing A for collecting one or
>> more delivery in one invoice.
>> After he wrote were i want to assign the routine in copying control? weather in header level or item level?
You can usually change header level (VBRK) data in the item level data transfer routine.
Before doing that and I like to to have 100% control, I would personally check the reason for the system behavior.
Check customizing for pricing settings for sales order and billing documents involved.
Regards,
Franck

Userexit for pricing

Can anyone please share any of their experience with a scenario of using userexit in pricing.
Thanks

User Exits for Price Determination
USEREXIT_PRICING_PREPARE_TKOMK (module pool SAPLV60A, program RV60AFZZ)
This user exit allows you to copy additional fields for pricing in the TKOMK communication structure (header fields), which have not been provided in the standard SAP system. These fields can also be used for pricing in the billing document.
This user exit is described in detail in the "New fields in pricing" section.
USEREXIT_PRICING_PREPARE_TKOMP (module pool SAPLV60A, program RV60AFZZ)
This user exit allows you to copy additional fields for pricing in the TKOMP communication structure (item fields), which have not been provided in the standard SAP system. These fields can also be used for pricing.
This user exit is described in detail in the "New fields in pricing" section.
USEREXIT_FIELD_MODIFICATION (module pool SAPMV61A, program MV61AFZA)
You can use this user exit to adjust the display of individual lines in the condition screen by changing the display attributes of the screen fields. This does not include the display of subtotals.
This user exit is also used in order processing.
USEREXIT_FIELD_MODIFIC_KZWI (module pool SAPMV61A, program MV61AFZB)
You can change the display of subtotals in the condition screen by changing the display attributes of the screen fields.
This user exit is also used in order processing.
USEREXIT_FIELD_MODIFIC_KOPF (module pool SAPMV61A, program MV61AFZB)
You can adjust the display of subtotals in the condition screen to your requirements by changing the display attributes of the screen fields.
This user exit is also used in order processing.
USEREXIT_FIELD_MODIFIC_LEER (module pool SAPMV61A, program MV61AFZB)
You can adjust the display of blank lines in the condition screen to your requirements by changing the display attributes of the screen fields.
This user exit is also used in order processing.
USEREXIT_PRICING_CHECK (module pool SAPMV61, program MV61AFZA)
You can install additional checks to the standard checks of condition lines (e.g. maximum/minimum value).
USEREXIT_PRICING_RULE (module pool SAPLV61A, program RV61AFZA)
In the standard SAP system, it is predefined which condition categories and classes can be copied or recalculated per pricing type. You can change the predefined standard procedure for each pricing type.
USEREXIT_CHANGE_PRICING_RULE (module pool SAPMV61A, program MV61AFZA)
You can use this user exit to change the pricing type that has been predefined in the copying control table in billing.
USEREXIT_XKOMV_BEWERTEN_INIT (module pool SAPLV61A, program RV61AFZB)
This field is used in the formulas and therefore initialized before the loop for the pricing procedure starts.
USEREXIT_XKOMV_BEWERTEN_END (module pool SAPLV61A, program RV61AFZB)
Within a loop for the price components during pricing, specific values can be transferred into the communication structures in pricing to be further processed.
USEREXIT_XKOMV_ERGAENZEN (module pool SAPLV61A, program RV61AFZB)
In change mode, you can change the dynamic part of the condition record (KONVD) that is always redetermined (i.e. it is not stored in database table KONV).
USEREXIT_XKOMV_ERGAENZEN_MANU (module pool SAPLV61A, program RV61AFZB)
You can use this user exit to change the ready-for-input fields of the manually entered condition record in add mode in the condition screen.
USEREXIT_XKOMV_FUELLEN (module pool SAPLV61A, program RV61AFZB)
This user exit is always called up during a redetermination of all or individual price components. You can change the work fields of the condition line. However, this only applies to conditions that have been determined via a condition record.
USEREXIT_XKOMV_FUELLEN_O_KONP (module pool SAPLV61A, program RV61AFZB)
This user exit is always called up during a redetermination of all or individual price components. You can change the work fields of the condition line. However, this only applies to conditions that have been determined via a condition record. This may include subtotals, manually entered conditions or conditions that have been calculated with a formula.
USEREXIT_PRICING_COPY (module pool SAPLV61A, program RV61AFZA)
You can change the KONV fields for copied price components.
Note: as of Release 4.6A, the display of the condition screen (screen 6201) has been converted from a full screen to a subscreen. The full screen is included in the SAPMV61A module pool, the subscreen, however, in program SAPLV69A. Therefore, instead of MV61AFZA and MV61AFZB, the user exits in LV69AFZZ should be used. For reference, see OSS note 313569.
Regards,
Rajesh Banka

Material Description in Condition record for pricing

Hi All,
I want to have material description (not as key field but just for information) in the condtion record for pricing in VK11. What shud i do for it. Please suggest.
Thanks

Hi,
While changing Condition Table , select the Material & go to technical view.There is a radio button of Text Field ,select it & then check.
Best Regards,
Ankur

Disable / enable table control field at runtime

hi ,
i am working on a custom transaction in which i have a table control...depending on a table value i have to disable an input field inside the table control...
i know in a normal field we use
loop at screen.
if screen- name = 'XXX' or screen-group = 'XXX'
screen-output = 0.
endif.
but inside a table control field how to modify it.
Regards
Harish Ramakrishnan

All you need to do is put some code in a module of your PBO. This will change the cell attribute of a single row.
PROCESS BEFORE OUTPUT.
* PBO FLOW LOGIC FOR TABLECONTROL 'I_INTRCON'
* MODULE I_INTRCON_CHANGE_TC_ATTR.
* MODULE I_INTRCON_CHANGE_COL_ATTR.
LOOP AT I_INTR
 WITH CONTROL I_INTRCON
 CURSOR I_INTRCON-CURRENT_LINE.
 MODULE I_INTRCON_CHANGE_FIELD_ATTR.
ENDLOOP.
MODULE SET_CURSOR_FIELD.
MODULE STATUS_0200.
module i_intrcon_change_field_attr output.
modify i_intr index i_intrcon-current_line.
if i_intr-check = 'X'.
 loop at screen.
 if screen-name = 'I_INTR-RCVQTY'.
 screen-input = '1'.
 endif.
 modify screen.
 endloop.
endif.
endmodule.
Regards,
RIch Heilman

Controlling fields in CMD for Pricing

Similar Messages

Maybe you are looking for