×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
We are 405 CD.
I believe that BPCS is SUPPOSED to verify any date data entry as being:
* Valid calendar date
* Valid within the range of current calendars (shop, general ledger)
I believe that not all of BPCS software does what it is supposed to, and
that the same can be said for software developed in-house and by third
parties. Thus there are applications which will not let you enter a date
outside of the open periods, and applications which ignore this
considerations, let you enter dates far in the future, or horribly past due.
I believe that human beings can make a variety of errors, some thru a lack
of understanding of BPCS implications.
Since ITH inventory history records do not get purged until the date falls
off however far backwards you keep it, and at that time the item # is still
valid, you might list what transactions are currently in ITH for distant
future dates you are not yet supposed to be using, and what transactions are
currently in ITH for item #s which are now invalid. If the volume seems
excessive, then maybe initially settle for a count of how many exist by
transaction effect code.
There's other reports and inquiries, than trial balance, on GLD menus, which
can help you explode the detail summarized in the trial balance. Some GJD
records, unless they are summary journal input, should have description
reference codes to point you back to where they came from in the rest of
BPCS, such as invoice #, cust #, vendor#, item#, etc.
When we post inventory etc. to Gen Led, there is the option to do it
exclusively for the current period, and to check what's going in, but some
careless user might post EVERYTHING, without thinking about consequences,
then post all screens of data, but only look at the first one, so not notice
if something is peculiar, and no one review the audit trails. In fact there
is often a management mandate to automate data processing, without human
review to catch anything peculiar.
If you change your calendar AFTER having posted transactions into the
periods, such that they would go to a different period if you posted them
now, except they are now in the wrong period.
We have period 13 and 14, but people can get confused what they are for.
Depending on how big the values, sometimes it is expedient to just fix the
errors and forget them, rather than spending an enormous amount of effort
trying to figure out how something happened.
-
Al Mac
-----Original Message-----
From: bpcs-l-bounces@xxxxxxxxxxxx [mailto:bpcs-l-bounces@xxxxxxxxxxxx] On
Behalf Of daparnin@xxxxxxxxxxxxxx
Sent: Friday, February 10, 2012 10:32 AM
To: bpcs-l@xxxxxxxxxxxx
Subject: [BPCS-L] Unexplained Trial Balance Values
We are on 4.02. Our accounting folks have discovered debit and credit
activity when running the trial balance report for periods in the second
half of 2012. Those periods haven't been opened yet. In fact, we've done
a preliminary close on 2011 with the final close pending review by our
auditors. I've found that the values on the trial balance report seem to
come from the GGM file. Is there a reason that they wouldn't have been
zeroed out? I checked the GJD, which does have records for periods 11 and
12 but those aren't the same periods as the GGM. Thoughts?
Dave Parnin
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.