on 10-04-2007 2:01 PM
Dear All,
I entered demands in MD62 for a FG.
day1 45
day2 105
day3 105
After that production orders were issued
PrdOrd1 45
PrdOrd2 105
Using CO15, workers booked FG against PrdOrd:
PrdOrd1 > 45
PrdOrd2 > 54
PrdOrd2 > 24
(I can see in MB51 all of them)
The current situation in MD62:
day2 81
day3 105
Why do we have 81 pcs for day2? It should be 105 - 54 -24 = 27. (in CO03 I can see 78 pcs [24 + 54] as 'delivered' qty).
What might be the reason? Where can I check the root cause of this?
(We use planning strategy 11)
Thanks in advance,
Csaba
Stg 11 is driven by consumption period...maintained in material mster or img for a mrp group, for which the material in question is assigned.
Hence please check the consumption stg, forward period and abackword period in material mster MRP3 view or mrp group.
Please check and come back
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Dear Rajesha,
Thank you for your help.
I've checked the material master, both forward/backward consumption periods are set to 0.
I don't think the problem would derive from this setting ( Or I'm mistaken [I don't know exactly])?
As they book against production orders the demands should decrease (as the stock increase as a consequence of 101 MVT of FG).
(We use only IndReq for FG and these are entered in MD62.)
What can be the cause of this problem?
BR
Csaba
Dear All,
Thank you for your answers.
(
MD6* just shows the problem itself:
Planned qty: 81 [105-24]
Withd. qty: 24 [instead of 54+24=78]
MB51 shows every booking (both 54 & 24).
)
This is the 'history' of this 'mystery':
2007.10.04. IndReq 105
2007.10.03. PrdOrd issued
2007.10.03. 54 pcs booked
2007.10.04. 24 pcs booked
So, till now it hasn't caused any problem if we booked days AFTER the IndReq but it seems to be problem if we book BEFORE it.
Is it possible that this is the cause of the problem?
Thanks,
Csaba
Csaba,
I think you did not go through my previous posting I already summed it all.
Yes, you are right Since there were no consumption days and Logic defined in the MRP3 view of the material master and also I assume the same for the MRP group, <b>system can consume only PIR which is on the same day of GR</b>, <b>since your PIR was dated 2007.10.04 when making GR for 2007.10.03 system did not find any PIR for consumption, so that quantity of 54 was not accounted.</b>
<b>Good practice would be to define the consumption days and logic in MRP 3 view, if not in MRP group parameters in OPPR.</b>
Hope this clarifies all, please close this thread after rewarding suitable points for answers which helped you,
Regards,
Prasobh
Dear Prasobh,
I did read your answer but one thing it's not clear to me:
You wrote that <i>'system can consume only PIR which is on the same day of GR'</i>.
But this contradicts to my 'experience'. For instance:
2007.10.02. IndReq 105
2007.10.02. PrdOrd issued
2007.10.02. 24 pcs booked
2007.10.03. 12 pcs booked
2007.10.04. 69 pcs booked
IndReq 'dissapeared'. So, the problem exists only if we book before. If we book after, it's no problem, because in this case we have IndReq to consume - as I comprehend.
Thanks for your help!
Csaba
Csaba,
Looks like your system is set only to consume in BACKWARDS.
Since there is no setting in MRP, check if there is any MRP group assigned to Material in MRP1 view.. check the defination of the consumption parameters for that group in transaction OPPR.
If MRP group is blank in the materail master, then check the MRP group assigned to the Materail Type, and look for the defination of the MRP group in OPPR. (SPRO->Production->MRP->MRP Groups->Define MRP group per Material Type).
Regards,
Prasobh
Message was edited by:
Prasobh Karunakaran
Dear Prasobh,
Thank you for your help and endurance.
1.
I checked another issue as well (CASE2)
2007.10.03. IndReq 45 pcs
2007.10.02. PrdOrd 45 pcs
2007.10.02. 45 pcs booked
>> IndReq dissapeared!
The difference between CASE1 (original issue) and CASE2 is the 'basic start date' of the PrdOrd.
CASE1
2007.10.04. IndReq >> 2007.10.03. 'basic start date' of PrdOrd
CASE2
2007.10.05. IndReq >> 2007.10.03. 'basic start date' of PrdOrd
So, in both cases they booked one day before the IndReq, but in CASE2 the qty in MD6* decreased in CASE1 it didn't.
2.
I've checked the settings you wrote about.
We don't use MRP Groups (no 'MRP Groups exist), and the 'Default MRP group per Materail Type' was totally empty too.
Is this the cause of the problem? I thought I understood it, but now I can't get a grasp of it again.
What's your idea?
Thanks,
Csaba
Csaba,
My simple suggestion would be to maintain Consumption = 2 Backwards/Forward and maintain days for Forward and Backward as required in the MRP3 view of the material. Generally clients prefer 999 days so that naturally PIR will get consumed for every GR and there will be no need to run reorganisation program.
Regards,
Prasobh
Csaba,
Hope you got the explaination, if so please close this thread after rewarding points to helpful answers.
Regards,
Prasobh
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Csaba,
If the consumption parameters are not maintained in the Materail Master MRP3 view or if it is not defined by in the MRP Group(OPPR) which is a assigned to the Material Master MRP1 view, then system allows you to Consume only the PIR which is relevant on the day of GR.
So in your case,
1. GR of 45 done excatly on the same day as PIR date.
2. I assume that when the second GR of 54 was done there was no PIR on that day which could be consumed. So there was no consumption. Probably done on the 1st day.
3. Next when GR for 24 was made the date matched to the date of the second PIR so it consumed 105-24 = 81.
Hope this helps your understanding. Please close this thread if so, after rewarding points to helpful answers
Regards,
Prasobh
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
104 | |
12 | |
11 | |
6 | |
6 | |
4 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.