Planned Work Orders, Messages and Time Fences

GVSUXC09

Member
I'm a Materials Manager, not an IT. Tried to search for my issue, couldn't find a related topic.

I was not here during implementation in Oct 2007 but have been tryig to fine tune th esytem since July 2008.

Don't ask me why, but they chose to have a multi-branch operation which means OT's between branches and complicated MRP runs.

But in one of my starign branches, a PC board area, we have too many past due work orders. I am addressign that issue, but in the meeantime JDE gives us messages to reschedule the old work orders or increase or decrease quanity but it also suggests planned work orders that assume we already have taken those actions so I overplan components. There is an avaialble balnce and yet it plans more material. I have never seen that and I go back to Ollie Wight days of MRP (Copics, Mapics, Fourth Shift, SAP, etc. installs under my belt).

The only manuals or help screens I have tell me how to put a fence for messages, but I can ignore the messages, will a time fence change cause the MRP planning to recognize all open work orders before it suggest a planned WO?

The way it works is backwards to me as it overplans until you react to the messages and then the next regen it tells me to push out the components.


Help! I must be missing something.
 
There have been a lot of views but no replies.
Is the question so basic that no one feels the need to help or is it so detailed a question no one has run into this before?

I could use suggestions, I'd like to fix this before my batch run thi sweekend. I am under pressure to reduce invenotry and this defect is increasing it!
mad.gif
 
I'm not sure of exactly what you are seeing, but the planning system is designed to plan orders on the basis that other recommended actions have been taken. Past due work orders should not affect the planning calculations - unless you arte using rate-based scheduling, when this is controlled in the processing options for R3482/83. For instance, if you have a "Decrease Quantity" message on a work order, the system will generate planned orders based on that action having been taken. That is one of the reasons for the "Unadjusted" and "Adjusted" rows in the Time Series, so you can see both sets of numbers. The system will always generate planned orders based on the "Adjusted" Beginnning/Ending Balances.

Hope this helps!
 
It does help and seems to confirm what I thought. I genraally just use supply demand inquiry, I will have to look up the Time Series you mention, I am unfamilair with the Adjsuted and Unadjusted you mention.

I am just surprised a system assumes you will react to the messages and plans on top of past due supply work orders.
Even if we answered every message every week there would still be the overplanning caused by the additonal planned WO that I don't need. I have never seen MRP work this way, with system planning "lag".
 
You need to be careful using Supply/Demand in evaluating MRP messages. Supply/Demand reflects real-time order information (work orders, sales orders, etc., as well as MRP data from the last MRP run. Because of changes in the data since MRP was last run, the planned orders may no longer be appropriate. You need to use the Time Series (P3413) to see the supply/demand information that resulted in the generation of the planned orders. The system does not "overplan". I believe you may be looking at data from two different points in time that may lead you to believe that. If you see that past-due orders do not seem to be considered, I would investigate things like supply/demand inclusion rules to determine the cause.
 
A possible other thing to consider is, that maybe your MRP run is set up to run without past due buckets. If that is the case the system is not taking into consideration these WO (as you indicate).

You can check this by looking at the time series again (P3413). If the first column is not saying past due, this has not been set up. Making sure that MRP takes into account past due orders is done by checking the processing options of the MRP-version that you run in your batch. It is on the first tab.

Kind regards,

Saskia Wijckmans
Business Consultant
 
Re: RE: Planned Work Orders, Messages and Time Fences

Thanks to all. You gave me just enough hints to figure it out.
We have a multi-branch setup which was esired by Finance. Now they see what a pain it is. The have a branch for every major product line. So there are many transfers (OT) between branches and the warehouse.

Anyway, we only have 5 weeks of firm orders inn a high mix, low volume environment. The buyer (supplier scheudlers) kept complaining demand was dropping in within the lead-time. It was assumed to be th ediffernece between firm and forecast dropping in or that we buy into the warehouse branch and the circuit boards are built in a different branch and the ysomehow wouldn't see planned demand, only firm.

So, each week MRP gave messages to move and cancel which were ignored and MRP had planned expecting thiose actions were taking place. And each week the planner firmed up the planned WO that really wasn't needed. And th enext week the same thing happened until there were more and more WO's. Viscious circle. I had planner cancel all th eopen Wo's for an item, MRP planned properly and guess what? Demand was in synch everywhere. No need to firm WO's before their time.

Next week we will see the results of about 20 more tests (the group is nervous so I'm letting them proceed slowly) and then the next week all WO's get canceled except for two week's worth.

An old MRP guy like me knew better but had to prove it to the group.

Don't know if I explained this well, but th elesson is clear, don't firm orders too early, let MRP do the work.
 
If you are getting mesages to adjust overdue orders, try setting the freeze flag on the orders; this will exclude them from any planning and will ensure all messages generated are for new orders or changes to those in the future.
The advantage of this type of multi-plant setup is the capability to use formal transactions (ST and OT ) for movements, and these work well with bar code scanning systems. They don't work well if the movement between production areas is automated or continuous and there is no desire to capture the transactions
 
Back
Top