Re: Need Help

I hope that my big picture review helps illuminate for you the many ways this process can be messed up, and the importance of BPCS education for relevant staff. This is the intersection of several extremely complex applications where the opportunities to mess up are astronomical.

It would help in the future if you could use Subject for thread that is somewhat relevant to content, such as "PHYS OPB" to help when people with similar problems are searching BPCS-L archives for solutions to recurring problems.

We are on 405 CD but I believe that over the years versions the general process is the same, just some changes in program names, file names, options available.
BPCSDOC and 3rd party manuals also helpful.

There are many many opportunities to mess things up.
It might help if you shared your sequence of end fiscal steps ... what programs you run, in what sequence, so people familiar with your version of BPCS might see if something is wrong with your end-week, end-quarter, end-month, end-year, physical inventory, recosting, file reorganization, etc. intermingling of steps.

We have made many modifications to BPCS. Sometimes new employees are unaware of the distinctions between vanilla BPCS, our modifications, what impact this has on how things are supposed to work. Your employer may have made modifications to BPCS before you were hired, of which you are unaware.

In BPCS, a physical inventory is taken as part of the end month process, typically a few days before end month processing. We shut down operations that affect inventory, we do this up to a week before end month, do the physical in that week, then the timing of processing the end month steps and physical inventory tags into inventory are critical.

You cannot be doing physical inventory in the middle of a fiscal month.
You can do cycle counting during the month, but not a physical.

Before the physical started, we clear Tags file (YPH I think) of anything left in there from previously, then we create tags and take the physical, which takes half a week. Once the physical has started, it is Ok to be entering transactions that change inventory, but these transactions are catch up for activity prior to the physical, so that what got keyed takes us to time of physical.

Once you start end month steps, everyone needs to stay off normal BPCS activity until end fiscal completion, then afterwards refrain from posting transactions back dated into an earlier fiscal month. Some exceptions can be made where understanding such input does not impact inventory quantities. There is also issue of timing of changes to inventory valuation, such as new year's standard costs.

Before starting any end fiscal 900 jobs, we get a backup.
Suppose there was a power failure in middle of INV900 or some other long running task ... our UPS does not have as much battery power as the time it takes INV900 to run.

End month has a sequence of steps, including some BPCS file reorganization recomputations. The sequence of steps is extremely critical. Wrong sequence can mess you up big time. End month step INV900 takes several hours and updates a lot of stuff, including pouring all ingredients of on-hand balance into opening balance for new month, zeroing issues receipts adjustments for that month to date.

Immediately after INV900 is where we interject the processing of physical inventory transactions if this month is a physical. There are a ton of reports that compare book inventory (results of INV900) and physical inventory tags file, then we run INV650 by warehouse which dumps in the tags, creating the "O" transactions, and replacing opening balance. You have to know how to read INV300 F21 screen. The quantity in the "O" transaction is NOT the total from the physical inventory, but the differentital between what INV900 said was new balance and what the physical said is new balance.

For example, if you knew of some item whose on-hand was being changed by the physical, and you did a screen print of INV300 F21 story before end fiscal and again in beginning of new month, you would see that the back calculations of history will have changed, because after the physical, the history is showing what the inventory situation must of really been with the hindsight of the physical correction. Do this experiment with various different filters.

Our month end check list includes INV970 after INV900 with the notation that if this month has physical inventory, it is absolutely imperative that this program NOT be run.

The actual dump in of the YPH tags to BPCS inventory also deletes the YPH records, so before doing this, we make a copy of the YPH file into another library for later reference.

When copying files across libraries, we have to be careful with DSPDBR to make sure logicals are pointing at the correct physicals.

We can have more than one inventory tag for the same item same location since there can be several containers, in which we have a tag attached to each container to facilitate auditors checking our counts.

After the dump in, which replaces OPB, opening balance, that should agree with aggregate total of YPH.PQTY tags to that item warehouse location combination in the copied library.

We have also run various reports before and after tags dump in, so we have the capability of checking out what was the on-hand of any given item-warehouse-location right after INV900 and right after INV650.

We have had problems with items that BPCS thought were zero, or the physical thought were zero, for which we have our own "Z" transactions to make corrections to the physical inventory process.

Our end fiscal month starts on a Friday night of weekend. Sometimes we are behind on keying in physical inventory tags, so the last of that gets done on Saturday morning.
Although we impress on that crew that the ONLY thing they are supposed to be keying in are the physical tags, invariably someone thinks "while the system is available, I can do some other transactions" and that person has just inadvertently sabotaged end fiscal month inventory data integrity.

Once we are operating in a new fiscal month, there had better not be any back dated transactions. For example, someone finds a batch of labor tickets that did not get entered on time. They get keyed in, back dated to before the end fiscal weekend. BPCS recognizes an earlier fiscal month, and tries to post as if those transactions had in fact gone in the previous month. Among other things, the opening balance changed.

This is especailly bad when also done into a prior fiscal year.
Various reports and totals have been delivered to management, auditors, perhaps outside organizations like the tax man ... here are the totals for our end of year.
Then some employee goes and changes those totals by back dating transactions, or posting transactions with prior year dates.
-
Al Macintyre