Re: MRP Planning Date

> From:   Lisa.Abney@sensient-tech.com
>  
>  OK, Mac, I have to ask!  Why do you reset the planning date each week?

Either you doing this wrong, or we doing this wrong, or there are only so 
many possibilities so it is worth checking out.  I took a few minutes tonite 
to read the relevant MRP on-line documentation.

What you are doing is having your MRP planning date frozen in time, which we 
are not doing.  I mentioned in my last post how this means that past due 
might be a problem for you different than how it is for us, and the business 
about effectivity dates, such that if you do change planning date with each 
year end fiscal you could lose a bunch of data depending on how you handle 
effectivity dates on new parts.

Did you know REL-02 has some Y2k fixes not in PTF-1 & there's even more after 
REL-02?  I can dig the list up from our BMR notes if need be but I also 
vaguely recall you saying you used an alternative Y2K solution to the CD 
approach.

According to BPCSDOC, the planning horizon is MRP120 date plus your horizon 
days ... our horizon days are one & would be zero if SSA supportdd that, and 
there is a limit of 200 planned orders per item ... I did not dig deep enough 
to see if that limit is for each date we slide through or aggregate for all 
WIP.

It is possible that you are doing other things different than us in addition 
to how you handle planning date & by identifying what that is we can 
illuminate what we need to know to improve our respective operations.

          O U R     S T U F F
          ==============
I do not pretend to be an expert on all of this.

We use "by facility" mode for
BOM & Routings
Costing
MRP & CAP
All kinds of orders
Inventory

We always do MRP500 immediately followed by MRP600
We always let dates default to MRP120 date
We alsways clear planned file when doing full regen
We never do it on net change

We do full regen EACH facility every week nite
We sometimes do a net change at lunch time

Our demand code is
1 Greater of Forecasts and customer orders
Our customer orders consume forecast

Our planning horizon is 
one day (other)

it would be zero if BPCS allowed that because we do not want a frozen 
(wasted) safety period ... if a customer calls in an urgent requirement, we 
start work on that THE SAME DAY, provided no problem with raw materials, and 
have been known to accept a change to a repetitive order in the morning & 
done an emergency air shipment (at customer expense) of the finished product 
that evening.

Repetitive is one period planning horizon ... we not using repetitive but we 
do have customer orders that are LIKE repetitive

We keep this in SYS800 not by item

We ignore horizon for phantoms
We do not manufacture phantoms

We use phantoms for things like ENGINEERING CHANGES
so people can look in BOM & see exactly what the revision history is on a part

& I just recently suggested that we start a new kind of phantom called
PRICE CHANGE HISTORY that would record the date a price change is approved by 
a customer ... reason being that some customers are slow to update their data 
bases with an agreed upon price change & then this causes a hassle with their 
payables department matching our invoices

We do not use FPO's
we use PO's & SO's & RO's for that purpose

We do not include planned orders as schedule receipts
We do not prorate forecasts

Our time fence is
20 periods for repetitive which we not using &
366 days for other MRP

BPCS DOC says that planned orders and MRP reports use time fences and demand 
codes effective from the MRP120 planning date, not the system date, while 
MRP300 & other inquiry relects today's system date position.

Our MRP & DRP period sizing is 7 days
but I would not be surprised if there are item overrides

As far as I know we are not using yield or scrap factors.
We used to allow for 2% scrap on BPCS/36 but had to do modifications to 
circmuvent BPCS netting, where it launched orders to replace assumed scrap, 
where we replace scrap in process os final to customer should be exactly what 
they ordered.

Our safety stock is for raw materials only
We have discussed the possibility of safety stock for high volume common 
sub-components and where ratio of setup time to production time is 
particularly costly.  But this idea was never approved.

We do "L" multiple issue allocations because we often launch shop orders that 
will use sub-assemblies that have not actually been manufactured yet, because 
our production involves overlapping operations ... operation 100 might be 50% 
done with the output from it into operation 200 concurrent at 25% done with 
its output into operation 300 which is 10$ done & so forth & we also doing 
the same kind of thing with sub-components with discrete item#s  We do not 
wait until some shop order is finished before we use its output in a later 
step.

Our usage factor is 0.20
Our annual holding cost is 14%
We put standard cost into our GLD

We do not use Order Policy K
I was intrigued by that when checking up this documentation
Can that be used without having Repetitive DST/12/13 installed?

Again, I am NOT an expert on all this, but from this list we can see what 
United Flavors doing differently from Central Industries & perhaps other 
folks, which might explain how we can do a better job with our respective MRP.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)


+---
| 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
+---