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

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 []
Sent:   Friday, September 20, 2002 1:20 PM
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


Before posting, please take a moment to review the archives
Al Macintyre ( via Eudora)
Al's diary
Cure cancer.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.