In earlier versions of BPCS,
IIM.ITSEQ has sequence # of ITH, within that item, at time of the
transaction.
INV300 uses that ITSEQ to count down to earlier transactions, for which
there are many filters available.
Sequence LOOKS like by date, only if everyone data entry uses same date as
when they key the stuff in.
We should ask how large is that ITSEQ field, and also size of sequence # in
ITH field, and what happens when the ceiling is reached.
During month end, INV900 copies from ITH to an optional file (YTH?) the old
stuff, and resequences what we are keeping, based on how many days to keep,
per ZPA parameters, and whatever date was supplied for month-end (risk of
human error). In the interests of access efficiency, you are probably
better off with an archiving system, of which several are available from
various vendors, like UPI.
We have some reports which list items on-hand, which have not had a certain
kind of activity in several years.
We use archives to support that.
Each end year, I survey all departments, to review archiving rules &
reasons.
If we have customers that cannot pay on time, and take 10 years to pay (we
have had some of those) then we do not want to purge proof of delivery to
them, but maybe we want to purge activity on customers which do pay on time.
If there is a law suit open with a customer or vendor, we might not want to
purge any of the activity associated with the incidents not yet resolved by
the lawyers.
If the IRS does another audit, they can ask for data going back 7 years.
So I ask, in case there's another exception to the reasons I was aware of.
If you manage to delete an item from IIM, which has activity in ITH, then
month end will ignore that item in ITH, until the next time that item is
created, for some other purpose. This can get confusing, when that item
starts its life.
Same principle for invoice #s, order #s, etc. which we have had wrap-around
several times.
Plus for some #s, having zero is not considered by some people as a valid #
to use.
We have also had weird stuff happen with BPCS files when we have done things
with our AS/400 which you are not supposed to do.
My 26 years working with BPCS is ending, but I do not have the stamina at
age 71, to move to another ERP.
Rob answers are dynamite.
Alister Wm Macintyre (Al Mac)
Linked In
https://www.linkedin.com/in/almacintyre
reminds me I hit 30 year anniversary with my day job
Aug 1984 - 2014
However, day job moving to a different ERP
will no longer need my services very soon
midrange.com
