Here's Another gotcha: Let's suppose customer orders were entered based on proper lead times so MRP plans your stuff correctly, and let's suppose SFC and PUR orders are released based on MRP advice, and let's suppose the customer then calls to pull up when they need the parts sooner. If you are running MRP properly, you see the firm planned production (SFC order) needs to be finished sooner for the final part, but MRP does not yet say that the sub-assemblies need to be expedited, because the customer order (needed sooner) drives the end part production order's MRP recommendation that it should be made sooner, but if that end SFC order does not get changed, then the lower sub-assemblies of that end SFC order are driven by the SFC order planning, not the end customer order due date. This can have serious impact on PUR getting the correct materials in on time. Suppose you change the end SFC order (we have a Query/400 list of all SFC orders that need changing) to agree with the customer ORD changed date, this changes nothing in your system (such as shop paperwork already printed with the old due date) until you rerun your MRP, at which point all your orders that are requirements of the end SFC order are now recommended for an earlier date of completion. What you need to do, if customer order requirements tend to fluctuate, is not release MRP planned orders as firm planned orders until shortly before actual production due, so you not have to be constantly adjusting orders released a week or two in advance. Have a Query or other report listing released orders whose due dates need adjustment, carry out the recommendations, run an MRP net change to apply what you did. Repeat the last sentence until there are no more recommendations. Think about a modification to automate this. By exploring the K* files you can find out where the coding is stored for exception messages, and create your own reports that exclude stuff with only a few days change. Manipulating this in Query/400 can be a bit of a pain because if MRP cannot suggest a better date, the MRP date is all zeros. Note that MRP date of all 9's means MRP suggests this order be canceled. Our Query have separate selection for all 9's (cancel these orders) all 0's and some specific date, against which we do date math. I had thought the purpose of Effectivity dates in BOM and Routings were for Engineering Changes to be planned through MRP with a date that a new version might come into effect. We do not actually use that feature because for our customers, when they do a model change, they want the switch over RIGHT NOW, which means we have to inventory where we are in production on the old model and discuss with the customer if they want us to wrap up that in what quantity, how much of it is practical (low cost) to switch to the new model. Fortunately SFC can track multiple different models where BOM has one official version. When we have new customer business, in which actual orders are not given to us until the customer approves our samples, then when that happens, they want their orders yesterday, we use customer's estimated annual usage in a forecast with order type that actual orders will consume the forecast. The purpose of this is for MRP to drive PUR to stock up on the raw materials needed for the new business, so that when the samples are approved, and the orders placed, we not have to deal with long lead time to get the raw materials. Mitch wrote in part:
* MPS and MRP calculations do NOT consider expiration dates on inventory lots so that if all of your inventory is about to expire MRP will NOT tell you to order more. * The exception messages tend to be a lot of trouble because there is no sensitivity setting. You tend to get a lot of move in / move out messages that only change the delivery date by a day or two. * Ignores orders entered in to a past due date as Al Mac points out. * There is no functionality to allow for stock based substitutions or engineering changes. I hope that this helps but the most important thing is to make sure that the users are fully aware of what each of the planning codes is intended to address, not only mathematically but functionally as well. APICS education can be a great asset at addressing this issue. Mitch Damon, CPIM Planning Systems Manager Agrilink Foods, Rochester NY (585) 383-1070 ext. 250 -----Original Message----- From: Rob Stagis [SMTP:firstname.lastname@example.org] Sent: Friday, September 20, 2002 1:20 PM To: email@example.com Subject: Starting up the MRP module I'm on V4.05CD. We've never implemented MRP, MPS, etc., etc. We are using SFC, PUR, INV, ORD in a 1960's type of computing environment and I've been charged with starting MRP up and using it. We manufacture carbide cutting tools - buy a piece, grind on it, maybe do an outside service to it, inspect and shelve (or ship) it. We have some extremely knowledgeable manufacturing guys who can interpret MRP terminology and, with my assistance, convert it to BPCS-speak. My question is are there any unexpected gotchas in MRP? Will I come in to work one morning to be greeted by irate users, upset management and the always dreaded pink slip? Thanks in advance Rob Before posting, please take a moment to review the archives at http://archive.midrange.com/bpcs-l.
Al Macintyre (firstname.lastname@example.org via Eudora) Al's diary http://radio.weblogs.com/0107846/ Cure cancer. http://members.ud.com/about/
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.