invoice approval workflow

An Introduction to the Invoice Approval Workflow

Jeannie Dobney

EduSource

Introduction

Oracle has introduced a new Workflow in later releases of 11i which allows the automation of invoice approval processing in Payables.

This paper provides a high level overview of that Workflow, focussing on the business benefits and effort required to implement the workflow.

Overview of Functionality

The Invoice Approval Workflow automates your invoice approval process. Based on rules you define (using the Approvals Management Application), the workflow determines if an invoice needs approval, who the appropriate approvers are, and in what order approvers should approve payment of the invoice. The workflow then sequentially asks each approver in the approval list to approve invoices online. For example, you can define a rule so invoices over $100,000 require CFO approval and then CEO approval.

If you use Invoice Approval Workflow, then every invoice that requires approval must be approved before you can pay it. Payables indicates that an invoice requires approval by setting the value in the Approval status field in the Invoices window to Required.

When you use this feature, all invoices require approval, with the following exceptions. Payables sets the Approval status of the following invoices to Not Required:

• Expense Reports imported through the Payables Expense Report Import Program (because these expense reports have already been through an approval process)

• Recurring Invoices if the recurring invoice template did not have the Approval Workflow Required option enabled (because recurring invoices are often approved in advance)

• Invoices that existed before you enabled the feature Invoices that the Invoice Approval Workflow process determined did not require approval according to the rules you set up in Oracle Approvals Management.

You can set up your system to request and receive approval through the approver’s email, through the approver’s Oracle Workflow Notifications Workflow web page, or both.

You can review the approval status of an invoice that has started the Invoice Approval Workflow in the following ways:

• Invoice Approval History window. • Invoice Approval Status Report.

Business Background

This new workflow has been introduced at an optimal time, in the wake of Enron and other corporate scandals, when many organisations are reviewing their organisational controls.

Here are two common Applications’ scenarios into which this new workflow might be used:

With Purchase Order Matching

Many organisations which have implemented both Purchasing and Payables, push most of their procurement approval controls back to the Purchase Order or Requisition stage. This means that when supplier invoices are entered into Oracle, they can be “matched” to the approved Purchase Order and need no further approval to be paid. The only invoices excluded from PO matching, are likely to be charges which are hard to pre-determine like utilities and taxation payments.

Such implementations commonly set a system option to Hold Unvalidated Invoices. Organisational approval for these unmatched invoices is then typically recorded in the system via the release of invoice holds by a senior Payables user with access to the required window. To process and document these

approvals, sites typically forward the actual invoices (in hard copy) to the relevant Cost Centre manager who reviews and signs them before the system data entry is done. This paperwork is then retained for audit purposes.

Without Purchase Order Matching

Sites which do not use Oracle Purchasing typically extend the type of processing described in the previous section for unmatched invoices, to all invoices.

In the past there has been no possibility of automating this invoice approval process, however, this new workflow provides that possibility. Potential benefits include the following:

• Demonstrably objective application of approval rules (i.e. automated). • Audit documentation stored in soft copy. • Automatic redirection available if first approver is unavailable.

Implementation Overview

So assuming that you have decided to implement the Invoice Approval Workflow, what’s involved?

Quite a lot as it turns out! Here’s an overview. Later in the paper we’ll look at each step in turn.

Document the business logic that you want the process to reflect.

Check your patching levels – this functionality depends heavily on the correct patches having been applied.

Enable the invoice approval workflow functionality in Payables.

Install and set up Oracle Approvals Management. This application is used to create the approval rules used by the workflow process.

Review the Workflow and modify it if required.

Test the process.

It will become obvious as we look at each of these steps, that the skills and implementation resources required should not be underestimated.

So let’s look at what is involved in each of these steps.

1. Document the Business Logic

Perhaps it seems trite to include this step, but it will hopefully become obvious how crucial it is to have the business requirements clearly defined.

