Use of subtotal column in MM pricing procedure

Dear experts,
Please tell me the use of subtotal in MM pricing procedure.
Regards,
ABHI

Subtotal is
u2022 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 vendor discount or the cost of a material) are stored.
u2022 If the same fields are used to store different condition amounts, the system totals the individual amounts.
u2022 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 order.
Hope this can assist you.
Thanks & Regards
JP

Similar Messages

What is the meaning of this column in the pricing procedure?

Dear Gurus,
What is the meaning of this column in the pricing procedure?
thanks..

subtotal field : Subtotal field is used to pass the value to some other field in PO .
for ex: using value 9 you pass the value to field komp-brtwr. so that this can be used in any other routine in the pricing procedure.
requirement field: if there is a scenario that condition type should come in pricing on some condition like vendor country is india. in that case use create the requirment and attached this requirement.in this requirment you put logic and set the sy-subrc value 4 or 0.

Use of Condiition Type JEXT in Pricing Procedure

Hi !
Can anybody tell me what is the use of Condiition Type JEXT in Pricing Procedure ?

Dear Indrajit,
JEXT - Total BED value and generally it will be 100% maintained in VK11. and more over if there are any discrepancies in the JBED -% condition type or some changes, then you also go with JMAN-Manual excise duties.
Ex:
Item   Condition type                Value
10             JBED(10%)                100( calculated on Assessable        value 1000)
20             JMAN (1%)                  10 (calculated on Assessable value 1000)
Then
30           JEXT                       110
and if there is no JMAN then JEXT value will be 100.
Generally if there is no JMAN , then JBED will be linked to Account key and JEXT will be treated as Statistical condition type.
And more over in the CENVAT Credit JEXT if offset against the JMOP( Purchases BED Value)
BEST REGARDS
SRI

The use of Cond type tab in Pricing procedure determination

Hi Guys,
In T-code:OVKK we are doing the pricing procedure determination. But ther is one tab called as :CType(Cond Type) there in that screen after our pricing procedure. Could you please some one tell me what is the use of this cond type and where it's reflecting in SAP.
Regards,
Kumar

Hi,
It is very useful to avoid Data entry work Pricing Conditiontype for example: PR00.
Ex: When your creating Sales order by using Item proposal there may be 100 item
if you maintain this in OVKK you no need enter the price for each item when ever your process sales order just creat condition record by using VK11 and condition type PR00.
Proposed condition type for fast entry
The condition type that the system automatically proposes in the double-line entry screen during sales order processing.
ProcedureEnter a condition type. If you leave the field blank, the system displays the active price condition during sales order processing.
ExceptionIf you change a condition manually, this will be displayed in the double-line entry screen.
Regards,
MH
Edited by: Mohammad Minahazoddin on Nov 22, 2010 9:54 AM

Invoice pricing procedure not using alt calc type from the pricing procedur

The sales order has the same pricing procedure as the invoice but when the invoice is created it is not using the alt calc type that is on the pricing procured like it is on the sales order. This is causing one of the condition types to have different values on the sales order vs. invoice.
I am not sure what other areas to check to see why this is happening. Any thoughts?

I have checked and in the copy controls for Delv type = LF and target Bill type = F2 the Pricing Type = G (copy pricing elements unchanged and redetermine taxes). Condition types such as ZPR2 where there is condition record copy in correctly to the invoice. It is condition type ZZIF where it is determined from a routine, not a condition record, where I am having this issue.
Is there another place in config that I should be making a setting so that condition types determined by routines are copied to the invoice without being redetermined at invoice create?

Downloading the pricing procedure

Hi Gurus,
I am new to the Middleware.
I have defined the new pricing procedure in ECC 6 and I require downloading the same pricing procedure to CRM 5. What are the initial objects I have to us for initial download?
I have used the following things in the pricing procedure
     56 Sales org. of order/plant Condition Table     Standard one
     PI02 Sales org/plant            Access Sequence      Standard one
     I have defined 6 condition types.
     I have created the condition records for the condition types that where in the pricing procedure.
Can any body help me out?
Thanks in advance.

Hi,
You told me that for the particular download use T.C - R3AR2 when I go there I found lot of objects but I am not sure which object i have to use? How to find the right object
If i want to download the Z00001 pricing procedure, 56 condition table , z001 to z10 condition table and condition records for the condition types.
I have also used the following things in the pricing procedure they are
In the subtotal column of the pricing procedure I have used
     1          Carry over value to KOMP-KZWI1
     A     Carry over price to KOMP-CMPRE (credit price)
     B     Carry over value to KOMP-WAVWR (cost)
