Force Invoice Approval restrictions

I had a request in a workshop last week to restrict access to the Force Approve Invoice option to Managers only.

As standard this can only be enabled or disabled in the Payables Options window, therefore at operating unit level.

However there is a function called Force Approve Invoices that you can exclude from a responsibility, or build into your menu to control who has access to this option.

Invoice Approvals Example using Oracle Approvals Management

This is the second time I have setup AME (Approval Management Engine) to demonstrate Invoice Approvals for a workshop. AME takes a bit of getting used to, especially if you read the documentation. So I thought I would record it here using the scenario I preparing.

The Requirement

All invoices will be matched to a Purchase Order and therefore approval is not required. However there will be designated exceptions, and where they exist these invoices must be sent for approval.

Assumptions

There is another important assumption for this test - that is the owner of the invoice, and therefore the approver, is known.

AME Components

Each applicable rule is made up of:

• Conditions (if) which in turn consists of an:
  • Attribute - transaction record value (static or dynamically generate using SQL), and
  • a Value
• Actions (then) which consist of
  • Action Types - Approval Group/supervisor hierarchy/position hierarchy etc, and
  • Approval Group - in this example a list of designated approvers

Example

1. I created a new dynamic attribute XX_SUPPLIER_HOLD_UNMATCHED_INVOICE_FLAG to return the setting for the Hold Unmatched Invoices option on the Supplier Record. I used the following SQL query:

   Select decode(decode(vs.hold_unmatched_invoices_flag,NULL, nvl(vh.hold_unmatched_invoices_flag,'NULL'), vs.hold_unmatched_invoices_flag )
   from ap_invoices_all ai ,po_vendors vh ,po_vendor_sites_all vs
   where ai.VENDOR_ID = vs.VENDOR_ID
   and ai.VENDOR_ID = vh.vendor_id
   and vh.VENDOR_ID = vs.VENDOR_ID

   This query returns either 'Y' ,'N', or 'NULL'. Note the NULL is returned as a string value as I have been unable to figure out how to specify the NULL value in the string list just yet.

2. I then created the condition 'XX_SUPPLIER_HOLD_UNMATCHED_INVOICE in (N,NULL)' using the string  values 'N' and 'NULL' .
3. Next I created an new approver group 'XX Invoice Approval Group' and manually added approvers to the list from HR. I have an employee named 'Accounts Payable' so all invoices are currently going to this employee for approval.
4. Next up I used the existing 'approval-group chain of authority' action type with an action requiring the 'XX Invoice Approval Group' .
5. Once these have been created I could now create the rule which I want to apply to all transactions. The rule links the condition to the action defined above.

Testing

AME provides a Test Workbench to try out your rules before going back into the main forms. This is a very useful tool. The easiest way to use it is to Run Real Transaction Test by getting entering the transaction ID, which in the above example is the INVOICE_ID for the record that apply to the rule.

Before actually running the test the application shows you all the available attributes and their values. It is worth checking that these are what you expect.

The test itself does not generate workflow notifications To do that you need to enter an actual transaction in the application. But what it does do is allow you to see the list of approvers this invoice would be sent to.

Useful points to note

One thing that is useful to keep in mind is that AME regenerates the approval list each time the invoice is approved. This way it is always working of the absolute latest business data.

I have left out a lot of information about the actions. AME allows for parallel approvals and much more. For example there is a First Responder Wins and Voting  option amongst other all worth investigating.

Summary

This is a very simple example. I imagine that the rules I end up with eventually will also check for invoice source, we have invoices being interfaced, and whether the invoice is already matched to a PO.

Hopefully the example puts it into context and helps explain how the pieces work together.

Hello

A short note to introduce this blog.

I have worked with Oracle Financials for a while now and would like to document and share my experiences and lessons in that time - something I wish I had started doing a long time ago...

What follows will I hope be of value and use.