If the manual approval process is already well-understood, then it should only take a quick moment to document it, for example as a flow chart. Alternatively, if the process takes longer than just a few moments, or if it generates discussion about possible improvements in the process flow, it was clearly worthwhile investing some time with it. Either way, your output will be something from which the whole team can understand and work.

I have included 2 references in the Appendix to this paper, for related papers which may be helpful in this connection (Volz & Cooney).

2. Check your Patching Levels

To use Invoice Approval Workflow functionality you must be at least on release 11.5.4 and have applied Payables Mini-pack I.

The Oracle Approvals Management Application is available in patch 2198768. After applying this patch, apply the following bug-fix patches: 2220334, 2228792, 2257526, 2271164, 2274701.

Upgrade to Oracle Workflow 2.6. Oracle Workflow 2.6 is distributed as patch 2032040. The Workflow Builder is distributed as patch 1782821

A search on MetaLink (the source of the requirements shown above) for current issues, is also recommended.

Invoice Approval Workflow

Note that in 11i, Oracle’s approach to patching has changed and your organisation probably needs to consider this. Patching to near current levels is now recommended. (See Alicia Hoekstra’s excellent paper cited in the References section for an excellent coverage of this important topic.)

3. Payables Set-Up

The set-up required in Payables is fairly straightforward. In the Invoice tab of the Payables Options window, check the Use Invoice Approval Workflow checkbox (see following image).

In the same window, there are also some other settings you may like to consider:

Allow Force Approval. Select this checkbox if you want to enable selected AP staff to override the workflow and manually approve invoices by using the Force Approval option in the Invoice Actions window. This might be required if the Invoice Approval Workflow does not complete for an invoice that you do wish to pay.

Require Validation Before Approval. If you enable this option, then Invoice Approval Workflow does not select any invoice for processing unless the invoice status is Validated. You might enable this option if you want the Invoice Validation process to create tax distributions for an invoice before approvers review it.

After your workflow is set-up and tested you will also have to submit the Invoice Approval Workflow Program (from standard report submission). Consider resubmission options that fit with the schedule of your validation program options.

4 Install and Set Up Oracle Approvals Management.

The Payables User Guide refers you to the Oracle Approvals Management User Guide for help with this step. If (like me) you find that your 11.5.9 documentation CD does not contain a document of this name, you can download it from MetaLink (and you will need this documentation!).

Although the excellent Payables whitepaper on the Invoice Approval Workflow by Michael Milano, states that Oracle Approvals Management application is supported by the Payables team, you will currently find the documentation for this in the HR section of the MetaLink Top Tech Docs (as shown here).

Note that the documentation variously lists the Oracle acronym for Oracle Approvals Management application as either AME or OAM (presumably the conflict with the Application Management tool is the reason for this ambivalence). This paper will use the acronym OAM to signify the Oracle Approvals Management application.

Understanding OAM is a non-trivial task and should not be underestimated in your planning. That will probably become obvious as we step through the screens in the following section.

OAM is a web Applications which can be accessed from 3 default responsibilities. To set up the approvals required for the Invoice Approval Workflow you should be assigned, and select, the responsibility AME Application Administrator.

(If you are unable to access OAM, check the value of the profile option AME: Installed at site level. It should be set to Yes. You may also need to modify the securing attributes when you are assigned the responsibility.)

The following screen shows the OAM access screen. Note that users who do not access the Applications from a Personal Home Page will see a navigator with a single menu entry Approvals. Either way the window which opens as a result of clicking on the Approvals item are the same HTML pages.


After selecting Approvals above (or in the Navigator), the following screen is displayed:

Each tab displayed in the image shown above relates to a task which will be required to set up the Invoice Approvals.

As we work through these screens, let’s assume that the business logic which we have documented in step 1 above, requires all invoices with a value of more than $100, to be approved by the manager of the requester.

An attribute (tab shown above) is a business variable with a specific value for a given type of transaction. When you select the Attributes tab, the system therefore first prompts the user to specify which Transaction Type is required.