In the requirement column of the pricing procedure I have use
     2     Item with pricing
     4     Cost
In the Condition formula for alternative calculation type column of the pricing procedure I have used
     2       Net Value
     11     Profit margin
Thanks in advance

Columns in Pricing Procedure

Hi..
What is the meaning of this column in the pricing procedure?
Regds
Shriniwas

hi
https://www.sdn.sap.com/irj/sdn/wiki?path=/display/erplo/16FieldsDescriptioninPricing+Procedure&
16 columns - Define Pricing Procedure
 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 theconditionswithin 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 conditionswithin 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 uncheck 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
o SKTO - Cash Discount
o 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.
o Go to T.Code: VOFM. - Maintain Requirements & Formulas
o Click on the "Requirements" in the top menu and then click on "pricing".
o We have a list of requirements, we can ask ABAP consultant to create new requirement based on the client requests.
o 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.
o Go to T.Code: VOFM. - Maintain Requirements & Formulas
o Click on the "Formulas" and then on the "Condition Values".
o We have a list of routines, we can ask ABAP consultant to create new routines based on the client requests.
o 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.
o ERB Rebate sales deduct.
o ERF Freight revenue
o ERL Revenue
o ERS Sales deductions
o ERU Rebate accruals
 For Ex.,
o For all Price condition types like PR00 etc. we assign ERL - Revenue.
o For all Discount condition types like K004, K005 etc. we assign ERS - Sales Deductions.
o For all Freight condition types KF00 etc. we assign ERF - Freight Revenues.
o 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.
Reward if USeful
Thanx & Regards
Naren..

Ask for detail explaination on "subtotal" in pricing procedure

hi, everyone!
I want to make clear about detail items under "subtotal" field in SD pricing procedure configuration.
For example, A--carry over price to KOMP-CMPRE, is a must for credit control on open sales order value.
But for other options, such as B, D, E and so on items, in which business suitation we need to use it? And where the "xworkd, xworke,..." are stored? What's the basic mechanism between condition results and communication structure, i.g., KOMP?
Would anyone do me a favor to give an answer or send some documents to my e-mail box: [email protected]
Tks!
Justin

dear justin
Sub-total:
The value of this field determines where the value of the sub-total is gong to be stored in data base
Sub-total 1     : KOMP KZWI-1
Sub-total - 2     : KOMP KZWI-2
rewards if it helps
siva

Requirement column in Pricing Procedure.

Hi,
Can anyone explain the usage of the Requirement column in the pricing procedure with a live scenario.
Regards,
RitiG

Hi Ritigo
Requirement key is used to assign a requirement to the condition type. This requirement can be used to exclude the system from accessing the condition type and trying to determine the value. This can be used to specify that the condition type should only be accessed if the customer has a low risk credit.
Regards
Yogesh

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

Pricing procedure with a reference of a billing document

Hi all,
How to apply new pricing procedure when you use a reference of another billing document?
by VA01, I want to use a billing document as a reference to create another sales document. Tthese 2 has different pricing procedures but when I do this, I want the sales document to use its own procing procedure.
But when I refer a billing document and create a sales document at VA01, it copies the billing document's pricing procedure.
These 2 pricing procedures have different condition types.
I already went to "Maintain Copy Control for Sales Document" - "Copying Controld: Billing Document to Sales Document" and set "B" as its pricing type.
Waiting for a valuable replies from y'all.
Best regards
Misaki

HI,
Thank you for your reply,
I already have assigned pricing procedures to the required order types at OVKK, and V/08.
but it still doesn't go right.
When I don't refer any billing document at VA01 and simply create a sales document using required order type, the assigned pricing procedure is used. However, when I use a reference of a billing document to create a new sales document, it copies a pricing procedure from the refered billing document and doesn't use its own pricing procedure.
Wanting to know how to redetermine a pricing procedure to create a sales document when referring a billing document.
Ideally, the new sales document doesn't copy a pricing procedure at all from the reference(billing document), if possible.
I really appreciate for your help.
Misaki

Error in Pricing Procedure Determination in Sales Order

Hi All,
I have created a Pricing Procedure and asiigned it with the SALES ORG, DIV, DISTR CHANL, CUSTOMER PRCDR and DOCUMENT PRCDR in SPRO.
i have assigned the Cust Doc Prcd with the BP and the Docuemnt Prcdr with the respective transaction. And also created the Basic Price for product and Discount Price for Sold To Party via CONDITION MAINTENANCE.
Still getting this error.
Looking for the solution.
Thanks,
VS

