RE: Incorrect scrap date -- BPCS-L

Dave

If you have never cleared out the deleted records, you might want to do SYS120 on a weekend the first time you run it. We run it weekly, right after a backup, when know no one on the system, and it takes about an hour. This is from menu SYS / 23 / 12 but some options that we run all the time, we have copied to other menus to try to cut down on the chances of taking a wrong menu option.

There are other reorg programs ... I have found that if they are running while someone is in INV300 SFC300 etc., they will run VERY SLOWLY and will not reorg any files that are accessed by INV300 or SFC300, so I prefer to run the bunch right after a backup, because then I have to kick everyone off the system anyway.

Check your ITE file ... many inventory transactions are invisible to accounting. If these are in that situation, then resolving this task is much simplified. However, a review of all invisible transactions is something else worth doing occasionally, as is the issue of how often the ITE file gets tweaked. You can get to this via INV / 15 / 2 ... pick any transaction, like the first one, then with your eyes glued to bottom of screen, scroll thru the sucker to see which transactions are setup to be invisible to accounting.

I also favor the notion of having instructions to the users how to fix their own mistakes. It can be a nightmare when many people have to get involved in fixing problems. It can give some departments of the company a bad name when they generate frequent errors. However, not all errors are practical to be solved by the same people who made them. Consider a labor ticket batch from JIT600 with thousands of transactions that gets aborted. Consider shipping sending the wrong quantity, wrong part, wrong order, etc. In accounting especially, you cannot use the same invoice # when posting corrections to that invoice#.

We are also 405 CD and also have the same kind of thing, but where you know where the bad dates are coming from, we not. Ours are all over the map ... labor reporting batches, accounts payables, billing corrections, shipping. I suspect a bad date in a PC that is running some BPCS software ... I mean the software SHOULD default to the 400 date, but what if some of it uses the date in the PC as today date? Plus when we key in dates, anyone can make a mistake ... I did so during end month a couple months ago.

We have had changes in management, with changes of opinions on what to do about this stuff. Former management said that it was "not material" which is accounting lingo for "so trivial as not to be bothered with" so "Al please delete this garbage" and over the years I have deleted countless thousands of General Ledger transactions because prior management told me to delete all that fell into the category of posted to a Fiscal Period after that Fiscal Period got closed.

Then I got put on part time, and was not able to do quite as much stuff as often as I used to. Then 6 months or so ago, new management was looking into a General Ledger problem and I asked if it had anything to do with the General Ledger deletions I am supposed to do, because I am several months behind on doing them. This was the first new management heard that one of my job responsibilities was to delete General Ledger stuff, so I had to stop that until we had further clarification.

We have a company rule (not enforced very well):
THOU SHALT NOT ENTER TRANSACTIONS USING A DATE OTHER THAN TODAY
unless you coordinate this with accounting

Sarbanes Oxley is not just what gets into General Ledger via accounting transactions, it is also the underlying transactions such as inventory scrap, customer order shipments, costing receivables, inter facility resupply orders ... anything anyone in the company does that goes into the computer system, or does not go into the computer system.

I believe we need to have systems and guidance for the clean up of bad data, and we need to have those approaches certified by someone who understands the implications of Sarbanes Oxley.

I hear what Milt is saying, but he has a conflict of interest when it comes to stating the best solution. Let's suppose we had some place to put a COMMENT or EXPLANATION of our actions, that the SOX auditor could see. This stuff got posted to the wrong date, and not discovered until many other files populated with the implications. We fixed this: * Method A = Ignore the problem ... eventually the garbage records will die of their own accord (we hope). We wonder what will happen to the unposted (to GLD) ITH transactions that have to wait for a couple years, and in the mean time some of those items get deleted. * Method B = Leave the 2006 transactions in the system ... make inventory adjusting entries to minus out the 2006 transactions and replace them with 2004 transactions, and let GLD catch up whenever ... this will be a nuisance on INV300 F21 for a while, but we can live with that. * Method C = Delete all the transactions we can find in Gen Led and Inventory on this, adjust the inventory totals to what they would have been if the transactions had never occurred, repost the bad transactions with corrected dates. * Method D = Find the transactions in ITH and GLD and change their dates to what the dates should have been * Method E = Write a program to seek out 100% of the transactions with the bad dates, this program will then copy those transactions 2 ways: add a correct transaction, minus the transaction found ... and it will also do a flag in the bad dates records found, and the 2 copies, that will tell future runs of the program (when the problem happens again) to ignore these transactions because they already got took care of.

From a SOX perspective, I do not see which Method is worst or best, so long as the problem gets fixed, and there is some kind of an audit trail on what was done that is intelligible to and auditor who does not know BPCS. But this is not my call.

The next topic is how to catch this in the future before history repeats and you get more chaos. Perhaps on eve of INV920 GLD540 you run a query that reads all unposted transactions, does some date math on them ... considers those dated today or last few days to be Ok, and lists those outside your reasonableness window.


 you wrote:

Dave,

The dates in ITH are incorrect.
1.  The inventory affect will be posted to the YTD quantities and not
MTD.
2.  The G/L should post in error because the period in the G/L is
closed.
3.  Accounting should be able to post to the correct period.

If you reverse and start over then you should use the original date to
reverse the transaction and the correct date in the re-posting
transactions.

The G/L will then be correct.

Good Luck

-----Original Message-----
From: daparnin@xxxxxxxxxxxxxxxxxx


I'm looking for suggestions...
(ver 405.CD)

We've got a front-end program that was created long before I began work
here to let users enter scrap transactions.  It loads the NIN file and
posts via CIMPath.  The problem is that the person entering them used
the
11/05/06 instead of 11/05/04.  Naturally, they didn't notice the error
until after things were posted.

Now I can see the transactions in the ITH.  Can I or should I fix the
dates
in the ITH file?  I wouldn't mind changing the ITH so much but I can't
think of any other files that may be affected.  G/L files come to mind
but
I really don't want to mess with those.  The parts and quantities are
correct, it's just the date that's wrong.  The users say they want to
make
sure that it posts to the correct period.  The posting is done.  Is it
too
late?  Can we reverse and start over?  Will the 2006 date be a problem
in
two years?

Thanks

Dave Parnin
Nishikawa Standard Company
Topeka, IN  46571
daparnin@xxxxxxxxxxxxxxxxxx

_______________________________________________
This is the SSA's BPCS ERP System (BPCS-L) mailing list
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.

- Al Macintyre http://www.ryze.com/go/Al9Mac Find BPCS Documentation Suppliers http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html