Each application that can use OAM defines one or more transaction types. Each transaction type has its own set of approval rules. You will be prompted for a Transaction Type in a number of OAM screens but this will not be shown again in this paper. In each case, you should select Payables Invoice Approval as shown above.

By setting the values of the attributes displayed for this Transaction Type, you control the behaviour (or logic) of the invoice approval process. In the following screen shot, you can see some of the mandatory attributes for the Invoice Approvals process. The OAM User Manual provides details about the function of each of these attributes, to assist you in setting each value appropriately for your site’s business needs.

For example in the following screen shot, the second attribute is:

ALLOW_REQUESTOR_APPROVAL

This is a Boolean attribute (i.e. either True or False) whose value determines whether OAM lets a requestor approve their own transaction, (if the requestor has sufficient signing authority).

The attribute’s value (or static usage in OAM jargon), can be set as follows:

1. Click the name of the attribute that you want to edit.

2. Make your changes on the Edit an Attribute page (e.g. by typing the value true).

3. Click the Submit Changes button to save your changes.

Note that the description here of the required set up is highly simplified and used only to indicate the process flow. You will need to study the OAM User Guide before proceeding.


Shown below is another screen shot showing a second attribute, this one has a dynamic usage i.e. it’s value is determined at run time by the SQL query shown in the Usage field.

In addition to thoroughly reading the OAM manual in order to understand which attributes are used by the Invoice Approval process and how to set them, it is probably also advisable to run queries like that shown below through TOAD or SQL*Plus in order to validate they will give you the results you expect. Functional users who are not familiar with the use of tools like TOAD and the Examine function within the Apps, will need to collaborate with a technical resource on this.

At the time of writing this paper, there were a number of open TARs relating to OAM. It is inevitable that with any new functionality there will be issues which have to be resolved as the product matures. Do not, however, underestimate the time which will have to be factored in to your implementation of Invoice Approval functionality due to the combination of a relatively complex set-up with unresolved (and perhaps not yet fully revealed) product issues.

The next tab is the Conditions tab.

An approval rule’s “if” part consists of one or more conditions, each of which is either true or false. For the rule to apply to a transaction, all of its conditions must be true for the transaction.

For our example the syntax for the required condition would look something like this the :

TRANSACTION_AMOUNT > 100 NZD

It is also possible to have conditions which use list operators or simple Boolean tests.

You may also have multiple conditions, allowing complex rules, for example so that high value invoices are routed to senior executives, but that invoices for specific categories of goods (like IT purchases) are also routed to specific managers.

The following sequence of screens shows the process of creating a condition which will identify amounts less than $1.000 USD.

First specify that this will be an ordinary condition, i.e. this condition will be used at the invoice header level to identify the usual conditions under which the rule we are creating should apply.

(Exception conditions are used specifically to create Exception rules. List–modification conditions are used to substitute an approver in a list-modification rule. Line level conditions identify variables in detail lines of a transaction.)


Next specify the business variable which should be evaluated as shown in the following image:

Then enter the value(s) within which the variable must fall for the rule to apply:

and then click the Create Condition button to add this condition to the list shown previously.

The Approvals tab (following image) enables you to instruct OAM to include a given set of approvers in a transaction’s approver list. Approvals constitute the “then” part of approval rules.

In our example business process, the supervisor of the requestor of the goods or services represented by the invoice is to be asked to approve the invoice. The appropriate Approval Type in this case is Relative Job Level with a parameter of 1 to indicate that only the immediate supervisor should be required to approve the invoice.

Notes:

• At the time of writing this paper, an enhancement request (Bug 3197499) had been logged to allow the use of the Position Hierarchy often used with PO approvals to also be used for Invoice Approvals. (See also Bug references 2433615 and 3011106). The fix was due in 2003 however, the MetaLink documentation does not make it clear if it has been delivered.