If you have check what RK suggested and is ok, then check also the customization of your transaction in spro>crm>transactions>basic settings>define transaction types.
go to your transaction type and then in left panel select customazing header. there check if you have defined under pricing data the doc.pric.proc. (document pricing procedure)
and also if you are not always using customer pricing procedure it is good to define in spro for determination of pricing procedure 1 determination rule which has filled only the folowing data:
- sales organization
- distribution channel
- document pricing procedure (the one you defined on transaction - which I described above)
- procedure
and division (if you use the dummy one) and customer pricing procedure leave empty. this way the procedure will be determined even if it's not found from customer sales data
And also be aware that once the error message for determination of pricing procedure appears it can't be removed so don't try the determination with already corrupted transaction.

Pricing procedure issue ..

Hi Expert,
I have assigned pricing procedure to sales org. 1500 so that i am able to create sales order through VA01. I have assigned it through view V_T683V. Now i want to create MAM order in sales org. 1500 but at the time of creation i am getting error message as "No pricing procedure assigned". MAM order is created with tcode JHA1x.
Please tell me what settings i need to do ?.
Thanks.

Thanks for your inputs Balaji,
Below is the error message which i am getting and it's diagnosis.
Pricing procedure could not be determined
Message no. J7 513
Diagnosis
The pricing procedure is determined using the sales area, a document pricing procedure in the sales document type and a customer determination procedure in the sold-to party's customer master. The system was unable to determine a pricing procedure in sales area for document pricing procedure and customer determination procedure .
Procedure
You can either change the customer determination procedure in the sold-to party's customer master or set up a pricing procedure in sales area for document pricing procedure and customer determination procedure .
From this could you please tell me where exactly i need to make changes?

Condition JEXC- Manual Excise Value, is missing in pricing procedure A M RM

Dear Gurus,
During PO creation following massage occurred,
Condition JEXC- Manual Excise Value, is missing in pricing procedure A M RM0000.
scenario: - JEXC condition type not picking the value automatically against Tax Code.
Pl. help,
Regards,

hi
plz check that U HAVE GIVEN PROPER SCHEMA FOR THE VENDOR as it is detecting schema as RM0000
or
it means that u have not yet setup the manual excise
check following configuration
Use Condition Type "JEXC" in MM Pricing Procedure.
You can use manual excise condition "JEXC" in case if your BED Rate is not fixed as 14% and you want to enter BED Value manually.
Once you input value in JEXC then it will replace the value of BED in "Taxes" under "Invoice" Tab. And ECS / 2% ans SECess / 1%
will get calculated on BED Value.
Here use Tax Code of (14% BED + 2% ECS + 1% SEcess + VAT/CAT As applicable), system will calculate BED, ECS & SECess as per the % maintained in Tax Code. Once you enter value in "JEXC" condition, it will replace the value of BED and ECS / 2% ans SECess / 1% will get calculated on BED Value.
For e.g.
As per Tax Code;
Base Value = 10000
BED / 14% = 1400
ECS / 2% = 28
SECess / 1% = 14
After putting value in "JEXC" as 1600 (For e.g.)
Base Value = 10000
BED / 14% = 1600 (Here 1400 will get replaced by 1600 under "Invoice" tab - "Taxes" button)
ECS / 2% = 32
SECess / 1% = 16
I think the above example will make clear the use of condition type "JEXC"
And Condition Type "NAVS" (Non - Deductible Tax) is used in MM Pricing which will bring value of CST from "Taxes" screen to "Conditions" of PO. Check the attributes of NAVS condition type in M/06
rgards
kunal

MM Pricing procedure change

Hi All,
Can you help with a problem I am facing. I have the requirement to add a new condition type to a MM pricing procedure. Upon recomendation from SAP I beleive that I should do this by copying the old one to a new code. My problem is this. We currently use scheduling agreements which contain the pricing procedure in EKKO. So my new pricing procedure will not take effect until I create an entirely new SA (which is not an option at the moment).
Any ideas?????

Hi,
In the existing SA's u can use the new condition type u create unless subsequent transactions have happened for the SA.
Delete the existing condition type & add the new one.
If subsequent transactions have been done, delete the existing one & prepare the new one, if the pricing is getting picked for subsequent transactions from SA.
Regards,
Sourabh

Use of subtotal column in MM pricing procedure

Similar Messages

Maybe you are looking for