INV900 Oops

[Al Mac <macwheel99@xxxxxxxxxxx>]

I am looking for suggestions while I struggle looking into some things.
We are BPCS 405 CD

I work nites and this info was as of what I figured out last nite

Last Friday night most of the EOM was done, finishing up Saturday 
Morning.  I was long gone from the system.  Monday I was informed that 
something went wrong with INV900, know not what exactly.  The hope is that 
we can do June transactions almost like normal, then some recovery effort 
in the next EOM.  What I expect is that there will be NO May totals in the 
system except any reports accounting ran from MTD perspective and from 
files not affected by INV900, so the total sales for JUNE will really be 
MAY plus JUNE combined, and some files will be out of sync with each other 
for MAY JUNE.  Thus it might NOT be SMART for me to run the weekly files 
REORG until I have a better grasp of what files went thru EOM Ok, and which 
will have a double month next EOM..

This means the new sales reports that I developed last month with Y"all 
help should be considered as trash for now, and the AMP TYCO report will 
not be available for another month.  AMP TYCO is one of our vendors ... we 
send them a monthly report on how much raw materials we ordered on behalf 
of each of our customers, in which the data is computed using combination 
of BOM and Sales History.  Well I consider Sales History to be the same 
value as GARBAGE until I figure out what is Ok.

WRKOBJ INV90* gets at a list of related INV900 major steps
8 (eight) enter scroll second screen shows DATE last time that program was used

The following were last used end of May (last Friday)
INV900PM (prompt screen)
INV900C (Main CL from menu)
INV903 (I think this is involved in the cycle count clean up at the start 
of INV900)
INV903O (report associated with cycle count distraction at very beginning 
of INV900C)

The following were last used end of April (a month ago)
INV900 (main RPG program)
INV904 (Rel-2 version)
INV901C (I think this runs close to the end of the whole operation)

According to SSARUN03, the files that INV900 messes with are
IWM IWI ILI RCM SSM SSH SSD ITH and I know that is not a complete story and 
that we do use ACR900, but I have lots of clues to explore

Some of these files are updated during the course of daily transactions, 
while some only EOM hits.  I happen to have been messing with RCM Friday 
before EOM due to placement of customers on a report sequenced by customer 
name.

I know from past experience that YTH file contains copy of ITH transactions 
cleared off in the previous EOM.  Our YTH file is empty of records (DSPFD 
list members ... the date not help me ... my speculation is that when a 
file is cleared, that does not alter the date of last change, it is only 
adding or changing records that updates that).  We used to write off last 
month records to tape, not do that any more, I not remember when that 
policy changed ... that could be why January 2003 is date of last change of 
YTH.

I have some software off GO CMDSCDE that I not check every week, but from 
it I see that our ITH Inventory History file had
1.330 million records as of a week before EOM
1.347 million records as of late afternoon of EOM (before final shipping 
and some other transactions) = 17 thousand added in the 4 day week
1.347 million records (about 500 more) first thing Monday morning
1.350 million records Monday evening (3 thousand added during Monday)
This tells me that the INV900 did not clear off the records older than our 
SYS800 system parameters (should be 365 days ... I still need to check to 
make sure no one mucked with that) so I know INV900 did not get to whatever 
step where that happens
It also tells me we have not lost anything valuable records wise

There are some files updated by EOM that I not sure if they supposed to get 
updated each day ... some of them supposed to have MTD data like last 
shipment, but I not know when that data goes in
SSD & SSH Sales History files last updated last Friday EOM

Now unless something other than INV900 updates them, this tells me that 
INV900 successfully got through at least part of a step ... but I still 
need to look at MTD, month 01, etc.

I expect these files to change every day and they were in fact last updated 
Monday June-2
IIM Item Master
ILI Inventory by Item Warehouse Location
IWI Inventory by Item Warehouse
RCM Customer Master

I am not sure what all updates these  ... they were last updated Monday June 2
IWM Item Warehouse Master
SSM Salesperson master

I ran a list DSPFD all files when last changed.  I only looking at some of 
them.
In most cases the date last used is same as date last changed.

Some weird ... RMAs last changed Mon June-6 but last used Fri May-30
When I not regularly look at some things, I not know what is (ab)normal

The menu launches INV900C whose CL uses a lot of soft coding, so it not 
obvious what job calls what job.
-
Al Macintyre
BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/

> From: Al Mac <macwheel99@xxxxxxxxxxx>

Forwarded from the office


> Will do.
>
> You may recall that the reason we not want people doing BPCS transactions 
> on the weekend of EOM is that with an EOM date of SATURDAY, that if you 
> finish FRIDAY nite then someone posts transactions DATED in the fiscal 
> period you just closed, BPCS treats those transactions as if they had in 
> fact gone in the month that you just closed ... altering opening balance 
> ... which Mike discovered by seeing that Opening Balance of CSTOPS had 
> changed during course of month.

I checked ITH date ranges ... nothing got posted dated Saturday or Sunday.

> But what you describing sounds OPPOSITE scenario.
>
> There is another wrinkle ... if someone enters transactions LAST MONTH but 
> DATES them into the FUTURE, BPCS does not include those transactions in 
> the EOM.  We have had a scattering of that kind of scenario in the past, 
> and I did not know all the implications of such activity.  Using a wrong 
> date on BPCS transactions can occur through human error, where the user 
> not realize what they doing, and they can occur through human 
> misunderstanding of the role of date in BPCS transactions.
>
> INV900 normally takes SEVERAL HOURS to do its thing, but Mike did have a 
> change in procedure a few months ago which would have somewhat lowered the 
> run time, but I still expected it to take several hours.  I did ask him to 
> track how long various tasks take, and update his check list.  It may be 
> that some things have changed significantly in time duration without his 
> check list reflecting that.
>
> It is not just inventory opening balance that INV900 updates, also stuff 
> related to sales history files.
>
> What I fear is that the job ended normally in IBM terms but abnormally in 
> BPCS terms such that there might not be an IBM JOBLOG with clues.

There was no job log for me to examine.

> > Al,
> >
> >
> > Mike had mentioned the month end close on INV900 ran quickly.  I don't 
> > believe it ran correctly.  Items show activity in the MTD totals now when 
> > they should only show an opening balance.
> >
> >
> > I don't think this will have an impact on operations, but it might create 
> > problems at the end of this month.  Please investigate this when you get in.
> >
> >
> > Thank you,
> >
> > Tim
> >
> >  -
>
> -
> Al Macintyre
> BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/
> Find BPCS Documentation Suppliers 
> http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html