Re: ITH transactions of the type #

There are additional scenarios in which we might want to add something to ITH 
history or something similar to some other history that is not as busy ... 
there are changes to cost that do not get into any history that we see ... 

Last year we had a previous level cost in one item that was more money than 
the entire gross money of our corporation since founded in 1953, and now we 
have some previous level costs that are negative 0.0001 - we clean them up 
then more arrive - we need some kind of trigger notification of where they 
are coming from.

if you look at a CST600 audit trail it is pages & pages of identical story 
... I would like something that for the 1 line in 100 pages that is a change 
to the standard history, write like # with comment that CST600 changed 
standard cost here

Our CST900 is 25,000 pages of detail in which the vast majority is within 
some reasonable norma, then boom, if we have not gone blind wading through it 
first, here is an actual cost change that is obviously totally bogus ... we 
want some way of getting right to the bogus information without wading thru 
thousands of Ok entries.

>  From:    bpcsmaynez@yahoo.com (Jesus Maynez)
>  
>  Has someone solved the interrogant of why these
>  duplicated sequence numbers are generated?. I called
>  SSA once about this problem and they told me nobody
>  report that issue before. Now, I see I'm not the only
>  one who has the problem. 

Do they happen at sites that have not done any modifications adding stuff to 
ITH?

When it happened to us, it was because we had added a program to add a new 
kind of transaction to the history to help better illuminate certain 
scenarios on the INV300 history & well I am not as good a programmer as I 
thought I was ... I made a mistake ... then when we did the testing, we were 
not as good as we thought we were there & we did not catch it ... then when 
we went live we discovered my mistake but it was too late, so I wrote another 
program to fix the numbers, and fixed the original mistake for the next time 
that program ran.

That kind of scenario needs to be eliminated from the equation.

Incidentally, we did not report that to SSA help support because we 
recognized very rapidly that the data was screwed up due to one of our own 
modifications.

>  From:    tony@jackocsi.karoo.co.uk (Tony Jackson)
>  
>  I have seen this problem occur in three ways.
>  a:..duplicate ela record caused a pick confirm to write mulipltle records
>  taking tseq above 99,999.
>  b:..to much history causing tseq to go over 99,999 records.
>  c:..a canned month-end on inventory.

Thanks - I now plan to do a query against ITSEQ in IIM sorting so biggest # 
on top & display it ... first screen should show largest # of any of our 
items so I can see if we are at risk of B ... but how do we deal with the ELA 
risk other than what we now do with a weekly reorg of it?

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