My remarks are version sensitive.
Problems exist at one version, fixed in later version, reinstated later.
Does your version have ILN file?
If you are fixing inventory based on closed fiscal period, then ONLY the
opening balance should be fixed, not current fiscal month issues receipts
adjustments.
Do you need to get your General Ledger correct for the fiscal period these
transactions were back dated into?
That bug needs to be fixed before this happens again.
While you have your nose in that program, you might consider whether you
want an error message to pop up if someone is trying to post using a date
of an invalid fiscal period. There may already be one if the date is
outside the current shop calendar.
We are on 405 CD & have had variations on this problem on this version &
earlier ones, any time someone tries to post activity to what is a valid
calendar date, but invalid fiscal date, either into the past, or into the
future. We made a rule, which we were unable to enforce:
* Thou shalt not post transactions outside the current fiscal month,
without the permission of accounting
* If you are posting stuff today, use today's date, unless you have
management approval to back date the input.
The main reason for the rule was that we run various reports at end fiscal
month, posting transactions into a prior fiscal month now means those
reports are no longer accurate & need some adjustment. Accounting needs to
know to do that. Management needs to know what has happened to their
bottom line, and on who'se authority.
Some of those end fiscal totals get reported to company owners, auditors,
outside regulators, like our bank loans statement of assets, A/R totals, etc.
Then after we have reported the end fiscal totals something happens to
change those totals. Is that a problem? It depends on the nature of the
business.
We regularly post to General Ledger for the CURRENT fiscal period.
Back dated transactions create GL journal batches for prior fiscal periods
that can get overlooked, never posted. Is that a problem?
Back dated transactions can come from a great variety of human errors.
Big rush to get up-to-date for month end, but a batch of labor tickets not
posted.
Monday after, someone posts that batch, but dates it the previous Friday.
Reports show an obviously bad total for transactions posted on a particular
date.
Someone researches, figures out the problem, fixes it & in the process does
the correction transaction dated same day as the original bad entry. But
when they doing this, that date is now in an earlier fiscal period.
RMA comes in, is entered to the system, using the current date. It takes
QC & other folks a couple months to get the returned product, analysis,
determine problem is that of vendor, go after supplier of raw mateiials to
get closure, then when the last actions taken with the RMA, the date in
there is several fiscal periods ago.
We have a HUGE problem with "unapplied cash", which is where a customer
pays us, let's say $ 5,000.00 when we have a bunch of invoices around $
200.00 each ... which invoices are they paying for? It might take 2-6
weeks for us to get that info from them.
For our transactions, in your scenario, what we found was happening was
BPCS was updating inventory totals as if the transaction had gone in last
month, so it was only updating Opening Balance, not total Issues, Receipts,
Adjustments, plus doing this to IIM IWI ILI and there's a lot file we do
not use, but it also gets updated ... ILN.
If the effect of a transaction is to drive the on-hand negative, or the
allocations negative, some programs accept the update, and some do not, so
we end up with on-hand or requirements that does not add up. There is a
related problem with MRP math trying to replenish inventory that has gone
negative, due to transaction posting sequence float. This is why we like
to be caught up each day with our input, before the next MRP regeneration,
but regularly run lists of what inventory has gone negative.
We fix this, when no one is on the system, with reorganization programs,
located on menu SYS / 23, some of which we have copied to another menu, to
separate out Ok to run on a weekend from only Ok to run at a particular
point during EOM. When the files messed up, generally the detail files
more accurate, so ILI is used to correct IWI, then IWI used to correct IIM.
However, there is yet another bug in this process.
When the balance in the detail file is correctly zero, the data does not
get rolled into the summary file, because the reorg is rolling a balance,
not absense of a balance, so before the roll, we do a dummy adjustment of
plus or minus one, then after the roll we reverse that.
As stated earlier, much of this is version sensitive.
BPCS has problems, they get fixed in later versions, then unfixed in later
ones.
Hello all,
We are currently on BPCS 8.2.01
We recently discovered inventory balance issues when production bookings
were processed in a closed period (after INV903-Month End Close).
When a production booking is done in a running period the issue fields are
affected. When booked in a closed period the Opening Balance fields should
be affected.
Because of a bug in SFC650-Shop Floor Posting we discovered that Component
issues (CI) were not updated in the opening balance fields when a period
was closed
The ITH records were created correctly.
OnHand stock = Opening Balance - Issues + receipts - Adjustments.
Because the Opening balance was not updated the Onhand doesn't show the
correct value. Obviously this is a problem for our production planning and
execution.
We are programming a correction conversion action by reprocessing all
transactions from history for those items with a balance problem. (I
couldn't find a standard reorganisation program)
Read ITH record, determine affected balance fields from ITE (affect
Opening Balance, Affect Issues, Affect Receipts, Affect Adjustments)
Tables and fields to update:
IIM - IOPB, IISS, IRCT, IADJ, year to date fields (IYISS, IYRCT, IYADJ )
IWI - WOPB, WISS, WRCT, WADJ
ILI - LOPB, LISSU, LRCT, LADJU
My Questions:
Has anyone experienced these problems as well. If so, how did you solve
this
Are there other files or fields, which I need to update as well
best regards,
Peter Heeren
Please note: This e-mail / fax is confidential and may also be privileged.
Please notify us immediately if you are not the intended recipient. You
should not copy it, forward it or use it for any purpose or disclose the
contents to any person.
For details of our international offices please visit our website:
http://www.thetford.eu
Thetford B.V. is statutorily based in Etten-Leur, Netherlands. Chamber of
Commerce West-Brabant registration number 20037470.
___________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
___________________________________________________________________
--
This is the BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.
Delivered-To: macwheel99@xxxxxxxxxx
midrange.com
