I face that when setting lot size in material master is "EX". Normally, SAP should generate plan order follow the quantity of each requirement. But I faced that if some requirements fall in to the same date. Why does system generate only 1 plan order which summarize all requirements quantity of that date?
Could you please suggest ?
which requirment ur taking abt in MD61 ??
Create Demand for 3 months in MD61
then run MRP
system will create 3 plan orders for three months
Else give FX as lot size and maintain 100 for fixed lot
and give demand as in MD61 300 for one month only
then system will create 3 plan orders
Edited by: kumar kumar on Nov 11, 2009 12:26 PM
In standard SAP if the requirements of one day are also combined to one procurement proposal for the lot-for-lot order quantities (lot size EX) (see documentation for lot-for-lot order quantity). Separate procurement proposals can only be achieved if you work with make-to-order production. Here, the requirements are managed in separate planning segments of the stock/requirements list. As you are using strategy 40 with EX lot size then the requirements of one day are also combined to one procurement proposal.
Hope clear to you. Also refer the OSS Notes: 140802 & 550568 for more details about it.
i'm facing a similar situation, and the explanation (though true) that EX behaves same as TB with strategy 40 does not make business or system sense to me. Did u guys find a work around for this? If it behaves thte same why allow EX for MTS at all? Most of all why should not EX be allowed to behave lot - for - lot when it is intended to be like that? Any insight will be apprecited. Thanks!
Also, most surprising and irrational is that this thting over rides everythting else (availability check grp, ind/coll indicator) and just imposes the weird EX behaviour on the system. They must have provided for a work around to ride over this. Surprisingly if they have not.
Edited by: Satyajit Kumar on Nov 3, 2010 8:56 PM
EX works exactly as it was designed. Most planners I know do not want multiple planned orders for the same day for the same plant/part in MTS. If SAP did not work this way when I was a planner, I personally would have commissioned a developer to create a way to force it to do so, using modifications if necessary.
The granularity of MTS MRP is "Day". Although I can't speak for SAP, I suspect that this granularity relates to SAP's reason for setting EX up this way. If you want a better answer, you should contact Walldorf. If you contact SAP and get their explanation, I would be interested in hearing what they say. Please let us know.....
i completely understand and appreciate your point here. Perhaps what u are saying is correct in terms of planning granuality. But let's also consider that even in MTS there are SOs coming on the planning screen (strategy 40). Now in a process industry set up, with multiple SOs and continuous lines, and variable weights of the finished product, say cheese, milk or ghee, this behaviour becomes counter productive. Hence in my opinion even if SAP suggests and designs this as a std behaviour, they should allow some work around to over ride this. Inputs are welcoem.
I would say that ESPECIALLY in the process industry, I wouldn't want 5 planned orders (with 5 setups and 5 teardowns) for the same part on the same day, just because I had 5 different sales orders with the same requirements date.
I hope you find the workaround you are looking for.
picture this: I have a continuous line, running one clubbed planned order for multiple sales orders. Output is being filled into cases and cases go into pallets. The output gets label printed/posted on it, with batch number and sales order number. Sales order number needs to be put on pallets as we need to putaway with sales order reference (process requirement).
Now with one continuous planned order, how would the operator know as to when one sales order is completed and the next one starts?
Also, this is a variable weight product, so just randomly printing weight with reference to theoritical weight of each pallet will also not work, as we do not know the weight of the pallet till the time final receipt/weighment is done, which is only at the end of a pallet.
Having one process order per sales order will enable shop floor to know that which sales order has been served thru this process order, and solves the issue of both capturing eact weight and sales order info, as well as putaway with sales order reference.
What you are describing is MTO, not MTS. Certainly, if you use MTO you can have one planned order per sales order item.
The original query was about strategy 40. This MTS strategy supports assembling and delivering FGs materials to stock, consistant with a demand plan, yet consumable by customer orders. The production line in most such scenarios neither wants nor needs to have visibility of any customer orders. Their 'customer' is the Demand plan, and their 'shipto' is Finished Goods warehouse.
MTO production orders have the sales order, item, and customer number embedded in them. In addition, it is possible to have Production Memo texts from the sales order automatically be printed in the shop floor papers. The Sales order and the production order are intimately married. I think this is what you should be using, especially considering you must putaway w/reference to a sales order.
appreciate your insight. Really glad that you could see through the issue. Yes you are right, typically it does appear like MTO, but as we all know there's nothing like perfect world, and so it is here. They do put in sales order reference (as in just reference, and not really need the hard link between SO and PO), but it's essentitally a MTS scenario, and they will still manufacture if there are no SOs. SO reference is there on process orders as there is a lot of contract manufacturing, which run into months and at times years.
That's all they need SO reference for, besides other reasons i mentioned in my earlier post. Apart from that they do not really need hard linkage of SO to process order. If i try to set up MTO, it'll get even more complicated due to SO stock and plant stock philosophy, and procurement based on SO account assignment, and other MTO philosophies, that we don't need here.
The whole point is why not let EX plan lot-for-lot, and if some planners do not like it that ways (i know u would'nt,from your earlier post) they can always use lot size TB instead. that gives flexibility on both sides. I'm trying to figure why wouldn't SAP let some one do that, instead impose clubbing of orders. Even if they keep the std design the way it is, let there also be a work around to over ride that, as they normally do in most of the cases.
Edited by: Satyajit Kumar on Nov 7, 2010 10:59 PM
I maintained availability check is "02", used strategy "40" and in MRP4 view maintained individula/coll = "1".
After run MRP. System generate only 1 plan order which summarize all requirements of each date.
I would like system to generate individual plan order for each requirement. Eventhough, the requirement fall in to the same date.
This is the standard SAP behavior.
Unless you use the Strategy - MAke-to-Order, this is not possible.
Eventhough the Lot Size is Ex, if the requirements falls on the same day, then system clubs the requirements and proposes the receipts in a single lot. This behavior is exactly same as the lot size "TB".
If you use the strategy 40, then this requiremnt can not be fulfilled.
Refer the OSS Note 550568 - FAQ: MRP run (MD01, MD02, MD03, MDBT...)
There are several requirements on one day. Is it possible that the MRP creates a separate procurement proposal for every requirement?
Just as for the daily lot size with number of periods = 1 (lot size TB), requirements of one dayare also combined to one procurement proposal for the lot-for-lot order quantities (lot size EX) (see documentation for lot-for-lot order quantity). Separate procurement proposals can only be achieved if you work with make-to-order production. Here, the requirements are managed in separate planning segments of the stock/requirements list.
Hope this helps..
Revert for futher discussion..