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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.