× 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: MRP600 - BPCS 4.0.02
  • From: MacWheel99@xxxxxxx
  • Date: Tue, 20 Apr 1999 12:58:41 EDT

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

If I understand this strategy correctly, for every date in reality, like 
April 1999, your users are supposed to subtract 28 years at time of entry & 
actually key in April 1971 & when anyone sees a date on a document, such as 
an invoice or shop order, they are supposed to mentally add 28 years ... so 
for example when you send a purchase order out which really has a real due 
date in say March 2000, the system prints that it is due in March 1972 & you 
have added some pre-printed alert, or enclosure with all documents to folks 
outside of your company to let them know what you are doing, so that everyone 
knows to add 28 years to what is printed.

Have I correctly stated the scenario?

Am I correct in stating that everything in your system is dated April 20, 
1971, when the real date is April 20, 1999.  This includes all dates entered 
into the system some time in the past, and all dates anyone subsequently keys 
in, such as customer cash payments, invoices due, labor tickets, inventory 
transactions, customer requirements, shipments, etc. & that to help automate 
part of the process of people remembering the 28 year shift in data entry, 
you have your AS/400 system date also back dated 28 years.

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

If your data is for the 1970's (28 years ago) & a purchase order is for a 
date in year 2000, that sure sounds to me like someone forgotten the 28 year 
rule - or does your company really have 29 year lead times?  If so, perhaps 
you should have gone with 56 years ago as your keyhole.

It sounds to me that someone who should have subtracted 28 years before 
keying in some transaction, forgot to do so so.  Policing this is going to be 
a challenge.   We can make some suggestions - I think it is a combination of 
a people reminder process, and some kind of checks & balances to inspect 
recent entry to catch over-sights.  A starting point might be in those files 
that contain a date of entry from perspective of your AS/400 system date of 
1971 showing the simulated date of entry, and do date math vs. the date the 
user keyed in as customer order, or labor tickets or ship date or whatever, 
to catch anything with several years variation, then have the people who made 
the mistake in keying the correct date instead of the simulated date, work 
with whoever has to fix it, so that helps them remember not to make that 
mistake again.

There will almost have to be daily reports on every kind of date sensitive 
input to catch such oversights by employees who forget to adjust for your new 
calendar.

You may have a problem with connected PCs because some versions of DOS & BIOS 
cannot pre-date the 1980's. 

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


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.