MM Pricing procedure - Condition type post to different GL account in MAP

Hi All,
We have a requirement for posting intercompany Stock transfer between Company A and B, and the transfer price will be Moving Average Price (say $ 100) + Mark up (say 25% i.e., 25) of supplying plant.
Created a new PO pricing procedure, and created a new Accrual condition type ZMRK for markup and made it statistical posting. Also in the pricing procedure the Condition type we assigned an Account key ZM1 and Accrual Key ZMA. we tried posting the Goods receipts in the receiving Company B, and it is posting the following entry :
Invetory A/C DR 125 (note: Account key ZM1 was not considered for debit account for markup)
GR/IR A/C CR 100
Markup Accrual A/C CR 25
REQUIREMENT: Our requirement is that the Mark-UP condition should not hit Inventory Account and should be debited to I/C Mark Up account (assigned to Account key ZM1) and entry should be as below:
Inventory A/C DR 100
Markup A/C DR 25
GR/IR A/C CR 125 (accrual is not required, if we can include the markup into GR/IR account)
OR
Inventory A/C DR 100
Markup A/C DR 25
GR/IR A/C CR 100
Markup Accrual A/C CR 25
NOTE: The Material is maintained as Moving Average Price and we dont want to add the Mark Up cost into the MAP of the receiving plant.
Please check and let me know if there is a way to do a condition type in PO pricing procedure to solve the issue of not hitting the inventory posting for condition record or any other way to handle this requirement.
Thanks in advance,
Surya

Hey surya,
I am also facing the same issue. Can you pls let me know whether you achieved this using any standard configuration.

Similar Messages

Pricing Procedure Condition Type EK02

Dear, Gurus
I have an MTO scenario. All is working I mean from the production order the cost is coming to my sales order in condition type EK02. But that is making all other condition types as inactive.
current pricing schema
Pr00 Price it is manual.
Other Z condition types which are also manual.
Then EK02.
Gross Sales
K005
K007
Net Sales
MWST
ZSED Sales excise duty
Value after Tax
VPRS
also, at the top the net value does not change at all it stays constant and seems to pick up the EK02 price.
I want all other condition types to be manual but active even if EK02 price is picked up from Production Order.
How can I set it up to make them all green as active?

Previously all my condition types were manual entry so all were green.
Pr00   manual
Zman manual
Zsat   manual
Zetc   manual
Also, in PR00 class is B=Prices       Calc Type = C for qty
All the ZMan, etc is A=discount/Surcharge   calc type=B fixed amount.
To be scenario all I added was condition type EK02 in pricing procedure and by standard it is in class B=prices     calc type=C for qty, and cond cat=costing
When production cost transfer to EK02 lets say example 500. All those previous cond are yellow inactive. and then net price equals 500!
In terms of my terminology and basic understanding you can only have one cond type function as price in class B=prices.
So either the EK02 or the Pr00 needs to have cond type B for Price. If I make the Pr00 a discount/Surcharge nothing changes in respect to updating the price in sales order. Lets say even if its all corrected and I have lets say EK02 function as price the Zman and Z condition types are under discount surcharge, that at least should not be inactive?
Please help
thanks

Scaling in case of Pricing Procedure Condition Types

Hi,
I want to maintain Scaling in Condition Types of the Pricing procedure. Please guide me to maintain it.
Thanks & Regards
Saeed Arif

Hi,
If you have maintained Purchasing Info Record: In ME12 transaction go to Conditions tab. Select the Condition Type 'PB00' and click the Scales icon (F2) on top of the screen. Here, maintain the Scales.
First decide the Scale Type, Scale Basis and Validity periods for which you want to maintain the Scales. Save your changes and you can see the effect on Price, while creating the PO for the quantity mentioned as per the Scales.
Regards,
Narayana.
Edited by: Narayana Ghanta on Oct 13, 2008 3:43 PM

Priceing procedure - condition type - number of units

Hi, I have a condition type in my pricing procedure. When I display item conditions for an item in a sales document I can see that my condition applies to 1000 units of measure. How do I change my condition so that the calculated amount applies to only 1 unit of measure?
Thanks

Hi Marko
Go to VK12 and change the UoM . Change the UoM and maintain the base unit of measure (ex:pc) that you have maintained in MMR . Provided you have not maintained Sales unit of Measure.
Also check wheather you have maintained any alternative UoM or not and that alternative UoM has been maintained in VK12 or not
Also check in V/06 in that condition type details wheather any UoM has been maintained or not. If it has been maintained then make the UoM feild blank by removing the UoM that has been maintained in V/06 and then check
Regards
Srinath

Scrap Movement type + reason code - different GL account ( OBYC)

Hi Experts -
I have an issue in hand which explains as below ...
User wants to post Scrap movement of different reason to post to different GL account with T.Code OBYC. SAP has a movement type 561 for Scrap related account determination. In the standard SAP situation, we can post to ONLY ONE GL account for Scrap using 561 movement type. But my situation is like this - A material can be scrapped due to different reason (reason code) and based on the reason (I use reason code A - E), I want to post it to different GL account.
In standard SAP , we can define the account determination (OBYC) for scrap with ONLY ONE GL account as follows ...
Val. modifier - Plant 1
Val Class - 1111
General/Account Modifier - VNG (mapped to 561)
GL Account - Z123456
But my scenario is like this ....
561 + reason code A should post to Z123456
561 + reason code B should post to Z999999
561 + reason code C should post to Z111111
I was thinking for creating new General modifiers for different codes (A - E). Please suggest me if that solution is feasible else provide me an efficient solution.
Thanks much.
Regards,
Jude

