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

Thanks again for all your help!
I'm working with all the information you have given to
me. I let you know when I get this done.

Thanks!

--- MacWheel99@aol.com wrote:
> 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
> +---
> 

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.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
+---