We have run into similar problems.
There are several issues.
We do not have time to check every audit trail.
It should not be neccessary for our people to key stuff in, check the
screen they keyed right, check the audit trail they did it right, have
someone else check the audit trail.
Instead, we should have people on the payroll who have an extremely high
rate of accuracy in what they do, and we should have equipment and software
for them to use which makes it very easy to catch any mistakes that may
occasionally occur.
We have exception reports looking for certain kinds of mispostings that
need correction.
We have too many exception reports.
We do not have time to check them all.
We have made our own custom audit trails that are easier to use than those
that came with BPCS.
Typically this is a Query/400 of someone's input, showing only the key
fields whose accuracy is most critical.
Most of our users do not check any of the audit trails, BPCS, ours, or our
exception reports.
The user in question knew that a mistake had occurred and volunteered the
fact, asking for a correction. Many human errors are not so easily
discovered.
Some users do not even know they made a keying error.
Some people who know they made a mistake are afraid to report it because of
what they fear about corporate culture.
Some people who know they made a mistake, they try to fix it without
telling anyone, and sometimes they make it worse.
We have found transactions posted with dates outside of our fiscal
calendar. We run month end, or finish a physical inventory, then someone
posts transactions that change the month end totals, by back dating them.
In the example, by the time this came to your attention, the Inventory
transaction might have been communicated to the General Ledger. Depending
on the transaction with wrong date, the data can be replicated to other
accounting records.
Thus if you use DBU or DFU or SQL or anything else to "fix" the original
transaction, that has not fixed the files it got perpetuated to before this
came to your attention.
Thus doing a negative transaction on the wrong date, then a positive
transaction on the right date, gives you the assurance that every place the
data is perpetuated to is also fixed.
We now have a corporate rule ... thou shalt not post a transaction using a
date other than today date, the date you keying in the transaction. If the
work was actually done yesterday or last Friday, we treat it as if it is
the date you keyed it in.
Some files contain date of actual data entry and date the user claimed for
the transaction.
We can run query to list all postings to those files in violation of the
company rule.
We rarely have time to check this.
Some custom programming we did was to look at fields on some screens, that
are sometimes cleared from transaction to transaction, and to not blank
fields that are usually the same from transaction to transaction, such as
today's date.
Where your shop order reporting is apparently via INV500 M transaction, our
shop order reporting is via JIT600 which might not be available with BPCS
4.0.03. Basically JIT600 supports keying in both labor and inventory with
a single transaction. Some BPCS programs do not support negative
transactions, so you have to know the relevant work around. Some BPCS
programs do not support entering the same transaction again corrected, so
you have to know the relevant work around.
I think that if HOW TO FIX this or that was generally made available to
people in their documentation of how to do things, people would be more
likely to fix things correctly and promptly.
Al Macintyre
BPCS/400 Computer Janitor at
http://www.globalwiretechnologies.com/
See Al at
http://www.ryze.com/go/Al9Mac
Find BPCS Documentation Suppliers
http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
Folks --
We are BPCS 4.0.03 with customer Y2K mods. The email below was sent to
me asking for help.
==User error email ==============
As you know, Lupe is currently training me in the process of
"reporting" shop orders. This transaction is under "INV", "1" Inventory
transactions, "M" Multiple Issue with Receipt.
When I reported this SO #19377 (JC Pasta Ole), I entered the incorrect
date of "10/29/03" when it actually should be "01/29/03". Please make
the necessary transactions to reflect the correct date.
==END user email ==============
The previous analyst would manually (with DBU) correct such errors. I
wish to avoid such silliness; I am a huge fan of audit trails. My
initial response was to advise the user to reverse the erroneous
transaction by entering it the same but with negative quantity.
a> Is this a good response?
b> Is there any way to limit the dates that can be entered into
inventory transactions short of custom programming?
Thanks for any advise you may have.
_______________________________________________
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.
midrange.com
