'HANKY PANKY' caught with Stitch-in-Time software

["Milt Habeck" <mhabeck@xxxxxxxxxx>]

Al, Stitch-in-Time Data Integrity Software puts an end to the
"hanky panky" you wrote about. The product looks for 
exactly the kind of internal control problem you described: 

               audit security stuff turned OFF, 
                        hanky panky done, 
            then turn the security back ON again.

That tactic will trick audit software that relies on triggers
 ... but ... it will not escape Stitch-in-Time's gaze.

Stitch-in-Time catches irregular activities of this 
kind ... it even catches someone smart enough to think
that they can defeat audit trails and monitoring strategies.
It would tell your security officer:

   1) WHO did it, and ... 
   2) precisely WHEN they did it, and ... 
   3) exactly WHAT they did, and ... 
   4) HOW they did it  

More information about Stitch-in-Time ... 
   http://www.unbeatenpathintl.com/award/source/1.html 

Al, your concern about BPCS ITE (Transaction Effect file) 
is valid. If someone did made a change to ITE, that change
could effect how something is posted to the General Ledger, 
Inventory, Shop Orders, Actual Costs, etc.  
Stitch-in-Time software would track the change to the ITE 
file and all the other pertinent BPCS files. It would provide 
blow-by-blow documentation of how ITE record changes 
caused data corruption in G/L, Inventory, etc.  

Wouldn't it be nice to have all that data damage
information presented on a sheet of paper? It would  
make the correction process much. much easier. 

If your company has a Sarbanes-Oxley compliance issue, 
then any hint of "hanky panky" vulnerability must be erased 
now. Stitch-in-Time will do that ... and ... here's several more 
clever/affordable SOX compliance ideas that will help: 
our Stocking Stuffers (tm) for SOX:
   http://www.unbeatenpathintl.com/SOXstuffers/source/1.html

Warm regards and have a blessed Easter, 

Milt Habeck
Unbeaten Path International

Toll free North America:  (888) 874-8008
International voice: (262) 681-3151
mhabeck@xxxxxxxxxx
www.unbeatenpathintl.com




+++++++++++++++++++++++++++++++++++++++++++++
From: Alister Wm Macintyre 
To:  BPCS_L discussion 
Sent: Wednesday, April 07, 2004 3:04 AM
Subject: Fwd: GL Garbage

I don't feel like I got good answers to my original 
question [... Al's March 30 note inserted below by UPI Path ... ] 
and now I have another question coming.

There's some great software available, but I don't feel it is 
proof positive there been no hanky panky.  

Anyone whose security lets them change the rules, can 
change ITE so the audit trail does not go into General
Ledger, change all kinds of stuff, then change ITE so that 
kind of transaction resumes going back in.  

Likewise various audit security stuff can be turned off, 
hanky panky done, then turn the security stuff back
on again.

Al Macintyre










++++++++++++++++++++++++++++++++++++++++++++++
From: Alister Wm Macintyre
To: BPCS_L discussion
Sent: Tuesday, March 30, 2004 7:16 PM
Subject: GL Garbage

We are BPCS 405 CD on AS/400 mixed mode V5 R1

BPCS does a poor job purging ancient records from many files,
so we write our own AS/400 clean-up software, to fill SSA gaps.
We run the BPCS reorg stuff regularly.

GJW has thousands of journals dated years ago.
GJH GJD similar story.

We also have scores with future dates (e.g. year 2010) that I believe
are bogus. Do I have correct understanding of the role of the files?
GJW is starting work area ... if still there it was probably never posted
GJH (header) and GJD (detail) is where journal entries go that BPCS
trying to post so that content is either posted or has identifiable
errors awaiting adjustment

Under prior management we mass deleted this kind of stuff (e.g. closing
fiscal year 2003, delete if dated 2002 or earlier) but now there is more
sensitivity to GAAP.

Question: how do I tell difference?
Which of this content was in fact posted and which was not?

Any other nuances worth considering?
I am not a GL expert, but I do try to maintain data integrity in what I
delete
e.g. avoid creating more widows (GJH records with no children)
and orphans (GJD details with no parents)

Al Macintyre