Audit Trails

[Chris Kelleher]

Mfg/pro 8.5f
Progress 8.3b

Small question. Is there a way to track (audit trail) for changes such as
Inventory Location adds and deletes?

Steven

 

[Chris Kelleher]

There is a file called tr_hist, which may have the transactions you are
searching for.

 

[Chris Kelleher]

That is what I thought but the only Transaction ID's I can find are:
CST-ADJ - Cost Adjustment
CYC-CNT - Cycle Count Adjustment
CYC-ERR - Cycle Count Error
CYC-RCNT - Cycle Count Recount
ISS-CHL/RCT-CHL - Change Inventory Detail
ISS-DO - Distribution Order Shipment
ISS-GIT - Distribution Order Receipt
ISS-PRV - Purchase Return to Supplier
ISS-RV - Inventory Return to Supplier
ISS-SO - Sales Order Shipment
ISS-TR/RCT-TR - Inventory Transfer
ISS-UNP/RCT-UNP - Unplanned Issue/Receipt
ISS-WO/RCT-WO - Work Order Issue/Receipt
ORD-SO - Sales Order Booking
RCT-DO - Distribution Order Receipt
RCT-GIT - Distribution Order Shipment
RCT-PO - Purchase Order Receipt
RCT-RS - Inventory Return to Stock
RCT-SOR - Inventory Sales Order Return
RJCT-WO - Work Order Reject
TAG-CNT - Physical Inventory Update

 

[Chris Kelleher]

We've go a small number of people that can access the 1.1.18 Location
Maintenance and one of them is entering Bogus locations into the system. Of
course everyone is pointing at one of the other two and as Sys Admin, I need
to find a way to prove who is actually doing it. I'm getting the feeling
there is no way....

Steven

 

[Chris Kelleher]

Well, I am the ONLY one that can access location maintenance. We
occasionally get 'bogus' locations. I am absolutely POSITIVE that I
did not add them myself. I know that there is another way a location
record can get added without going through the location maintenance
screen. Nevertheless, I have not been able to duplicate this.

All my sites are setup with automatic locations = no. These weird
locations get setup with permanent = no, single lot/ref = yes, a blank
status, no description, and a location name that is setup in another
site. I, too, blamed this on the one other soul who had access. So I
took his access away. And months later, another one appeared.

Debi Loope
PI Inc.
8.5e

 

[Chris Kelleher]

Steven,

I don't see any way, either, to tell who added a location.
However, there is the "date created" field (loc_date) in loc_mstr.
Perhaps if you checked for newly created locations on a regular basis,
you might narrow your list of suspects (maybe a new location added in
the last hour could have been entered by only one person). Of course,
if this is tomfoolery or mischief, then the user could always enter a
bogus date, as well. A lot of work, in any case.

But I'm also thinking of some situation that we had here where
locations were created automatically and it was causing us some
problems. I think it was on receipts where locations were entered
wrong by the receivers and the system just went ahead and created a
new (and erroneous) location. I'll write again if I can recall
anything more about this.

Good luck,

Jack

 

[Chris Kelleher]

From: "Lesniak, Steven" <Steven.Lesniak@ShepherdCasters.com>

> We've go a small number of people that can access the 1.1.18 Location
> Maintenance and one of them is entering Bogus locations into the system. Of
> course everyone is pointing at one of the other two and as Sys Admin, I need
> to find a way to prove who is actually doing it. I'm getting the feeling
> there is no way....

Then,... From: "Loope, Debi" <DLoope@PI-INC.com>

Well, I am the ONLY one that can access location maintenance. We
occasionally get 'bogus' locations. I am absolutely POSITIVE that I
did not add them myself. I know that there is another way a location
record can get added without going through the location maintenance
screen. Nevertheless, I have not been able to duplicate this.

