MRP and Consumption-based planning are two fundamental SAP planning types that can be used to determine a product’s requirements. To avoid any confusion on the subject: I am not talking about the MRP run that is executed through MD01 and MD02. I’m talking about planning types that are set in the Material Master’s MRP1 tab. The MRP type is used in the MRP run to determine HOW procurement and/or production quantities are calculated.
Tag Archive for 'MM'
Page 2 of 2
The dead stock report often leads to misinterpretations. Hence a little guidance on the dead stock report.
The dead stock report analyses what part of stock is never touched in a defined period of time. If you look at the below graph you will see stock level through time.
In analyzing stock movement between period 1 and 5, stock never drops below 30. 30 is your dead stock. It’s the part of stock that was never touched. Now what does this tell you? That’s not easy to say:
NETCH, NETPL and NEUPL are three fundamentally different ways to schedule your MRP run:
- NETCH – Net Change Planning
- NETPL – Net Change Planning within Planning Horizon
- NEUPL – Regenerative Planning
I will elaborate on these three options and their workings:
End-users can get confused about the difference between MD04 – Stock/requirement List and MD05 – MRP List. This post will give you the answer on when to use what report and why:
The price in the info record (EINE-NETPR) does not always agree with the price that is taken from the info record when creating a purchase order. The most common cause is that the condition was updated by condition maintenance. This will not translate into a direct update of the net price in ME13 (display info record). If you want the net price to show exactly as the info record condition, then schedule report/program RM06INP0 (SM36). This will do an update routine and synchronize prices.
To block storage location postings the easiest way to achieve this is to use MI01 create inventory document. This is normally used for inventory count. In creating an inventory document (which is used as a counting document) you can select the option to block postings on the location. The storage location block can be undone by deleting or posting the inventory document. In case you do not actually execute a inventory count you wish to delete the document using MI02.
Note: In case you are using batch managed materials you will not be able to use this method, since the inventory document will only block existing material/batch combinations. New batches can still be received.
Problem we ran into today: we added a couple user-defined fields in the customer data tab in ME21N – Purchase Order. This worked fine, but we found that when in transaction ME22N after we saved the changes in these fields, the fields themselves would still be editable. Also going to a purchase order in ME23N, the UDF would always show as editable fields. After a search we found that function MEPO_DOC_GET_TRANSACTION_STATE was able to return the transaction state (I_TRTYP) that is required to tell the system to lock or unlock the new fields.
“Posting only possible in periods 2008/10 and 2008/09 in company code…”.
This is a typical error when you are working in a test environment. This will be job controlled in a production environment and should never be an issue there. It means that the fiscal period (the previous month) is not closed yet. You are probably trying to post a goods movement in the new fiscal period/month. The system will not stand for this kind of behavior! First you have to close the previous period. You can use transaction MMPV – Close Period for Material Master Records to close the previous period.
When you are in a test environment you don’t really care about checks and balances: tick the button Close period only. This will get SAP into the new period without any problems.
And to check the current period for your company use OMSY. This will help you determine what the next period is to fill out in MMPV. Your Finance colleagues can tell you what the current fiscal period is. Usually the periods follow the calendar month logic. It is also possible that the fiscal year is determined otherwise.
Especially in test environments that are hardly ever used periods may not have been closed for months. In this case you have to close each period one-by-one.