By default, the hierarchy ascent starts with the supervisor of the transaction’s requestor, identified by the attribute: TRANSACTION_REQUESTOR_PERSON_ID. It is, however, possible to amend this so that the ascent start is based on some other system data such as a project or descriptive flexfield value. Such changes however require PL/SQL skills as well as further information from the OAM manual.

In addition to the seeded Approval Types, it is possible to create new Approval Types using PL/SQL procedures (called handlers by OAM). To create a new Approval Type, click the Add Approval button shown in the next slide.


Approval groups are optional and typically represent functional approvers outside a transaction’s chain of authority, such as an HR manager or specialist procurement advisor, who must approve a transaction before or after line management has done so.

When you create an approval group, OAM automatically creates the corresponding approvals of the pre– and post–approval approval types. These approvals are then also available to all transaction types.

The tab used to create these additional approval groups is shown below. Note that someone in your team will need a good working knowledge of the underlying data-structures to write the required SQL Query .

Rules associate one or more conditions with an approval in an if–then statement. Before you can create rules, you must create conditions for the rules to use (as previously described). So in this step we are actually tying together the logic components we have previously configured.

Our example rule should be like the following statement when it is finished:

If TRANSACTION_AMOUNT > 100 NZD

then require approvals up to the first superior.

The last section of this statement is called the Approval Description and should be formulated as an imperative sentence.

The next screen image shows the Rules tab displaying existing / pre-defined rules.

Click on the Add Rule and Usage button to start defining a new rule (such as our example rule).

Note that as the user navigates into this tab, they are again prompted to select a Transaction Type. By selecting the Transaction Type, you are associating the rule you will create with the Invoice Approval workflow. (You can see the Transaction Type displayed in the tab’s title bar, indicating that these rules are apply to that process.)

There are a number of steps in creating the Rule, as shown in the screen shots on the following pages.


For our simple business scenario, the following would be required:

Enter an Approval Description (this description should uniquely identify the rule and communicate the business case to which the rule applies.). In this example it would be: require approvals up to the first superior

Select the appropriate Rule Type, in this example that would be List Creation Rule (because this Rule identifies the list of required approvers).

Allow the Start Date to default to today’s date (except for final validation in Production as described in the OAM User Guide).

Click Continue (in the screen shown above) to move to step 2.

In the screen shown above, select the third list item Chains of Authority based on relative job level. (Note that it is this that tells the workflow which of the approval types will be used by this rule).

Click Continue

In the next screen (not shown here), allow the constraint type which restricts the rule’s application, to default to none. This means the rule applies to all organizations, business groups and sets of books.

Select the Ordinary Condition attribute TRANSACTION_AMOUNT

Select the Ordinary Condition TRANSACTION_AMOUNT > 100 NZD

No exception conditions are required, so simply click Continue and OAM saves the new rule and displays it on the rules list. You have completed your first simple rule!

The set up in OAM is now complete. The next step is to review and possibly modify the actual Workflow.


5 Review and Modify the Workflow

Workflow is a technology which Oracle Applications uses to automate business processing. It consists of both client and server components:

On the client side is a Builder which must be installed on your Desktop to allow you to modify Workflow processes.

On the server side is the engine which runs the processes, creating the notifications and executing the business logic.

Whilst it is not impossible for functional users to use the client side Workflow Builder, in practice it seems this task is typically left to a technical resource or to a semi-technical system administrator.

After the Workflow Builder is installed on your desktop, you start the program and then select File ~ Open in order to load the Workflow process from the database into the client side Builder.

You will be prompted for a database user name and password (you cannot use your Applications log on here).

Once you are logged into the database, you will be able to select the Invoice Approval Workflow process (in the right pane shown in the next image) and load it into the Builder by clicking on the arrow button in the centre of the dialog box.

Note that the workflow may also be named AP Invoice Approval in your database.

Note also that this process of opening the database store and loading the workflow process into the Builder can be a little slow and you may need to be patient.

