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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.