HI
Defining new general modifiers is an option.
Alternatively you can look at defining a new substitution rule. The substitution rule will only hold good if the GL Account for scrap is not used anywhere else. (This should ideally be the case if it a scrap account).
In the substitution rules you can check for the particular scrap account number and then depending on your reason code, you can change the GL account before it is posted to.
Regards

MR8M post a different GL account versus MIRO

Hi Gurus,
Any idea why MR8M posted a different GL account from the original entry? here are the entries:
MIRO
Debit- GR/IR clearing      100
Debit- Expense(manual)    20
Credit- AP vendor                120
MR8M
Debit- AP vendor          120
Credit- GR/IR clearing         120
This entry resulted to a difference in GR/IR clearing account and the user do the clearing manually in FI.
Why is it MR8M did not reverse the Expense entry and posted to GR/IR clearing instead?
Thanks a lot for your time.
Cheers,
Dru

hi
when u post MR8M ,the invoice is get reversed but the FI entries u have to clear manually ,it is done by FI peoples
FI documents need to be cleared manually using Trsnactions F-04 for G/L accounts & F-51 for Vendor accounting documents
You can also automatically clear using F-13
Mention the Documents number & clear the items
Please get in touch with FI Consultant.
regards
kunal

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: New condition type not getting listed in options in product master

Hi,
I have created a new pricing procedure and also created a new condition type for it. I am trying to create a condition record in the product master for this condition type but the condition is not there in the list of conditions. How can I inlcude it in the condition list?
Even the new condition type I have created by copying 0PR0 is not getting listed in the options, whereas 0PR0 is getting listed.
Regards,
Meenakshi
Edited by: Meenakshi Sawhney on Sep 9, 2010 8:27 AM
Edited by: Meenakshi Sawhney on Sep 9, 2010 8:29 AM

Hi Meenakshi,
you need to enhance the condition maintenance group in the customizing, which is assigned to the product master. Please check: IMG: Customer Relationship Management -> Master Data -> Products -> Special Settings for Sales Operations -> Assign Condition Group to Application CRM and IMG: Customer Relationship Management -> Master Data -> Conditions and Condition Technique -> Condition Technique: Basics -> Create Maintenance Group.
Best Regards,
Michael

Manual Pricing for Condition type pricing

Hi experts,
I am changing the price in sales pricing of cj20n transaction manually and it get updated, working good.
Is it possible to get the updated manual pricing in all the transactions related to CJ20N transaction.
Thanks&Regards,
Vino

Hi..,
Yes. Its possible.
I want give some function support on this as worked on condition types in another transaction.
You needs to be check that if your pricing procedure is having that condition type or not and also you have to check that condition type is mannual or not.
First get your pricing procedure...
For this goto V/08 transaction code and select your pricing procedure there -> double click on control folder-> there you can get all condition types for that procedure -> and check ur condition type is mannaul or not.
Thanks,
Naveen.I

Pricing Error- Condition type not found.

Hi Gurus,
I have a issue with pricing.
Scenario :
For a pricing procedure i have 3 condition types ;
For example :
ZXED, ZXE1 & ZXE2.
Of these ZXED is Manual, Mandatory & Statistical in nature.
ZXE1 & ZXE2 are Manual.
When i create a sales order my pricing procedure is getting determined correctly.
The issue comes in when i try to key in the values at the item level condition in the sales order:
If i see the options(F4) available for me to select the condition types i get have see only one condition type i.e ZXE1. but esentially i should get to see all the 3 condition types as an choice of code(condition type).
Can any one help me to find out the possible reason why i get to have only one condition type for selection.
Your suggestion is highly appreciable.
Rgd
VIVEK.

Hi,
1. Understand onething that a particular condition type if maintained "mandatory" in the pricing procedure then you will have to create the condition record for it using transaction code "VK11". If it is manual then you can give the rate directly in the sales order after selecting it. Since you have maintained "manual", "mandatory" & "statistical" for the condition type "ZXED" at the same time that is why the system is giving you the error "Pricing error" Mandatory condition ZXED is missing."
2. Also you want the system to show you all threee condition types "ZXED', "ZXE1", "ZXE2" to choose manually as per your requirement. Do one thing go to transaction code "V/06" - select the required condition type say "ZXED" - double click on it - in the "changes which can be made" section you will see a field for "Manual entries" - in this select "no limitations" and save the condition type. Similarly do it for the other 2 condition types and save it.
I tell you you must have maintained there "D-not possible to process manually". If this is maintained then the system will never show you the condition type to choose from the condition type list in the sales order.
Note: You have maintained for "ZXED" manual/mandatory/statistical. Now as it is mandatory also you have to maintain the condition record for it in "VK11". Now if you change the rate of this condition type in the sales order then when you will create the invoice in "VF01" the system will show that value only which has been maintained using "VK11" because in billing also the system fetches the condition record from VK11 for the mandatory conditions.
Hope this clarifies and solves your doubt.
Reward points if solution helps.
Regards,
Allabaqsh G. Patil

