<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=523033&amp;fmt=gif">

2 ½ Options for Auditing Batches in Dynamics GP with Fastpath Audit Trail

We got a question recently about auditing batch approval in Dynamics GP using Audit Trail from Fastpath. This was interesting enough that I thought I would tackle it via a blog.

There are really 2 ½ scenarios here.

1) You don’t use GP Workflow 2.0 (pre-GP 2015)

 

In posting setup, (Setup>Posting>Posting) you can require batch approval for an AP batch and input a password to approve. Users will need to enter the password before a batch can be approved. GP tracks the user who approved and the date/time.

GPpost1.png

However, GP only tracks the LAST approver. Sometimes it matters that a batch was approved, then changed, and then reapproved by someone else. It may matter if there is a process to match printouts later. It may matter if you are using a product like Salespad where batches are part of their workflow process. It may matter for cash flow reason that batches don’t change once they are approved.

Auditing the SY00500 table with Audit Trail will track changes to the batch header, including approval changes, and can show each approval and re-approval. On the plus side, you probably don’t need to audit Inserts and Deletes for this table, just updates. You can’t create and approve a batch in a single step, so inserts are covered; approvals are always an update step. You can’t post a deleted batch so that’s not required, unless you just want to see who deletes batches.

That’s just the batch approval. Most companies need to audit vendor setup and address changes. Depending on how detailed you need to get, you can also audit payables transactions in PM20000 in GP and changes to batch assignments at the transaction level, but if you’re managing batch approvals, this is probably overkill.

 

2) You use GP Workflow 2.0 to approve individual AP transactions (GP 2015 R2 or higher).

 

In this scenario, GP’s workflow history should take care of tracking approvals and re-approvals. Reporting on multiple transactions still needs some work, but the data exists. Starting with GP 2015 R2, individual transactions can be approved prior to being available to select for payment. This typically eliminates the need for batch approval.

 

 GPost2.png

 

As before, most companies need to audit vendor setup and address changes, but auditing individual transaction changes is an option.

 

2 ½) You use GP Workflow 2.0 to approve AP Batches (GP 2015 RTM or higher).

Like the last scenario, GP’s workflow history should take care of tracking approvals and re-approvals, but approval is done at the batch level via workflow so this option is halfway between old school batch approval and new school transaction approval. The batch is getting approved at posting along with all the goodies like email notification and approval, but, individual transactions are not getting separately approved.

You’ll still want to audit vendor setup and address changes and auditing individual transaction changes are optional depending on requirements.

Despite my 2 ½ ways, don’t do anything half way when it comes to security, audit and compliance. Use tools from Fastpath to get it right.

 

- Mark Polino

Find me on: Twitter or LinkedIn