RE: Starting up the MRP module -- BPCS-L

Thanks, Al.....this is exactly what I was looking for.  We have enough
issues wiwth the system that I don't need to add more unknowns....

-----Original Message-----
From: bpcs-l-admin@midrange.com [mailto:bpcs-l-admin@midrange.com]On
Behalf Of Al Mac
Sent: Monday, September 23, 2002 1:00 PM
To: bpcs-l@midrange.com
Subject: RE: Starting up the MRP module


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:stagis@fansteelvrwesson.com]
>Sent:   Friday, September 20, 2002 1:20 PM
>To:     bpcs-l@midrange.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 (macwheel99@sigecom.net via Eudora)
Al's diary http://radio.weblogs.com/0107846/
Cure cancer. http://members.ud.com/about/



_______________________________________________
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/bpcs-l
or email: BPCS-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.