RE: MRP Planning Date

My understanding of the planned start date is this is the date the system
starts the MRP120 bucket for.  For example:  If your start date is Jan 1,
2000 and your MRP120 shows 7 day buckets for the first 26 periods that is
weekly for the entire year.  If your start date is Jan 1, 2000 and your
MRP120 shows 7 day buckets for the first 12 (basically three months) and
then 30 day buckets for the next 8 periods.  That would be weekly buckets
through the third week or so of March and then monthly thereafter for the
rest of the year. So if you are running MRP reports in April - your reports
would have the first bucket as the whole month.  





-----Original Message-----
From: MacWheel99@AOL.COM [mailto:MacWheel99@AOL.COM]
Sent: Thursday, July 19, 2001 3:05 PM
To: BPCS-L@midrange.com
Subject: Re: MRP Planning Date


Our planning periods are a bunch of 7 day periods, then several 14 days,
then 
several 30, and the last one is 999 days.

Why do we reset the planning date each week?

I do not believe I have a satisfactory answer to this question.

Several reasons - most importantly because we have always done it that way 
for the past over 10 years of several different versions of BPCS & never had

occasion to revisit this until you invited us to.  

If it works, don't fix it, unless you really really understand the 
alternatives.

In an earlier simpler time we thought we understood MRP, and we figured out 
the best way to manage it, then the world got more complicated & we may not 
have kept current on all implications.  When we thought we had a handle on 
how this works, MRP had these various windows inside which the data was 
reliable, and people had to read the documentation a gazzilion times to 
comprehend what it all meant.  

My vague recollection was that if you get your MRP planning dates out of
sync 
with your real world of requirements, that some stuff that is really due, 
witll be ignored by MRP, so you have to have your SYS800 parameters & other 
settings & calendars all in sync with each other.  

Like we have people who try to post labor tickets on a Saturday, but that 
Saturday was not in the Shop Calendar as a valid date, but the JIT600
accepts 
that date.

And we have people who try to release shop orders on a weekend that happens 
to be the same weekend as Fiscal end month but the GL is now closed for that

month.

If they do the transactions dated correctly, and BPCS accepts the data, it 
retrofits the opening balance for the month.

You have to have all these calendars in sync & people have to know when they

get the error messages which calendar is objecting to them.

In these modern times no one reads the documentation any more.

So the BPCS rules may have changed between versions & in the absense of 
redoing our education in the BPCS rules, we are still operating by the old 
rules on the new software.

We started using the MRP planning periods for other functions than BPCS 
provided, primarily in a report we call our Weekly Production Planning 
Schedule Summary, although it is primarily from Customer Requirements 
perspective.

It has columns corresponding to the contents of the different MRP120 buckets

& the totals are all requirements for end customer parts, sorted by
facility, 
customer, item & some other nuances.  All past due is lumped into first 
column with date of the oldest ingredient there.

We are make to order, with a lot of repetitive business, and customers that 
change their due dates & quantities due, on pretty short notice.  Our lead 
times need us to be able to fulfil customer requirements without expediting 
raw materials in the door to satisfy these rapid changes in requirements & 
the parts we use are common across many customers, so that if one customer 
sabotages lead times, there is the risk that we end up using raw materials
on 
that customer that were ordered in plenty time for another customer.  

Keeping track of all this is such a nightmare that management basically set
a 
mandate - customer service is not to accept changes to customer orders
inside 
a certain planning window, but unfortunately the lead time situation is not 
consistent on all parts & well that is another post to explore what can be 
done to improve that visibility.

When we learned about the past due stuff not being planned, we had a short 
experiment in deliberately using a past due planning date, so that MRP would

plan stuff that it would not ordinarily plan.  This scheme was shot down by 
the Purchasing Dept because they did not appreciate past due stuff showing
up 
by surprise in the MRP.  Before it got shot down, I put the Master Schedule 
Report on a separate Planner Code so that it would not conflict with these 
experiments.

We are now back on the MRP & the Schedule report using the same MRP120
rules.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
AS/400 Data Manager & Programmer for BPCS 405 CD Rel-02 mixed mode (twinax 
interactive & batch) @ http://www.cen-elec.com Central Industries of 
Indiana--->Quality manufacturer of wire harnesses and electrical 
sub-assemblies - fax # 812-424-6838

---- Prior Message ----
Subj:    Re: MPS
From:   Lisa.Abney@sensient-tech.com

OK, Mac, I have to ask!  Why do you reset the planning date each week?

>We use one of our own menus in which the menu screen reminds people how to
>fill out the MRP prompt so that regien / net change will come out right.
We
>do MRP120 every Friday nite to reset planning date for Monday of the
calendar
>week.

We reset the start date to the current date on the first day of the year
(and I think we only had to start doing that sometime in '99, when we
started to get some Y2K issues).  The rest of the time, we have four 7 day
periods, ten 30 day periods, and the rest 1 day periods.  What does
resetting the date do for you?  (Knowing you're on the same version as us,
I'm always curious if I might be missing something!)


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