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


The transactions with old dates are generated by BPCS.
Not all the programs take the the system date to
populate the transaction date field in the ITH. This
field is populated sometimes with the user entries. We
are thinking on create a program that identifies new
transactions with dates out from the current period.

Thank you to everybody for your help.


--- Jesus Maynez <bpcsmaynez@yahoo.com> wrote:
> 
> 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
> 
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Talk to your friends online and get email alerts with Yahoo! Messenger.
http://im.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
+---