The image on the following page shows the Invoice Approval displayed in the Workflow Builder.

The left pane in the image above represents all the components of the workflow hierarchically. Right of centre is a graphical display of the main process. Each coloured icon represents a step in the process.


Note that understanding and modifying Workflow processes is a significant topic in it’s own right and is only touched on here to indicate the scope of the process of implementing the Invoice Approval workflow.

The default process shown above can be edited to fit your site’s requirements as required. The following discussion outlines the default processing and possible modifications.

Node 1: Receive Invoice Approval

This activity selects invoices. An invoice must meet all of the following criteria to be processed:

• If the Require Validation Before Approval Payables option is enabled, then the invoice must be validated.

• The Approval field value in the Invoices window must be: – Required if you submit the workflow program from the Submit Requests window. – Anything except Initiated or Manually Approved, if you submit the workflow program from the

Invoice Actions window.

• The invoice amount must equal the distribution total. The Ready for Approval check box in the Invoices window must be enabled. This check box is enabled by default for all invoices.

Node 2: Check if Matched to PO

This activity is disabled by default because a constant value of No is seeded for the Exclude PO Matched Invoices attribute in workflow (as shown in the following image).

When this activity is enabled, if all distributions on the invoice are purchase order matched, then this activity sets the Invoice Approval status to Not Required. The process then exits.

If all distributions on the invoice are not matched to a purchase order, then the process branches to Node 3.

Note: To edit a workflow you may need to review its protection level and change some settings. Before you do so, you should read Oracle’s Support Guidelines in MetaLink Note: 97381.1 (I would also recommend you save both the original workflow and your modified workflow in flat file format somewhere safely.)

To get started with understanding Workflow, try reading Karen Brownfield’s whitepaper for which you will find a reference at the end of this paper.

Node 3: Identify Approver

This activity selects the next approver from a list of approvers that is generated from approval rules defined in OAM.

• If the activity finds an approver, then the process branches to Node 4.

• If the activity does not find an approver, and there is no prior approver, the invoice approval status is updated to Not Required. The process then ends.

• If the invoice has already been approved by at least one approver, and if there are no additional approvers, the invoice approval status is updated to Approved. The process then ends

Node 4: Send Notifications

This activity calls the Send Notifications sub-process. (Described in the following pages).

• If an approver approves the invoice, then the process branches to Node 5. If an approver rejects the invoice, then the process branches to Node 6.

Node 5: Update Approval History

This activity updates the invoice approval history information that appears in the Invoice Approval History window and the Invoice Approval Status Report.

Because the approver approved the invoice in Node 4, the invoice approval status is updated to Approved and the process branches to Node 3 again to identify additional approvers.

Node 6: Update Approval History

This activity is similar to node 5, except that it occurs because the approver rejected the invoice in Node 4.

This activity updates the invoice approval status to Rejected and then the process ends.

End Nodes

These nodes all signify the end of the process due to various outcomes.


Send Notifications Sub-Process

Node 1: Start

This is a standard function activity that simply marks the start of the sub-process.

Node 2: Approval Request

This process sends the approver an email and / or workflow notification requesting invoice approval. The approver can approve or reject the invoice.

• If the approver approves the invoice, then the process branches to an End node and the sub-process ends.

• If the approver rejects the invoice, then the process branches to an End node and the sub-process ends.

If the approver does not respond within the time you specified for a timeout, then the process branches to Node 3.

Node 3: Approval Reminder

This activity sends a reminder email or workflow reminder notification (or both) to the approver. The approver can approve or reject the invoice.

• �If the approver approves the invoice, then the process branches to an End node and the sub-process ends.

• �If the approver rejects the invoice, then the process branches to an End node and the sub-process ends.

�If the approver still does not respond within the time you specified for a timeout, then the process branches to Node 4.

Node 4: Escalate Approval

This activity identifies the approver’s manager and escalates the approval request to the approver’s manager.

