Re: MRP Effectivity Dates

from Al Macintyre

If you do not number your end parts like we do at Central, then you might 
have some alternatives to Gordon's date x - 30 approach that will not work 
for us.

Our end item number is the same number as the customer part number, which 
simplifies things no end when communicating with the customer.  We 
manufacture wiring harnesses, which tends to have sub-assemblies approaching 
the final part that are uniquely for the customer, and we are able to use a 
number system that starts with customer part # & has tacked onto the end some 
information identifying the sub-part & this also simiplifies review of how we 
are coming on customer parts that approach completion, or when questions go 
from customer service to production shop floor regarding status on some 
customer part.

Due to the complexity of the parts, and the sequence in which lower levels 
are combined, even though the same lower sub-assembly might show up in the 
wiring harness in multiple locations & have the same effectivity date rules, 
the reality is that some portions of the harness will normally get finished 
some days earlier, so we want effectivity to flip on all aspects of a part in 
production in concert, but we cannot predict how much of the work will be on 
same days or off by a few days ... these rules apply to this whole part, 
which is not exactly how BPCS effectivity dates are designed to work.

This means that when date x arrives, someone has to know that date x has 
arrived & that certain action needs to be taken with respect to MRP.  When 
stuff is going on with multiple customers & parts it is easy for 
inter-personal communications to drop some details.

If the part numbers were not so locked into customer number system, then it 
might be a simple matter to do same-as-except pair of paths ... apply 
effectivity to which of two designs from the end customer part #, in which if 
some sub-assembly is called from the parent effectivity all the children 
start out being x-30 effective.

We sometimes handle some repairs this way.
CUST-X123 is the regular part BOM
CUST-X123-R is the REPAIR ... in which most of the materials are Ok, we just 
need to make some changes here & there, so CUST-X123-R has CUST-X123 in its 
BOM along with the adjustments, and human beings need to carefully walk the 
right parts through the system, since the CUST-X123 that entered the system 
through an RMA from the customer is not inventory that we want to ship back 
to them with the weekly supply.

That concept might be used temporarily in which various parts are identified 
CUST-X123-reference#-code designating old or new revision, but we are close 
to running out of length of item # for one thing, and one of our bottlenecks 
is getting the engineering work done on new business, so we do not want to 
complicate any department any more than is neccessary.

We also have the concept that for some departments, setup is 10 minutes while 
today's production needs is 2 minutes to run, so there is the temptation to 
run a week's needs on the latest setup.  That could be a problem if there is 
an engineering change in the works.  The inventory tags accompanying WIP need 
to show which version this was made at, but 95% of the time this is not an 
issue.

Bottom line, we cannot let MRP run the whole show, there has to be human 
intervention to massage what we are doing with parts in production & planning 
when an engineering change occurs on those parts.

We have not considered Effectivity Dates to be a big deal for us for MRP, 
because when there is an engineering design change, someone is on top of 
monitoring our old inventory & when to switch to the new version.  Our 
current concern is why we sometimes have new customer parts in which MRP does 
not properly plan them the first time out, and some people's behavior has 
been based on an understanding of what is going on, that is not what happened 
with the latest scenario, so how many other combinations are out there that 
we are not properly reacting to, because some people falsely believe there is 
only this scenario & that scenario.

> Subj:  Re: MRP Dates Education & effectivity dates
>  From:    gordon.coen@abbott.com (Coen,Gordon)
>  
>  Hi folks,
>  
>  AS400 6.0.04 MM
>  
>  I have been reading your ideas on back dating the effectivity dates on the
>  BOM. We currently do the same because we noticed that effectivity dates 
were
>  causing problems with requirements , especially where offsets are used. 
>  Am I the only one who would expect the effectivity date to function in 
> conjunction with other BPCS functionality ?
>   As it stands it leaves us with a situation where the BOM can be keyed
>  with an effective date of x. Then when x arrives we have to go back in and
>  set the effective date to x - 30 (to back date thirty days). This causes
>  major change control issues as our process is very tightly controlled. Does
>  anyone out there have a better way of getting effectivity dates to work 
????
>  
>  In hopeful anticipation,
>  Gordon. 

>  Subject: Re: MRP Dates Education
>  Harmon Zieske

>  Al,
>  
>  There could be several sources to your problem, 
>  but the most likely is that the first few times the item is planned
>   requirements are getting created earlier
>  than the effectivety date of the components on the BOM. 
>  The BOM effective date defaults to date of entry. 
>  If in planning the parent, the components end up
>  being scheduled before 'today' and the bill was entered today, 
'effectively'
>  no components exist and nothing will be planned. 

My engineers checked out BOM dates on the latest challenge - thanks for the 
suggestion by the way - and they said that was not the problem on that part - 
however we have more than one engineer & there is the risk that variations in 
entry practices could lead to one person's input having this flaw while we 
check out other input & conclude that we are not at risk.

>  As you screw around and plot and plan, and days go by 
>  and the MPS horizon pushes orders out further, suddenly
>  bills become effective and planning works, 
>  I doubt playing with planning dates has anything to do with it. 
>  If you just back date the effective dates of new
>  assemblies you should be fine.

Well playing around with planning dates solved our latest mystery, but as I 
stated in an earlier posting, MRP 500 & 600 is not the only place that 
defaults to the "M", so my current plan is to MRP120 to a month ago, then 
launch the 8 jobs (by facility) then reset MRP120 to current week & do it 
that way because I am sometimes plagued with el typo ... if I oops on MRP120 
a lot easier to redo there than oops on MRP 500 600 what date did I launch 
again?

>  The default of today for bill changes is entirely reasonable. 
>  However for new assemblies the default should be back dated 
>  to prevent the chaos you are seeing.
>  
>  Harmon Zieske
>  Nexgen Consulting

Oh, we also have a modification ... we produce in 2 warehouses at each 
facility ...end items for shipping are manufactured in the end items 
warehouse, while raw materials (item type 2) are manufactured in the WIP 
warehouse.  Now BPCS puts everything in one default warehouse, so immediately 
before running MRP500, we run our MRP80W modification that fixes the 
warehouses in CIC & KFP files, so our humans do not need to futz with this 
before launching new production orders.

Al Macintyre
BPCS 405 CD for 4 facilities
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---