Re: MRP600 - BPCS 4.0.02

> We are working with BPCS 4.0.02. To have Y2K ability we have downdated our
>  files for 28 years and are live with this programs since the beginning of
>  April.

>  Since this time we have the problem, that MRP600 put purchase orders on a
>  wrong reschedule date. This problem only occurs, when the purchase order
>  due date is a date in year 2000 or later.

In my earlier posting, I speculated that the problem of enforcing 100% of all 
entries of date sensitive information consistent with 28 years ago, is a 
potential people problem, both inside & outside the company.  You will 
frequently have data entry that inputs contemporary dates by users who forget 
to subtract 28 years, and departments that rebel at sending documents to 
customers & vendors & government agencies that show a date of 28 years ago 
along with some kind of cover document reminding the recipients of your Y2K 
keyhole strategy.

Do your Tax forms report current activity dated 28 years ago?  Is this Ok 
with the feds?
Are your paychecks dated 28 years ago?  Is this Ok with your local banks?
Are your payable checks dated 28 years ago?  Is this Ok with your vendors?
Are your invoices dated 28 years ago?  Is this Ok with your customers?

I think there will have to be some exceptions & you probably understand this 
far better than I because your company investigated the implications before 
applying this solution.  Right?

The easy way around the outside world is to have your data internal to the 
BPCS files back dated 28 years, but all programs that print stuff that is 
going outside of the company, on a regular basis, to be modified to add 28 
years at time of printing.

For BPCS 4002 to work with this strategy you must FORBID any entry of 
transactions or master information that has dates going into 2000 or beyond, 
except in a very narrow range of scenarios that have been thoroughly 
researched to not be a problem.  

Your MRP120 date should be around April 19, 1971, scheduling requirements for 
that vintage, with customer orders, purchase orders, shop orders, and 
associated transactions all back dated 28 years.  No exceptions.

However, humans are falible.  They will write the real date on various 
documents.  People will transcribe the real date from documents that came 
from customers or accounting forms, forgetting to subtract 28 years. 

You need to think about an edit list of EVERY form of human input, to catch 
any transactions dated in the 1990's & 2000's - they probably either should 
have had 28 years subtracted before entry, or not be entered at all.

You might also look at your window for MRP acceptance of the data - make sure 
your MRP120 date buckets are such that anything in the 1990's & beyond is off 
the scale & to be ignored for planning purposes.

You may have a problem with connected PCs because some versions of DOS & BIOS 
cannot pre-date the 1980's.   This could also apply to other connected 
hardware, such as bar code technology, weigh scales, e-commerce.

Al

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