Note that these notification activities (nodes 2 and 3) are have a Timeout transition (the time period in which an approver needs to respond before sending a reminder notification or

escalating the request to the approver’s manager). Review this and consider changing the timeout value,.

Node 5: Escalated Approval Request

This activity sends the approver’s manager an email or workflow notification (or both) requesting invoice approval and informing the manager that the invoice approval was escalated because the original approver did not respond.

• �If the approver’s manager approves the invoice, then the process branches to an End node and the sub-process ends.

• �If the approver’s manager either rejects the invoice or does not respond within a specified time limit, then the process branches to an End node and the sub-process ends.

End Nodes

These nodes all signify the end of the process due to various outcomes. They return values of Approve or Reject depending on which branch they terminated.


6 Test the Workflow

Here are some suggested steps to test new workflow process:

1. Create a business case and identify the expected outcome from your Workflow for this scenario. 2. Enter a standard invoice into Payables, ensuring that it’s amount etc reflect your business case. 3. After saving the invoice, use Examine to note the invoice_id. 4. Validate your invoice if you have selected the Require Validation Before Approval Payables

option. 5. In the Invoice Actions window, select the Initiate Approval option. Click OK. (The approval field

should now display Initiated. Note the original value of this field when the invoice was entered was Required.)

6. Once the invoice approval is Initiated, a request is placed in the WF_DEFERRED queue. You can log into the self-service web application Workflow Administrator Web Applications responsibility. Select Event Queue Summary. Select WF_DEFERRED Queue. The Item Key is the invoice id. Verify the invoice id of your test case appears in the queue.

7. In the System Administrator responsibility, run the Workflow Agent Listener (N~Requests~Run). This launches the Invoice Approval Workflow and moves the request from the WF_DEFERRED queue.

8. Log into the self-service web application Workflow Administrator Web Applications as the approver. Select Find Notifications. Click on the notification. Approve the invoice.

9. Back in Payables, query the invoice and verify the approval field has changed to Approved.

You can also test to OAM as a standalone process. 1. Log into self-service OAM web application using AME Application Administrator responsibility. 2. Click Approvals to open the OAM form. 3. Select the Test tab (shown in the following images). 4. Select Create a Test Transaction and then click Continue. 5. Select Person as Test-Transaction Requestor Type. 6. Search for the requestor. 7. If the approver is found you should get a list the test transaction attribute values. 8. Make any necessary changes to the values and click the View Approval Process button. If an

error appears the error is within OAM. If the approval completes without any errors, then OAM is set up correctly.


Other Considerations and Notes

Approval and Validation

The new invoice approval workflow is not meant to replace validation. The ‘old’ approval process (now called validation) must be run prior to the invoice approval workflow. Validation as it is now called, is still the process that will place holds on invoices and automatically create tax distributions and invoice price variance calculations. The new approval process allows additional system constraints to be applied to an invoice before it’s approved for payment.

Cancelled Invoices

Consider the following modifications to handle cancelled invoices.

• In Oracle Workflow, modify the predefined workflow notifications to show the invoice status. In OAM, set a rule to remove invoices from the approver’s list when the status becomes Cancelled.

Handling Exceptions

If the workflow program fails, then the workflow sends an email or workflow notification (or both) to a designated person such as your system administrator. This person can abort the workflow program, retry the failed workflow activity, or resolve the problem that caused the error to occur.

If you want to override the Invoice Approval Workflow for an invoice, a Payables user can force approve it. You might want to use force approval if there is a problem with the Workflow program and you need to pay an invoice immediately. To force approve an invoice, select it in the Invoices window, then in the Invoice Actions window choose the Force Approval option. This stops the workflow program for the invoice and sets the approval status to Manually Approved. This invoice status cannot be updated, even if the pending approver subsequently approves or rejects the invoice. Also, you cannot resubmit the Invoice Approval Workflow for an invoice that has a status of Manually Approved.