Pricing schema condition type

How to substract two condition types to get another condition value.
ZD01 contion type value-200
ZD02 contion type value-500
ZD03 Condition type value= 500-200
How to map this in the pricing schema
Regards
Umapathy.M

Hi,
You have to store value of ZD01 and ZD02 inn 2 variant (using column sub to) in pricing procedure. Then, you have to create 1 new routine to determine condition value for ZD03 using T-code: VOFM and assigned it in condition type ZD03 in pricing procedure.
(Subtract is done in new routine using ABAP Coding)
Regards,
Pavin

SD - TAXINN procedure - Condition types

Hi Friends ,
what are the conditions types used for (SD - TAXINN procedure)
BED - Basic Excise duty
Ed cess - Education cess
SH Ed cess- Secondary and Higher Education cess
VAT
SS cess - Social Security cess (1% on VAT)
CST
commisssion?
Thanks
Ivy

Hi Friends ,
I am using the pricing procedure JINFACF(TAXINN) wher iam using
JEXQ for BED
VAT for JLST
CST for JCST
I am not sure what are the conditions types i should use for the below ,I tried by making a copy of JCEP(cess) renamed it and used it to capture the below:
Ed cess - Education cess
SH Ed cess- Secondary and Higher Education cess
SS cess - Social Security cess (1% on VAT)
But when iam trying to calculate the CST on (base priceBedEdcess+Sh EDcess) its calculating on base price alone.
Thanks
Ivy

VOFM Pricing Requirement - Condition type at header

Hi Experts,
We have a new condition type, we want to use it in all our new invoices and has been made mandatory in the pricing procedure. Both the sales order and invoice have the same pricing procedure. I am using a requirement routine.
The code has to execute some logic for line items and pass the value to the new condition at the line item level. For new sales orders this is working absolutely fine as we have maintained a condition record and the condition exists. While creating any invoice from open sales orders which do not have this condition type, we are entering it at the header level.
I perform my logic and pass the value for the line items in TKOMV. These values do not get saved. Whereas, the values get saved when we have other condition types that are at the line item level.
The questions I would like to ask is:
1. Is requirement routine correct for this scenario? Or should I use condition value/condition base value routines to pass new values?
2. Is the method of changing the values in internal table TKOMV correct?
3. The value from this condition type has no financial impact on the FI documents, but it is mapped to COPA. Is there a way to write code to directly update the COPA value field in the COPA side without having to create a routine?
Thanks,
Abdullah Ismail.

You should not be facing this problem as system adjusts the difference in value for the last item. Try to update the prices in the doucment and check.
Regards,
GSL.

Retail Promotion condition type can be different from VKA0

Dear expert,
You may know that when we create promotion through WAK1 and active price through WAK5, SAP will create condition and store to condition type VKA0.
My question is "Is this condition type VKA0 hard code by SAP, can we have different condition type other than VKA0"?
Here client wants to have different condition type, for example ZKA1, ZKA2 to store different condition for different promotion type / purpose.
Any soluiton or suggestion?
Best Regards,
Honghai

Hi
Please check you customize settings in the IMG under retail sales price calculation.
Spro>logistics general>retail pricing>sales price calculation>control data for pricing table and data backup>control per sales price calc schema and list field
In your schema under list field ENDPR set the condition type for promotion and normal when saving list fields in master conditions.
Don't forget to then maintain the assignment of condition tables for your schema as well.
I hope this works.
Regards

Urgent: Posting to different Symbolic Accounts for the same Wage Type

Hi Everyone,
Assuming that I have a Wage Type and 2 sets of Symbolic Accounts tied to their respective Chart of Accounts (belong to 2 different companies).
When I go to the configuration node "Define posting characteristics of wage types" in SPRO, under Payroll, I have assigned Symbolic Account 1234 (which belongs to Chart of Accounts A) and Symbolic Account 6789 (which belongs to Chart of Account B) to Wage Type 1000.
When I execute the Transaction for Posting to Accounting (PC00_M99_CIPE), I get an error (Message: Posting Balance is not cleared). After exploring the log, i notice that both Symbolic Accounts appeared.
How do i ensure that only the specific Symbolic Account is being posted?
Take for example that the employee belongs to Company A.

Hi,
U can post to different accounts for same wage type but NOT symbolic accounts!
Do as follows:
1)-Define employee grouping account determination(PPOMD feature)
2)-Define symbolic accounts
3)-Assigning Accounts
When doing 3rd step, click "RULE" button and select "Employee group".
By doing so you can posting same WT to different Accounts according to different employee grouping , like below:
SymAcc   Grp             Account
Z001     GU     5502019900
Z001     SZ     5502019901
Z001     YY     5502019902

MM Pricing procedure - Condition type post to different GL account in MAP

Similar Messages

Maybe you are looking for