Re: ITH not posted to Gen Led (Was CST600 rollup)

From Al Macintyre

I assume Jim means the change of topic was the good catch, not the actual 
advice given.

Jesus - I gave you some bad advice.
You are on V6, I am on V4.  A lot of stuff is the same but some is different 
& apparently this is one of the different areas.  V4 uses ITE rules to govern 
how inventory gets into Gen Led, V6 has a whole other sub-system that is not 
relevant at V4.

As for the Y N & blank, I doubt that BPCS has a consistent rule of thumb 
accross all settings.  To be on the safe side, if I was you, I would print 
out, or carefully scan, on of the online documents for SYS800 from DOC menu & 
check the settings of Y N blank to see if blank has a consistent meaning, and 
also do F1 help on changing ITE  transaction effects ... INV150 or INV140 or 
thereabouts ... to see if blank has a consistent meaning.  When blank is a 
default for one side of two choices, I would change such blanks to a more 
obvious meaning to avoid confusing the next person studying this.  I would 
not change any settings without massive consultation with other people who 
think they understand what it all means.

On the date inconsistencies, the data goes into ITH, as seen on INV300 F21, 
in the sequence that it is posted, and people's programs normally use today's 
date in consistent Y2K-compliant format.  At Central, we kick everyone off 
every week nite for backup assurance, so there should not be any scenarios of 
green screen signed on with a session date of more than one day old, except 
after weekends, but PCs are now doing emulation simulation off of an external 
(to the 400) ethernet with PCs left turned on continuously - I am assuming 
they get their 400 session date from the AS/400 sign-on & not from the PC, 
but V6 client/server might work differently on that.  In other words, if the 
BPCS software gets the date to use from the session & if the session gets the 
date from the PC & if the PC has the wrong date ... a lot of IFs there that I 
do not know answer to.

We taught our users how to reset JOB DATE months ago to help with Y2K testing 
& I refreshed that for some folks who needed to do last week's transactions 
today ... if you have a bunch of them, it is easier to change the defaults.  
But if you are having transactions going in that are months old, then 
probably either you have human keying error that they do not self-catch, or a 
bug, or a specific scenario that some co-workers know about but did not 
consider it neccessary to include you in the loop of heads up explanation.

There are a handful of scenarios where BPCS defaults to today's session date 
but we need to enter an older date.  If you have one in which the users are 
constantly having to change that date, it probably is only one line of code 
to take out the reset after 1st screen, so that it will leave the date that 
the user last entered.

Before creating a new report or inquiry via query, or starting on a new RPG 
program, I often RUNQRY *N file-name F4 to look at the actual contents of the 
file involved to see what fields are populated in our combination of version 
& parameters.

This is how I stumbled on the fact that a very small number of dates in IIM & 
ITH are not Y2K compliant ... the 1st 2 digits of 4 digit year missing.

For IIM I wrote a program to read in every active item, run every date field 
through a subroutine that checks to see if the date is a valid date, then 
output those that are not - I got tons of hits, but they were all in fields 
that are reference fields, no damage to BPCS ,,, the scenario was something 
we overlooked when converting to BPCS 405 CD.  I plan to do the same thing 
for other files but have not yet done so.

I suspect a bug in some program writing ITH, because our users see format 
mm/dd/yy while internally it is ccyymmdd.

If you are feeling ambitious, it might be practical to write a date math 
program that compares ITH dates in IIM transaction sequence & just print out 
the scenarios of the date jumping backwards, or forwards by more than a 
reasonable number of days.  By carefully selecting fields to include with 
this story, you can see if it is happening more often with particular 
transaction types, particular user & work station.

Some of it will be legitimate, depending on transaction type.  We post labor 
in batches & it should say the date the labor was done, not the date it was 
keyed in.

When we had our problem of ITH not posting to Gen Led, because we ran out of 
Journal Batch numbers, and I got to looking at all the unposted stuff in Gen 
Led work files, I found some transactions with dates way in the future.  I 
suspect that someone was doing Y2K testing in the wrong environment, with 
live data, and on the transition between December & January we always have 
people who key in the wrong year ... it is hard to key the new year when in 
habit of keying old year ... and when you do need to key the old year, it is 
easy to key the current one.

>  From:    bpcsmaynez@yahoo.com (Jesus Maynez)
>  
>  Thanks everybody for the valuable help.
>  
>  The transaction were posted today, it seems like some
>  BPCS (6.04) applications are generating new
>  transactions with old dates. I will have to track the
>  transactions everyday to see what is going on.
>  
>  But, I still have a question.  Several people told me
>  to verify the ITE file and check the GL post flag. I
>  did that, but I am confuse because there are some
>  transaction that have an 'N' and another a blank. Do
>  these two values work of the same way, and they do not
>  post to the GL?
>  
>  Thanks again!
>  Jesus Maynez
>  
>  
>  --- Jim <jcannon@antigua.com> wrote:
>  > Nice catch Mac! Excellent suggestion.


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