All my sites are setup with automatic locations = no. These weird
locations get setup with permanent = no, single lot/ref = yes, a blank
status, no description, and a location name that is setup in another
site. I, too, blamed this on the one other soul who had access. So I
took his access away. And months later, another one appeared.

I was gonna suggest falling back on an old favorite, creating a front-end
procedure with a trigger. Something like:

<BLOCKQUOTE><font size="1" face="Arial, Verdana">code:</font><HR><pre>
/* xxiclomt.p */
{mfdeclre.i}
on create of loc_mstr
do:
assign loc_user1 = global_userid + " " + string(today).
end.
on update of loc_mstr
do:
assign loc_user2 = loc_user2 + global_userid + " " + string(today) + ",".
end.
{gprun.i ""iclomt.p""}
[/code]

But from what Debi said, this won't help. Looks like you're gonna have to set up
database triggers for this. I'd trap global_userid, the program-name() stack, date,
possibly time, etc..
---------------
Paul T. O'Leary
Evco Plastics, a leader in plastics injection molding
DeForest, WI USA

 

[Chris Kelleher]

We are using MFGPRo 7.4i. When creating purchase orders if a bogus location is entered at line level, the system doesn't validate against location master. It simply adds the bogus location to the location master.

We are planning to combine two sites into one site and two locations. When I was testing purchase order module for this purpose I entered bogus location but the system didn't warn me. It simply created bogus locations in the location master.


Geetha

 

[Chris Kelleher]

Sorry.
I was in the middle of testing when I wrote the mail. The purchase maintenance screen doesn't give error but when u receive items the system does give error message.

Geetha

 

[Chris Kelleher]

Taking this a step further...

Create a new program (e.g. xxmf.p) :-

- define variable lvSeq as integer no-undo.
- on write of loc_mstr do:
- find last usrw_wkfl where usrw_key1 = "LOCAUDIT" no-lock no-error.
- lvSeq = if available usrw_wkfl then integer(usrw_key2) else 1.
- create usrw_wkfl.
- assign
- usrw_key1 = "LOCAUDIT"
- usrw_key2 = string(lvSeq)
- usrw_key3 = loc_site
- usrw_key4 = loc_loc
- usrw_charfld[1] = userid("qaddb")
- usrw_charfld[2] = program-name(2)
- usrw_datefld[1] = today
- usrw_decfld[1] = time.
- release usrw_wkfl.
- end.
- run mf.p

Replace all of your user's start-up script/pf files to execute the new
program (xxmf.p) in place of mf.p. If this is too painful, rename your mf.p
to something else (orig_mf.p), create the above program as mf.p and call the
renamed mf.p (orig_mf.p) at the end. You won't have to change any start-up
processes this way.

This will give you an audit of ALL creations/updates in the loc_mstr table
no matter which programs perform them. To see the audit... for each
usrw_wkfl where usrw_key1 = "LOCAUDIT" etc.

Note 1: The "qaddb" reference must be changed if the logical name of your
main MFG/PRO database is not "qaddb".
Note 2: The above will not work in a multi-database environment. To do this,
the above trigger needs to be defined for each connected database with a
loc_mstr table.
Note 3: Obvious but needs to be stated, you may notice a SLIGHT decrease in
performance when Locations are updated.
Note 4: If you want more details, specify the "old buffer" as well and add a
"buffer-compare" between the two. You will then be able to see exactly which
fields have been modified.
Note 5: QAD variables (e.g. global_name, execname) will not be available
when the above trigger is defined so cannot be used (hence the "userid" and
"program-name" functions).
Note 6: The size of the usrw_wkfl will grow. Keep an eye on it and clear it
down of all "LOCAUDIT" records if it gets too big.

Jon Miller
Technical Consultant
TRW ISCS
jmiller6@concentric.net

 

[Chris Kelleher]

Correction...

- lvSeq = if available usrw_wkfl then ( integer(usrw_key2) + 1 ) else 1.

Jon Miller
Technical Consultant
TRW ISCS
jmiller6@concentric.net