• Subject: Re: Programmer DFU access
  • From: MacWheel99@xxxxxxx
  • Date: Fri, 16 Jun 2000 12:11:02 EDT

> From: booth@martinvt.com
>  
>  Was the auditor's concern that the data could be changed with DFU, or was 
>  their concern that the data could be changed without a record of the 
>  change's time, user, or data?

We use DFU & other tools to fix problems with our ERP that do not rise to the 
level of needing a program to deal with this particular scenario.  If I was 
auditing ourselves, my point would not be what tools we use to update our 
data, but rather the notion that there ought to be some kind of consistent 
audit trail on what got changed & why it got changed, and whether our 
security permits people in department-A to be changing data that is under the 
management of department-B without dept-B being any the wiser.

Many programs create some kind of before / after picture of data entry ... we 
rarely print these reports ... we rarely store them any place.  The audit 
trail is created but goes no where by the choice of the users of the 
software, because corporate policy is that each department is responsible for 
the veracity of their data & how they choose to achieve that accuracy is up 
to them.

There may be a security issue of who is making the changes, and who is able 
to make what changes - I as programmer am only changing data in the system 
when specifically requested to by some department in charge of it.  
Occasionally, during testing of software mods, I temporarily create some data 
in a live environment ... I always notify the departments involved about what 
is going on.

We have reason codes in BPCS for WHY an inventory adjustment is made ... the 
screen defaults to "CC" which is Cycle Count Adjustment & none of the other 
reasons show up in the history except when I was making an adjustment a few 
weeks ago to fix a suspected human-bug & was checking what reasons other 
people using to see what was most appropriate - I did not use CC ... then I 
looked at the EOM reports ... no one is running any report to see what reason 
codes are in use.

I would have thought we ought to have a monthly report with a count of how 
many of which kinds of abnormal transactions are being made by which users.  
I should think that adjustments should be dominated by certain individuals.  
If we are not monitoring the audit trails of the official software, then 
there should be no grievance by some outside audit that we do some changes 
that do not generate an audit trail.  The only grievance is internal people 
who find something is wrong & want to access whatever history exists to 
figure out why that data is wrong.

At one time I suggested that we add a comment capability to the history files 
... so that if someone makes a DFU adjustment to some file, then they would 
have an obligation to insert a note about what they did & why to either the 
notes on that order or a comment line to that item history, coded to not show 
up on standard documents like to customers, but using a unique transaction 
code so that all such notes could end up on one report.  No one seemed to 
think we had any such need for any such thing.

We have been having ISO & related audits ... our policies say that we should 
do things certain ways ... are we in fact obeying our own policies.

Al Macintyre  ©¿©
http://www.cen-elec.com MIS Manager Programmer & Computer Janitor

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.