× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: MRP Planning Date
  • From: MacWheel99@xxxxxxx
  • Date: Thu, 19 Jul 2001 16:04:47 EDT

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

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-2024 by midrange.com 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.