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
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,
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
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.
As an Amazon Associate we earn from qualifying purchases.
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
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.