If you want to resubmit an invoice for approval then you can resubmit Invoice Approval Workflow from the Invoice Actions window. You can resubmit the invoice if the approval status is Required, Not Required, Rejected, or Approved. Because the workflow program selects only invoices that require approval and have never started the approval process (approval status is Required), you can’t use the Submit Request window to resubmit approval for an invoice.

You cannot delete an invoice if the Invoice Approval Workflow is processing or has processed it (bug 2386392).

Inquiry and Reporting

Use the Invoice Approval History window to review the approval progress of any invoice that has started or completed the Invoice Approval Workflow process.

This window shows you all the approvers for an invoice in the order that the workflow requests approval from them. You can see who has reviewed the invoice, whether the approver approved or rejected it, the response date, what the invoice amount was when the approver reviewed it, and any comments the approver entered. You also see who the pending approver is and who the planned approvers are. If an invoice is force approved, then you see the username of the person who approved the invoice. Since this window does not automatically update, you should re-query the window to see up-to-date information on an invoice.

You can access this window from either the Invoices or Invoice Overview window. To do so select an invoice and then select View Invoice Approval History from the Tools menu.

Alternatively you can submit the Invoice Approval Status Report to monitor invoices that are in the Invoice Approval Workflow process as of the date and time the report is run. The report also shows invoices that have completed the process because they were approved or rejected. You can use this report to determine which invoices require approval (regardless of payment status) and review all pending approvers for a particular supplier.

Workflow Administration

If the Invoice Approval Workflow is the only workflow your site is using. You will also have some additional workflow administration tasks.

Schedule the Workflow Agent Listener to run regularly (as System Administrator from standard report submission or from Oracle Applications Manager). This task may not be necessary if you are already using other workflow processes – just check to ensure that the seeded agent listener service component named Workflow Deferred Agent Listener, is running for the WF_DEFERRED agent.

Set up and test Workflow’s use of email notifications (including possibly modifying the standard email template.) Do not underestimate the scope of this task – it is rarely straightforward and will require a technical resource.

Identify and set up a designated person as your workflow administrator to receive notification of workflow errors through the Oracle Workflow Default Error Process. Oracle recommend that the person who receives OAM error notifications should also receive Oracle Workflow process error notifications. If a technical user is assigned this role, consider also assigning a functional user a monitoring role to ensure that any non-technical issues are detected and resolved.

Review and set Workflow profile options. For example WF: Mailer Cancellation Email prevents notification mailers from sending any notification cancellation messages.

If you are new to all these tasks and find the Oracle Workflow Administrator’s Guide a bit daunting initially, you might start by reading Donna Christie’s Workflow Admin paper cited in the Appendix of this paper. It provides a good introduction to Workflow Administrator functionality.

Conclusion

This high level overview has covered the implementation of the Invoice Approval Workflow process.

The author would like to thank Brisbane City Council for allowing access to their test environment to obtain some of the screen shots used in this paper.

The author would also like to thank ASSIST for allowing Donna Christie to referee this paper. Donna provided helpful comments and input and her contribution was significant.

Further Reading / References

With Isaac Newton I would like to acknowledge that I have “stood on the shoulders of giants”. Here are some of them:

Karen Brownfield ABC’s of Building Workflow

Donna Christie, Workflow for System Administrators in R11i

Brian Cooney The Horse Before the Cart: Decide What’s Needed Before How to Implement It

Alicia Hoekstra & John Stouffer To Patch or Not To Patch … It’s Not a DBA Question

Michael Milano, MetaLink Whitepaper: Invoice Approval Workflow

Douglas A. Volz Don't Forget Your Business Processes! Oracle Can't Do it All for You!

N.B. All of these papers (except Michael Milano’s MetaLink whitepaper) are available from the OAUG conference paper database, available to OAUG members (www.oaug.org).

invoice approval workflow

Documents

relative job

workflow agent

standard report

end nodesthese

force approval

invoice actions

oam user guide

oracle approvals