If we assume that the live data has errors, while the test version is
correct, then it should be possible to do some data comparisons between the
two sets of files and software to identify what's different. Perhaps the
test environment has last year's version of some software, that got
modified in the live, but the modification was not properly tested to
include physical inventory scenarios.
You can use PDM/54 to compare two different versions of a program.
You can also use it to compare two different versions of some file.
Depending on your selection criteria, you get at a list of the differences.
In our case we have the original BPCS software, and our modified version.
You can also dump objects to an *OUTFILE then query the externals to find
out when the software was last changed.
Here are some problems I have encountered over the years which can mess up
the physical inventory process, but it is grasping at straws to say that
any one of them is in your situation.
We IT people can be inexperienced in what various things are supposed to
look like under normal circumstances, if we do not often work in those
areas, thus when a problem arises & we looking at data, we can misconstrue
what is normal, and what is wrong.
Sometimes there are errors of such a low intensity that no one notices,
thus when we do notice, we think we just did something wrong.
Our UPS battery ran dry & we did not notice, this meant that some BPCS
files got corrupted when we had ordinary power outages. Since you have
been able to do a full backup, that is not one of your problems.
We are supposed to have transactions entered with today date of
entry. Some people use post dating, advance dating, using other than the
default today date. When they do so, they sometimes have keying
errors. When the error creates a transaction that is outside current
fiscal month, all sorts of other problems can happen with proper processing
of that data.
Sometimes new releases of BPCS fix problems of earlier releases, and
sometimes earlier fixed problems re-appear. In a version of BPCS prior to
our current one, there was a problem with the reorganization process.
What is supposed to happen is ILI has the greatest detail, which gets
written to IWI then IIM more and more summarization. The bug was that it
was being driven by detail in the detail file. Suppose the detail file was
zero balance or null (no record at all), and the summary file had some
content. In the flawed reorg, no action occurred for the item that was
zero or missing from the detail file.
What we had to do was identify discrepancies across files, where the detail
was zero, make a dummy transaction to say quantity one there, then do the
reorg, then reverse the dummy transaction.
Original SSA software, and our modifications, cannot always think of
everything.
There can be some kind of crash that messes up how IIM keeps track of ITH
records to be displayed on INV300. For example, there is an upper ceiling
on that IIM field for # of ITH transactions ... are you anywhere close to
the maximum on your more volatile items?
We have had human error posting inventory transactions after INV900 in EOM
which recalculates opening balances, and INV650 which posts physical
inventory tags replacing the opening balance. This does serious sabotage
to veracity of physical, and to INV300 clarity. Although you say test
environment is correct, depending on the cause of the problem, some items
can look correct, some look wrong, and you looking at the ones that are Ok.
If there have been no transactions since the physical, thenthe new opening
balance from the physical tag (assuming you only have one tag for each
combination item location) should in fact be the new on-hand which in
INV300 F21 it should calculate backwards.
I have been on BPCS V6.00.04 since March of '99. This is a first. If you
have ANY ideas, please reply.
We had a physical inventory on March 30, 2007. I posted the inventory on
April 2, 2007. Our company made the decision many years ago to not print
inventory tags out of BPCS but to simply locate all of the inventory,
write tickets and enter them into BPCS. Before posting the physical the
opening balance in the ILI is set to ZERO for everything. This way
everything starts at ZERO and then the tags that were entered and posted
are reflected 1 to 1 as the opening balance. We then run ORD970 to update
IIM from the ILI file. Again, this process has worked without fail since
March '99.
This month, however, the system seems as if the system is totally
ignoring, in some cases, the opening balance post. In others it is almost
as if the opening balance is what the system is determined to make the
current on hand. This causes the history screen in INV300 to calculate
backwards from the opening balance quantity.
Now for the real kicker! I have backed up, twice now, the production
system and restored it to test. This is a FULL backup. The test
environment is correct!
Please help if you have ANY ideas.
Thank you
Norman K. Boyd
Showa Aluminum Corp. of America
midrange.com
