RE: MRP540---why??

99/99/99 is in actual fact valid when selecting a date range. We use DDMMYY
in BPCS CD REL02 and it works fine.
See below an extract from our BPCS Users Manual. This info would have been
obtained from the release documents.
Date Processing in BPCS CD
All Screens and Reports show a 2-digit year. To process dates correctly
there is a system parameter called Century Break Year. This is set to 40.
All years less than 40 are processed as 20xx years. Therefore year 2000 is
entered as 00 and as this is less than 40, the system processes and stores
it as 2000. Similarly 1999 is entered as 99 and this, being greater than 40,
is processed and stored as 1999.

There are 2 exceptions to this rule

0/00/00 which is treated as valid and is processed and stored as Year 0
99/99/99 which is treated as valid and is processed and stored as Year 9999

Some Reports and Inquiries have the following Defaults:-
Lower Date Range 0/00/00
Upper Date Range 99/99/99

Some Masterfile Maintenance Programs have the following Defaults:-
Effective Date 0/00/00
Discontinue Date 99/99/99

Where required, these dates as entered as 000000 and 999999 respectively.


        -----Original Message-----
        From:   MacWheel99@aol.com [SMTP:MacWheel99@aol.com]
        Sent:   22 June 2000 20:47
        To:     BPCS-L@midrange.com
        Subject:        Re: MRP540---why??

        The date of 99/99/99 is NOT a valid Y2K date ... BPCS selection
criteria for 
        date ranges often start with default 00/00/00 to 99/99/99 but users
need to 
        know to key in a valid range if they want valid results.  It looked
like to 
        me you were selecting from June 21 of this year to the end of last
year & it 
        should have told you that the start date needs to be below the end
date, but 
        some software does not check for that nuance & just selects nothing
because 
        when dates are in wrong sequence by definition nothing falls into
that range.

        Marc mentioned checking SYS800 to check your date format ... we also
use 
        MMDDYY ... you might also check your Y2K-compliant windowing ... our
cut-off 
        is currently 1940-2039 for both BPCS & AS/400 in other words our
year 99 is 
        really 1999 - what's yours?  There is a WRKSYSVAL to get at the IBM
setting.

        In past threads here we have also addressed issue of lead times into
the past 
        ... MRP cannot plan requirements which are past due at time of
entry, or in 
        which the BOM effectivity date is that of when the part was entered
to the 
        system but MRP planning would go into the past.  Also if you have an
MRP plan 
        for a specific date & you release an order for that date, then the
original 
        requirement changes, MRP will not plan for the change because you
have firmed 
        up the dependencies on the old date.  Confusing - Yes, very.

        >  From:    Qin_Huang@schindler.com (Qin Huang)

        >  Dear all,
        >  
        >  
        >  Check from KFP I could find a record fprod='642511SML244306' 
        >  with planned and release date,
        >  however when I enter 642511SML244306 in MRP540 
        >  and press 'enter',
        >  it replys me that no plan in the arrange date, which the date
range is
        >  '00/06/21' to '99/99/99', how could it be possible?
        >  
        >  thanks and best regards,
        >  hqin

        On the topic of item #s that are ASKING FOR TROUBLE

        Our end customer item numbers are in fact the part#s of our
customers, for 
        ease of tracking when customers call in with questions & for ease of
using 
        our BPCS reports on selected item # ranges to share directly with
customers.  
        Occasionally a customer has the same part # as another part #, is
using one 
        of our official part #s for the stock stuff we make as their part #,
and some 
        customers have part #s that are in excess of the number of
characters that 
        BPCS allows for an item #, but fortunately these scenarios are
exceptions to 
        our general rules. 

        This means, however, that our part numbers tend to have a mixture of
numeric, 
        alpha, and special characters, that are very easy for people to
misconstrue, 
        and this is not just item #s, we also get it with customer PO#s.  We
have 
        some customers in which their item # is a variable number of digits
& we key 
        in items to alpha field left justified which means lists of their
items are 
        not in numeric registration or in numeric sequence.  People need to
know in 
        advance what a policy is letting us in for & make sure all new
people 
        understand these nuances, such as collating sequence with upper
lower alpha 
        characters & numeric is not same ASCII (PC) & EBCDIC (AS/400).

        Al Macintyre  ©¿©
        http://www.cen-elec.com MIS Manager Programmer & Computer Janitor
        +---
        | 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
+---