Explains the types of audits available in Auditor.
Form (Window) Audit
The Form method is easiest. You can try this method first and if you are unable to accomplish what you need, then try the Table or SQL Table method. The Form, or Window, method allows you to point and click on the screens and windows in Dynamics GP. Using a wizard, this setup provides a simple way for the non-technical person to setup fields to audit with or without notes at the window level. An audit at the window level will track any change made to a window, not necessarily the database. For instance, it will track changes to a window field after the user tabs off of it, before the Save button is clicked.
An understanding of database structures is recommended for using this method. When a record is added, deleted, or modified, you may track who changed the record. At the table level, table fields set up to be audited are tracked when a data change occurs within Dynamics GP application, regardless of the window in which the change was made. A typical scenario would be on a maintenance window after the Save Button is clicked. After this table save occurs, the audit is triggered and those changes are tracked.
The SQL audit level requires a thorough understanding of how SQL tables are setup and used. This type of auditing allows audits to be tracked in Dynamics GP as well as any table in any database on the SQL Server instance where Dynamics GP and Auditor are currently installed. The audits are tracked after the changes are made to the SQL database.
Note: With SQL audits the user will not have the option to track the “Why” (reason code/note) a change took place. Auditor will capture this change at the point when the data in the database has been changed. It also does not care if a user is logged into Dynamics, or if the user making the changes in SQL is setup as a user in GP. SQL audits place triggers on the database and capture when the data is being changed regardless of who changed it.