Defining Workflow Processes

This chapter covers the following topics:

Expenses Workflow

The Expenses workflow process defines the administrative tasks necessary for managers and your accounting department to review and approve expense reports entered in Internet Expenses. The Expenses workflow process also routes information about expense reports and various notifications to managers and employees so that these tasks can be completed. You can modify the predefined workflow process by defining any company-specific policies that your business requires.

When an employee submits an expense report, the Workflow Engine initiates the Expenses workflow process. This workflow consists of several connected processes that send notifications to managers and employees, ensure reports adhere to company policy, check manager approval levels and, if necessary, split an expense report into multiple reports.

Accessing the Expenses Workflow Processes

You can view the Expenses workflow process in a Process window using Oracle Workflow Builder.

To display the process in Oracle Workflow Builder:

  1. Choose Open from the File menu, and connect to the database.

    Alternatively, you can connect to the workflow definitions file apwxwkfl.wft, located in the product directory tree of your Oracle Applications server.

  2. Expand the data source, then the Item Type branch within that data source.

  3. Expand the Processes branch within your item type then double–click on a process activity to display the diagram of the process in a Process window.

Setting Up Workflow Builder for the Expenses Process

Before you can use the Expenses Process to initiate a workflow, you must set up workflow activity attributes, timeouts, and performers using Workflow Builder. This table lists the setup steps and indicates whether each is required or optional:

Step Number Step Description Required or Optional
1 Set workflow activity attributes. See: Setting Workflow Activity Attributes for the Expenses Process. Required
2 Set workflow timeouts. See: Setting Workflow Timeouts for the Expenses Process. Optional
3 Set expense reports performers. See: Setting Expense Report Performers for the Expenses Process. Required
4 Defer workflow process at submit time. See: Deferring the Workflow Process for the Expenses Process. Optional

Setting Workflow Activity Attributes for the Expenses Process

To set up workflow activity attributes:

  1. From the Processes branch, double click the appropriate process.

  2. From the Processes diagram, double click the appropriate function.

  3. In the Navigator Control Properties window, click the Node Attributes tab.

  4. In the Attribute region, select the activity attribute from the Name field.

  5. Select or enter the desired value in the Value field.

  6. Click Apply and then, click OK.

  7. Save your work.

Define Your Find Approver Method. The associated attribute is Find Approver Method. This Find Approver function activity is part of the Manager (Spending) Approval process. The Find Approver activity controls how workflow routes expense reports during the management approval process. See also: Finding and Verifying Approvers.

Notify Preparer When Resend Count Equals Limit. The associated attribute is Number of Times to Notify Manager. This function activity belongs to the No Manager Response process.

The attribute value (1, 2, 3,...) you define here controls the number of times workflow sends an expense report to a manager for approval. If the number of times a manager does not respond equals the number you define here, then workflow notifies the preparer that the manager did not respond to the approval request.

Sum of Exp Lines with Missing Receipts Exceeds AP Limit. The associated attribute is AP Limit of Sum of Missing Receipt Expense Lines. This function activity belongs to the Manager (Spending) Approval process. The attribute value you define here determines whether workflow requests a second approval from managers for an expense report they previously approved. This second approval confirms that managers recognize they have approved expense reports with missing receipts for a specific amount. For example, if you define this value as 200, then expenses reports with missing receipts that exceed $200.00 are forwarded to managers for a second approval.

Employee Approval Required. The associated attribute is Employee Approval Required. This function activity belongs to the Third Party Expense Report process. The value you define here (Yes or No) controls the kind of notification employees receive when their authorized delegate submits expense reports for them. (An authorized delegate is an employee with the responsibility to enter expense reports for another employee.) If you define the value as Yes, workflow requests employees to approve or reject expense reports created by their authorized delegates. If you define the value as No, workflow notifies employees when their authorized delegates submit expense reports for them (approval is not required).

Loop Counter. The associated attribute is Loop Limit. This function activity belongs to the Third Party Expense Report process. The value you define here limits the number of times workflow transitions through the Request Employee Approval notification activity. (The Request Employee Approval activity requests that an employee approve or reject an expense report entered by their authorized delegate.) If an employee does not respond to the Request Employee Approval notification before this attribute equals the number you specify, workflow transitions to the End (Continue) activity. Therefore, if an employee does not respond to the Request Employee Approval notifications, the Third Party Expense Report process ends with the same result as if the employee had approved the expense report.

Req Proof Of Payment Even If Mgr Apprvd Receipt Missing. The associated attribute is Always Require Proof Of Payment. This function activity belongs to the Manager (Spending) Approval process. When you define expense report templates in Payables, you specify whether employees are required to submit receipts (that is, proof of payment) for expense types that exceed a certain amount. For example, you can specify that employees submit receipts for all meals (an expense type) that exceed a certain value (for instance, 200). If a user submits an expense report with a meal expense type that cost more than 200, Internet Expenses populates the RECEIPT_REQUIRED_FLAG column of the AP_EXPENSE_REPORT_LINES_ALL table with the value “Y”.

When users enter expense reports in Internet Expenses they can check the Original Receipt Missing check box to indicate they do not have proof of purchase (an original receipt) for an expense. The value you define (Y or N) for the Always Require Proof of Payment attribute controls how workflow manages expense items that:

If you define the value as “N”, workflow changes the value of the RECEIPT_REQUIRED_FLAG column in the AP_EXPENSE_REPORT_LINES_ALL table from “Y” to “N” if employees check the Original Receipt Missing check box. Defining the value as “N” enables workflow to make proof of payment unnecessary if employees indicate that they do not have proof of payment (for example, she lost the receipt).

Note: You can require that managers approve an expense report twice if an expense report has missing receipts of a certain amount. The second approval notification ensures that managers acknowledge they are approving an expense report that contains missing receipts. See also: Sum of Exp Lines With Missing Receipts Exceeds AP Limit (Node 13).

If you define the value as Y, workflow cannot change the value of the RECEIPT_REQUIRED_FLAG column from “Y” to “N”, even if an employee checks the Original Receipt Missing check box. Setting this value to “Y” makes proof of payment necessary for every expense type in an expense report that exceeds the value defined in the Expense Report Templates window. Expense lines with this expense type that do not have original receipts (proof of payment) cause the report to be short paid during the Missing Receipts Shortpay process.

Setting Workflow Timeouts for the Expenses Process

You can specify any combination of days, hours, and minutes to indicate when a notification activity times out. For example, you can specify that a manager has five days to respond to an expense report approval notification before the notification activity times out. If a notification is not completed by the specified time, workflow redirects the process to transition to another activity. For example, if a manager does not respond to an expense report approval notification in time, the Request Approval process transitions to the No Manager Response process.

To set up a notification activity's timeout value:

  1. From the Processes branch, double click the appropriate process.

  2. From the Processes diagram, double click the appropriate notification.

  3. In the Navigator Control Properties window, click the Node tab.

  4. In the Timeout region, enter desired values in the Value fields for days, hours, and minutes.

  5. Click Apply and then click OK.

  6. Save your work.

Internet Expenses provides seeded values for all of these notification activities, grouped by processes. You can also specify another timeout value:

Setting Expense Report Performers for the Expenses Process

All workflow notifications require a performer to be assigned to the notification. If a performer is not assigned, then Workflow will fail to send the notification.

All of the standard notifications come seeded with a performer. While some of the notification's performers are based on the item attribute associated with the notification message, other performers need to have a role assigned to the performer. For purposes of this discussion, roles are synonymous to employees defined in the Human Resources database.

When you define a notification's performer, you need to specify the Type of the Performer as well as the Value. If you select Constant for the Type, then the Value field will be limited to the roles that are loaded into the database. If you select Item Attribute for the Type, then all of the Item Attributes defined in the Expenses workflow will be available in the Value field.

For ease of maintenance, it is recommended that the notifications discussed below be set to the Type of Item Attribute. Then select either the AP or AP Expense Report Workflow Administrator item attribute.

Perform these steps in Oracle Workflow Builder to set up expense report performers. These steps include recommendations for which item attribute to use for each notification.

  1. Load Roles: To load roles (employees):

    1. From the Files menu, select Load Roles from Database.

    2. In the Role Selection window, query the appropriate roles from the Find Roles field.

    3. From the Query Results region, select the required roles and click the Add button to add the roles to the Loaded Roles region.

    4. Click OK to save the loaded roles to the database.

    5. Save your work.

  2. Assign Role to the attribute:

    1. From the Navigator window, open the attribute.

    2. In the Navigator Control Properties, under the Attribute tab the Type in the main region should be set to Role.

    3. In the Default region, select the proper Value (role) and click Apply.

    4. Save your work.

    5. Assign a role for each of the attributes listed in the Performer Definitions table below.

  3. Define Notification Performers. For each notification outlined in the Performer Definitions table below:

    1. Open the appropriate workflow process.

    2. In the workflow process, open the notification.

    3. In the Navigator Control Properties window, click the Node tab.

    4. In the Node tab's Performer region, select Item Attribute as the Type.

    5. For the Value, select the appropriate attribute as documented in the Performer Definitions table below.

    6. Click Apply and save your work.

      Note: By performing the steps above, you are indirectly linking a role to the notification. If you want to directly link a role to a notification, then set Performer Type as Constant instead of Attribute. Then, select the proper role. By using the Constant type, you have more flexibility. However, by using the item attribute, maintenance is minimized when any of the performer roles need to be changed.

Performer Definitions

This table lists the notifications and seeded performer for each workflow process.

Workflow Process Name Notification Performer (Attribute)
Server Side Validation Process Inform Sys Admin of Payables Validation Failure AP Expense Report Workflow Administrator
Server Side Validation Process Inform Sys Admin of Custom Validation Failure AP Expense Report Workflow Administrator
Server Side Validation Process Inform Individual of Expense Allocation Failure Notification Expense Allocations Administrator
Manager (Spending) Approval Process Inform System Administrator - No Approver AP Expense Report Workflow Administrator
Manager (Spending) Approval Process Inform AP Mgr Approved ShortPay With Missing Receipts AP
AP Approval Process Request AP To Review For Spending Policy Compliance AP
Rejection Process Inform AP Exp Report They Reviewed Is Mgr Rejected AP
Policy Violation Shortpay Process Provide AP With Missing Info To Rectify Policy Shortpay AP
Bothpay Process Inform System Administrator - No Vendor AP Expense Report Workflow Administrator
AP Custom Default Error Process AP Custom Default Error Notification AP Expense Report Workflow Administrator

Note: It should be noted that the performers listed in the table above are already seeded in the workflow notifications. In addition, the setup steps above are recommendations on how to use the seeded item attributes. For additional flexibility, you can configure workflow by creating new item attributes and then perform the same setup steps above.

Deferring the Workflow Process for the Expenses Process

To improve the performance at submit time, you can defer the workflow process upon expense report submission.

To defer the workflow process:

  1. Using Workflow Builder, open the file:

    $AP_TOP/patch/115/import/US/apwxwkfl.wft

  2. From the Workflow Builder Navigator, expand the Processes list and double-click on the AP Standard Expense Report Process.

  3. Double-click on the activity: Determine Which Process To Start From. Alternatively, right-click on the activity and select Properties.

  4. In the Navigator Control Properties region, click the Function tab.

  5. Select Properties.

  6. Set the Cost field to a number larger than zero.

  7. Save your work.

Related Topics

Activities, Oracle Workflow Developer's Guide

Process Window, Oracle Workflow Developer's Guide

Extending the Expenses Workflow

Although you can use the predefined Expenses workflow in its current state, you may want to configure the process to accommodate your organization's specific needs. You can modify the predefined PL/SQL client extensions to extend the basic functionality of Internet Expenses to implement and automate company–specific business rules.

Expenses Workflow Procedures

The PL/SQL procedures of the Expenses workflow are contained in two packages, AP_WEB_EXPENSE_WF.apwxwkfb.pls and AP_WEB_EXPENSE_CUST_WF.apwxwfcb.pls located in $AP_TOP/patch/115/sql/apwxwfcb.pls.

AP_WEB_EXPENSE_WF.apwxwkfb.pls. Do not configure any of PL/SQL procedures in this package. Modifying, replacing, or removing any of the procedures in this package can interfere with the proper functioning of the Expenses workflow.

AP_WEB_EXPENSE_CUST_WF.apwxwfcb.pls. This package contains PL/SQL procedures that you can modify. Some of the procedures in this package contain seeded business logic while others contain no seeded logic and are simply “hooks” to which you can add custom logic.

Note: To help you with modifications, refer to the sections that describe the components of this process so you know what attributes have already been predefined and what activities are requirements in the process.

You can modify these procedures in the AP_WEB_EXPENSE_CUST_WF package:

See also: Chapter 5, "Implementing Client Extensions". We recommend that you do not create custom processes to replace the seeded processes. Doing so interferes with the proper functioning of the Expenses workflow.

Expenses Item Type

The Expenses workflow is associated with an item type called Expenses. This item type identifies all of the available Expenses workflow processes.

These processes are associated with the Expenses workflow:

The Expenses item type has many associated attributes. Most of these attributes reference information in the database tables AP_EXPENSE_REPORT_HEADERS_ALL and AP_EXPENSE_REPORT_LINES_ALL. These attributes are used and maintained by function activities as well as notification activities throughout the process.

Expenses Workflow Item Type Attributes

The Expenses workflow is associated with the item type Expense Report. This item type identifies all workflow processes available.

This table lists all the item type attributes for the Expenses workflow with their descriptions, field type, and their associated lengths, formats, or lookup types.

Display Name Description Type Length/ Format/ Lookup Type
(Negative) Credit Display Total The total formatted amount of credit (negative) expense lines in a report Text 50
(Negative) Credit Total The total amount of credit (negative) expense lines in a report Number No Access
(Positive) New Expense Display Total The total formatted amount of expense lines in a report Text 50
(Positive) New Expense Total Total amount of expense lines in a report Number No Access
AP The person within the payables department that receives workflow notifications Role No Access
AP Required Policy Info Information required according to accounts payable department policy Text 2000
Expense Report Workflow Administrator The name of the Expenses workflow administrator Role No Access
Approval or Rejection Reason Reason the report is approved or rejected Text No Access
Approver Display Name How the approver's name appears in notifications Text No Access
Approver ID The identification number of the approver Number No Access
Approver Name The approver's name Text No Access
Bothpay Document Number The number of the invoice that is created when an expense report containing both out of pocket expenses and credit card transactions is approved in the 'Bothpay' payment scenario Text No Access
Currency The reimbursement currency Text 25
Display Total The total amount of an expense report Text 50
Document Cost Center The cost center entered for an expense report Text No Access
Employee Cost Center The cost center of the employee Text No Access
Employee Display Name How the employee's name appears in notifications Text 80
Employee ID The unique identification number of the employee Number No Access
Employee Name The name of the employee Text 30
Error Activity ID Activity identification number of the error activity Number No Access
Error Assigned User Role assigned to perform error activity Text 30
Error Item Key Item key or error activity Text 240
Error Item Type Item type of error activity Text 8
Error Message Error message that appears in notifications Text No Access
Error Name Error code raised by error activity Text 30
Error Notification ID Notification identification number of error activity Number No Access
Error Result Code Result of error activity Text 30
Error Stack Error stack of error activity Text 2000
Expense Report Details A hypertext link that appears in a notification that employees can click on to view details about an expense report URL Full Window
Expense Report ID Expense Report ID Number No Access
Expense Report Number Expense Report Number Text No Access
Expense Report Total Total amount of the expense report Number No Access
Find Approver Count Number of times the process searches for an approver Number No Access
Forward From Display Name The display name of the approver who forwarded the report Text No Access
Forward From ID The identification number of the approver who forwarded the report Number No Access
Forward From Name The name of the approver who forwarded the report Text No Access
Is Employee Project Enabled Yes or No flag that indicates whether an employee can enter project–related information in expense reports Text 1
Line Info Body Stores expense lines that are shortpaid or adjusted Text 2000
Line Table Stores information about all expense lines Document Full Window
Manager Approval Send Count Counts how many times a manager sends approval Number No Access
Manager Display Name How a manager's name appears in notifications Text No Access
Manager ID A manager's unique identification number Number No Access
Manager Name The manager's name Text No Access
Missing Receipt Total The total amount of all receipts missing from an expense report Text 50
Missing Receipts Shortpay Document Number The invoice number of the new, short paid report created because of missing receipts Text No Access
Missing Receipts Shortpay Expense Report ID Report identification number for new, short paid report created because of missing receipts Number No Access
Missing Receipts Shortpay Total Total of short paid report created because of missing receipts Text 50
Original Expense Report Doc Num The expense report from which an expense report is shortpaid Text No Access
Payment Due From Checks the Payment Due From setting in the Card Programs window Text No Access
Policy Shortpay Document Number Document number of new expense report created due to a policy violation Text No Access
Policy Shortpay Expense Report ID Expense report identification number of new expense report created due to a policy violation Number No Access
Policy Shortpay Total The total amount the expense report was shortpaid Text 50
Preparer Display Name How the preparer's name appears in notifications Text 80
Preparer Name Name of the person who created the expense report (usually the employee) Text 30
Preparer ID The identification number of the person who created the expense report Number No Access
Purpose The reason provided for creating the expense report Text 240
Purpose In Document The reason provided for creating the expense report Document Full Window
Receipt Missing Warning Text in a notification that informs the employee or manager that a report is missing receipts Text 2000
Start from Specified Process Flag that determines which process begins the Expenses workflow Lookup AP Start from Specified Process
Vendor ID The identification number of the vendor that provided goods or services for the employee's corporate credit card transactions Number No Access
Vendor Site ID The identification number of the vendor site that provided goods or services for the employee's corporate credit card transactions Number No Access
Version The workflow version number Number No Access
Week Ending Date The week ending date specified for the expense report Date No Access

Related Topics

Item Types, Oracle Workflow Developer's Guide

Expenses Workflow Processes

This section details the various processes that comprise the Expenses workflow. These processes are:

AP Standard Expense Report Process

The AP Standard Expense Report process manages the entire workflow process for expense reports created in Internet Expenses. This process is initiated automatically when an employee submits an expense report for approval in Internet Expenses. This process activity can also be initiated as a top level process by making calls to the Workflow Engine APIs CreateProcess and StartProcess.

To view the properties of the AP Standard Expense Report process, select the process in the navigator tree, then choose Properties from the Edit menu. The AP Standard Expense Report process has a result type of Approval, indicating that when the process completes, it has a result of either Approved, Rejected, Returned, or Withdrawn.

The Details property page of the process activity indicates that the AP Standard Expense Report process is associated with an error process called DEFAULT_PROCESS (Error Process with Retry). Initiated only when an error occurs, DEFAULT_PROCESS notifies the system administrator and provides information about the error.

Note that three activities in the Expenses workflow contain specific error handling logic. When these activities fail, the workflow sends a special error notification to the system administrator.

This table lists these activities and their corresponding error notification activity.

Function Activity Notification Activity
AP Validate Expense Report (Server Side Validation process) Inform Sys Admin of Payables Validation Failure
Custom Validate Expense Report (Server Side Validation process) Inform Sys Admin of Custom Validation Failure
Find Approver (Manager Spending Approval process) Inform System Administrator – No Approver

For example, the process sends the workflow system administrator a notification when no approver is found while executing the Find Approver function activity. The system administrator must fix the error before the process can continue.

The AP Standard Expense Report has 13 different activities, one of which is reused, so 17 activity nodes are described below.

The AP Standard Expenses workflow begins when a user submits an expense report using Internet Expenses (Node 1). At Node 2, the process determines at which subprocess the approval process begins. By default, all expense reports transition to the Server Side Validation process (Node 3). Expense reports that passed the validations transition to the Manager (Spending) Approval process (Node 4).

Node 3 is a subprocess that updates an expense report with required information (for example, the employee's expense account) so the approval processes and the Expense Report Export program can process the report.

Node 4 is a process that routes an expense report to the appropriate managers for approval. If it is approved, the report transitions to the AP Approval process (Node 7). Otherwise, the report transitions to the Rejection process (Node 5) or Return Expense Report process (Node 6).

Node 7 is a process that determines whether the report requires approval from the accounts payable department. If the report is approved and is not short paid, then the process transitions to the Bothpay process (Node 11) which checks the setting for the Payment Due From field in the Card Programs form. If the Payment Due From field is set to Both, then the workflow continues with the Bothpay process. If the Payment Due From field is not set to Both, then the workflow transitions to the Mileage process (Node 12).

If the accounts payable department short pays the expense report, then the workflow transitions to the Policy Non-Compliance Control process (Node 10). This process creates new expense reports from the lines that the accounts payable department short paid, and routes the new expense reports to either the Missing Receipts Shortpay activity, or the Policy Violation Shortpay activity.

Node 5 is a process that notifies the employee when the expense report is rejected by management. The process then pauses until the rejected expense report is resubmitted. If the report is not resubmitted within the specified time period, then the report is deleted from the system.

AP Standard Expense Report Process Activities

This section provides a description of each activity in the process, listed by the activity's display name.

Server Side Validation Process

The Server Side Validation process checks that the report contains all required information and populates columns in Oracle Payables tables so the Expenses workflow and the Expense Report Export program can process the report.

The Server Side Validation process has a result type of None, which indicates that when the process completes there is no specific result. This subprocess cannot be initiated as a top level process to run; it can only be run as a subprocess when called by another, higher level process. To view the properties of the Server Side Validation process, select the process in the navigator tree, then choose Properties from the Edit menu.

The Server Side Validation Process differentiates code combination errors from the other errors. When the process detects a code combination error, a new notification is sent to a new responsibility. You can set this new responsibility as system administrator or a new role.

From the new notification, the administrator can click on a link to a page that lists the expense allocation errors. The administrator can access a correction page to correct the expense allocations.

The Server Side Validation process has 7 different activities, none of which are reused, so 7 activity nodes appear in the workflow diagram below. To examine the activities of the process in more detail, we have numbered each node for easy referencing below. The numbers themselves are not part of the process diagram.

Server Side Validation Process

the picture is described in the document text

This process begins at Node 1 with the Start activity. At Node 2 the process validates the report and populates columns in the Oracle Payables tables AP_EXPENSE_REPORT_HEADERS and AP_EXPENSE_REPORT_LINES_ALL so the workflow approval processes and the Expense Report Export program can process the report. If the report fails at Node 2, the process notifies the system administrator (Node 3).

At Node 5 the process executes custom logic that you define using the Accounts Payable Involvement Extension (see Accounts Payable Involvement Procedure (CustomValidateExpenseReport)). If the report fails at Node 5, the process notifies the system administrator (Node 6). When the problem is fixed and the report passes validation, the process ends (Node 7).

Server Side Validation Process Activities

This section provides a description of each activity in the process, listed by the activity's display name. Each node corresponds to the workflow icons that appear in the above illustration.

Manager (Spending) Approval Process

The Manager (Spending) Approval process verifies that a report requires manager approval, then forwards it to the appropriate managers for approval.

The Manager (Spending) Approval process has a result type of Approval, indicating that when the process completes, it has a result of Approve or Reject. This subprocess cannot be initiated as a top level process. It can only be run as a subprocess when called by another, higher level process. To view the properties of this process, select the process in the navigator tree, then choose Properties from the Edit menu.

To examine the activities of the process in more detail, we have numbered each node for easy referencing in the following illustration. The numbers themselves are not part of the process diagram.

the picture is described in the document text

This process begins at Node 1 with the Start activity. If the Third Party Expense Report subprocess (Node 3) returns a result of Continue, the process transitions to the AME Enabled activity. Otherwise, the process ends with a result of Reject.

At Node 4 the process determines if Oracle Approvals Management (AME) is enabled:

After approval, the process transition to the Manager (Shortpay) Approval Subprocess.

If the expense report is approved or no approval was required, then the process marks the expense report with a status of Manager Approved (Node 10). The process then informs the preparer that the expense report has been approved by management (Node 12).

Manager (Spending) Approval Process Activities

This section describes each activity in the Manager (Spending) Approval process, listed by the activity's display name. Each node corresponds to the workflow icons that appear in the illustrations.

Non-AME Approval Process

The Non-AME Approval Process manages the sending of notifications to managers for approval of expense reports, when Oracle Approvals Management (AME) is not enabled.

the picture is described in the document text

The process begins with the Start activity and transitions to the Find Approver activity (Node 1). This process attempts to identify an approver for an expense report. If the approver cannot be identified, then the process notifies the system administrator.

At Node 2, the process determines whether expense reports require manager approval, manager notification, or no manager involvement. If an expense report requires only manager notification, the process ends and returns to Node 8 in the Manager (Spending) Approval Process. If an expense report does not require any manager involvement, the process ends and returns to Node 9 in the Manager (Spending) Approval Process.

Expense reports that require manager approval transition to the Request Approval process (Node 3). If the Request Approval process returns a result of Approved, the process transitions to the Verify Authority activity (Node 4). If the Request Approval process returns a result of Reject, the process ends.

The Verify Authority activity (Node 4) determines whether an expense report exceeds the signing limit of the approver and whether the approver has signing authority for the cost center to which an expense report is charged. If an expense report fails the Verify Authority activity, the process records the name of manager who previously approved the expense report (Node 5), and the process returns to the Find Approver activity (Node 1).

Non-AME Approval Process Activities

Manager (Shortpay) Approval Subprocess

The Manager (Shortpay) Approval Process manages the sending of notifications to managers for approval of shortpaid expense reports.

the picture is described in the document text

The process begins with the Start activity and transitions to the Check If ShortPaid Expense Report activity (Node 1).

At Node 4, the process determines whether the total of missing receipts on an expense report exceeds the limit you define. For a description of how to set this limit, see Setting Workflow Activity Attributes for the Expenses Process. If the expense report exceeds the limit, the process confirms that the approver recognizes that he has approved an expense report that has missing receipts of a certain amount (Node 6).

If the expense report does not exceed the limit, the process ends and transitions back to the Manager (Spending) Approval Process to mark the expense report with a status of Manager Approved (Node 10). The Manager (Spending) Approval Process then informs the preparer that the expense report has been approved by management (Node 12).

Manager (Shortpay) Approval Subprocess Activities

AME Approval Process

The AME Approval Process manages the sending of notifications based on Oracle Approvals Management setup.

the picture is described in the document text

AME Approval Process Activities

This section provides a description of each activity in the process, listed by the activity's display name.

AME Request Approvals Process

This process requests approval from approvers when Oracle Approvals Management is enabled.

the picture is described in the document text

AME Request Approvals Process Activities

This section provides a description of each activity in the process, listed by the activity's display name.

Post Notification Activities

After the AME Request Approvals Process is completed, the AP_WEB_EXPENSE_WF.IsApprovalRequestTransferred function is called.

This function process results in the following two cases:

Finding and Verifying Approvers

The Manager (Spending) Approval process includes the activities Find Approver and Verify Authority. The functionality of these activities differ based on whether or not you have implemented Oracle Approvals Management to handle expense report approval routing. This section describes the functionality for both scenarios.

Find Approver and Verify Authority Behavior without Approvals Management

The behaviors of the approver selection and verify authority for the Manager (Spending) Approval Process are based on your selected Find Approver method.

The predefined Find Approver methods are:

Go Up Management Chain Method. This method first sends the expense report to the employee's direct manager. If the direct manager approves the expense report, the Verify Authority activity determines whether the expense report exceeds the direct manager's signing limit. If the expense report does not exceed the manager's signing limit, then the expense report passes the Verify Authority activity and the expense report continues to the Check if ShortPaid Expense Report activity.

If the expense report exceeds the direct manager's signing limit, the expense report fails the Verify Authority activity. The expense report then returns to the Find Approver activity which routes the expense report to the direct manager's manager for approval. This process continues (goes up the employee's management chain) until the expense report is either rejected or a manager with the necessary signing limit approves the expense report.

Note: Managers can reject expense reports even if they do not have the authority to approve them.

One Stop Then Go Directly Method. This method first sends the expense report to the employee's direct manager. If this manager approves the expense report, the Verify Authority activity determines whether the expense report exceeds the manager's signing limit. If the expense report does not exceed the manager's signing limit, the expense report passes the Verify Authority activity and the expense report continues to the Check if ShortPaid Expense Report activity.

If the expense report exceeds the direct manager's signing limit, it fails the Verify Authority activity. The expense report then returns to the Find Approver activity. The Find Approver activity routes the expense report to the nearest manager in the employee's management chain who has the signing authority necessary to approve the expense report. That is, the workflow searches the employee's management chain until it finds a manager with the necessary signing authority. Because the manager identified has the necessary signing authority, the expense report passes the Verify Authority activity if the manager approves the expense report.

Go Directly to Person With Signing Authority Method. This method routes the expense report directly to the nearest manager in the employee's management chain with the signing authority necessary to approve to the expense report. That is, it goes up the employee's management chain until it finds a manager with the necessary signing authority. If the manager approves the expense report, the report passes the Verify Authority activity, because the manager identified has the necessary signing authority.

Note: If you choose this option as the Find Approver method, expense reports may not be routed to direct managers for approval (the amount of the expense report and the direct manager's signing limit determine this). The CC Direct Manager notification activity in the Request Approval process informs managers when employees who report to them submit expense reports that do not require their approval.

Using Alternate Approvers. If a user selects an alternate approver, the approval process first routes the expense report to the alternate approver. If the alternate approver approves the expense report, the Verify Authority activity determines whether the expense report exceeds the alternate approver's signing limit. The Verify Authority activity also determines whether the alternate approver has signing authority for the cost center to which the expense report is charged. If the expense report does not exceed the alternate approver's signing limit, and the alternate approver has the correct cost center singing authority, the expense report passes the Verify Authority activity.

Note: If an employee enters an alternate approver, the expense report is not routed to the employee's direct manager for approval. The CC Direct Manager notification activity in the Request Approval process informs managers when employees who report to them submit expense reports that do not require their approval.

If the expense report exceeds the signing limit of the alternate approver, or the alternate approver does not have the correct cost center signing authority, the expense report fails the Verify Authority activity. The expense report then returns to the Find Approver activity. At this point, the Find Approver activity will handle the expense report differently based on the Find Approver method you are using.

However, if you are using the Go Directly to Person with Signing Authority method, both the Find Approver and Verify Authority activities are simplified. The Find Approver activity routes the expense report to the nearest manager in the alternate approver's management chain with the signing authority necessary to approve the expense report. If this manager approves the expense report, the expense report passes the Verify Authority activity because the manager identified has the necessary signing authority. However, if the user enters an alternate approver who does not have the authority to approve expense reports for the specified cost center, the expense report fails the Verify Authority activity.

The Find Approver activity will not find an approver if users charge expense reports to cost centers different from their default cost centers and they do not enter an Alternate Approver. To prevent users from submitting expense reports with this scenario, set the profile option OIE: CC Approver Req to Yes. If this profile option is set to Yes, employees who charge an expense report to a cost center that is not their own must enter an alternate approver. However, an employee can enter an alternate approver who does not have signing authority for the cost center entered on the expense report.

If an alternate approver is assigned to an expense report and that approver does not have signing authority for the cost center specified, the manager approval process fails when it reaches the Verify Authority function activity regardless of the selected Find Approver method. Internet Expenses users must ensure that the alternate approver entered has signing authority for the specified cost center.

Transferring Approval Ownership. Approvers can change the approval ownership of an expense report. A Reassign button is available on the approval request which enables the approver to designate a new approver.

Find Approver and Verify Authority Behavior with Approvals Management

When enabled, Oracle Approvals Management approval routing rules are used by the Manager (Spending) Approval process. This workflow process still handles the overall flow of the expense report. However, the behaviors of these activities are modified to account for Approvals Management routing rules:

The Find Approver activity sends the specified approver of the expense report to an Approvals Management API. This API builds an approval chain based on the normal Human Resources hierarchy of this approver and the rules you have defined in Approvals Management if the approval chain does not exist. For example, you define a rule that specifies that expense reports over a certain dollar amount requires approval from a manager with a job grade level of 2. When an expense report is submitted that exceeds this dollar amount, Approvals Management builds the approval chain based on the HR hierarchy until it reaches an approver with that level.

Note: When expense lines are split into multiple distributions, Approvals Management can build multiple approval chains that require approvers to review and approve expense reports in parallel. See: Reviewing and Approving Expense Allocations With AME.

Once a manager approves the expense report, the Verify Authority checks the authority of the specified approver on the expense report. If the approver has the required authority for the expense report, then the approval process proceeds to the next step in the Manager (Spending) Approval Process. If the approver does not have the required authority, then Verify Authority cancels and the Find Approver activity is reactivated to retrieve the next approver from the pre-built approval chain. The expense report is then sent to this approver. This cycle continues until the expense report is approved by the final approver on the chain.

As the expense report is escalated to each approver, a notification is sent to the preparer that the expense report has been forwarded for approval. The process for releasing this notification is handled by the Record Forward From Info activity.

To summarize, Approvals Management is used to create a temporary approval chain based on the HR hierarchy and rules, and to return the next approver from the approval chain.

Using Alternate Approvers. The normal Human Resources hierarchy is used by Approvals Management to build the approval chain for an expense report. This chain is rebuilt if a user specifies an alternate approver. In this case, the approval chain is based on the selected alternate approver.

Transferring Approval Ownership. An approver can transfer the approval ownership of an expense report to another approver. When this occurs, the approval chain is rebuilt based on the new approver.

Third Party Expense Report Process

This process activity ensures that, if required, employees approve expense reports created by their authorized delegate (an employee who enters expense reports for another employee). If approval is not required, this process activity simply notifies the employee that an authorized delegate has submitted an expense report on their behalf.

Note: Whether expense reports submitted by authorized delegates require employee approval depends on the value you choose for the Employee Approval Required function attribute.

The Third Party Expense Report process has a result type of AP Continue or Reject Result Type, indicating that when the process completes, it has a result of Continue or Do Not Continue (the lookup codes in the AP Continue or Reject Result Type lookup type associated with the Expenses item type). This subprocess cannot be initiated as a top level process; it can only be run as a subprocess when called by another, higher level process. To view the properties of the Third Party Expense Report process, select the process in the navigator tree, then choose Properties from the Edit menu.

The Third Party Expense Report has 7 different activities, one of which is reused, so 8 activity nodes appear in the workflow diagram below. To examine the activities of the process in more detail, we have numbered each node for easy referencing below. The numbers themselves are not part of the process diagram.

the picture is described in the document text

The process begins at Node 1 with the Start activity. The process then checks whether the person who submitted the expense report is the same as the employee name on the report. If the employee and preparer are the same, the process ends at Node 7. Otherwise, the process checks whether employee's approval is required. If it is, the process requests approval from the employee (Node 4) and then ends at Node 7 if it receives approval and at Node 8 otherwise. If the report does not require the employee's approval, the process notifies the employee that the report was submitted on their behalf (Node 6) and the process ends (Node 7).

Third Party Expense Report Process Activities

This section provides a description of each activity in the process, listed by the activity's display name. Each node corresponds to an icon in the above illustration.

Request Approval Process

To view the properties of the Request Approval activity process, select the process in the navigator tree, then choose Properties from the Edit menu. The Request Approval process has a result type of Approval, indicating that when the process completes, it has a result of Approved or Rejected (the lookup codes in the Approval lookup type associated with the Standard item type). This subprocess cannot be initiated as a top level process to run; it can only be run as a subprocess when called by another, higher level process.

The Request Approval process activity has 9 different activities, one of which is reused, so 10 activity nodes appear in the workflow diagram. To examine the activities of the process in more detail, we have numbered each node for easy referencing below. The numbers themselves are not part of the process diagram.

the picture is described in the document text

This process begins at Node 1 with the Start activity. At Node 2 the process determines whether a manager has approved the expense report. If a manager has approved the report, the process then checks whether the approver is the employee's direct manager (Node 3). (The Find Approver activity in the Manager (Spending) Approval process determines the approver.) If the approver and the direct manager are not the same, this process sends a notification to the direct manager (Node 4).

If an expense report has been previously reviewed, the process determines whether the expense report has been forwarded to another manager for approval (Node 5). If so, the process informs the preparer that the expense report was approved by a manager that does not have the necessary signing authority and that the expense report has been forwarded to another manager for review (Node 6).

At Node 7 the process sends the expense report to managers for review. Managers can approve, reject, or reassign the expense report. If the manager does not reply within the time period specified for the notification, the process transitions to the No Manager Response process (Node 8).

Request Approval Process Activities

This section provides a description of each activity in the process listed by the activity's display name. Each node corresponds to an icon shown in the illustration.

Post Notification Activities

After the Request Approval Process is completed, the "AP_WEB_EXPENSE_WF.IsApprovalRequestTransferred" function is called.

This function process results in the following two cases:

No Manager Response Process

This process enables the Expenses workflow to manage the approval process when managers do not respond to approval requests, for example, when they go on leave or vacation. It informs the person who prepared the expense report that the manager responsible for approving it did not respond within the time period specified. The preparer can choose to resend the expense report to the same manager, or direct the expense report to the manager's manager.

To view the properties of the No Manager Response process, select the process in the navigator tree, then choose Properties from the Edit menu. The No Manager Response process has no result type and cannot be initiated as a top level process; it can be run only as a subprocess when called by another, higher level process.

The Request Approval process activity has 7 different activities, all of which appear as activity nodes in the workflow diagram below. To examine the activities of the process in more detail, we have numbered each node for easy reference below. The numbers themselves are not part of the process diagram.

the picture is described in the document text

Note: The approval process stalls unless employees reply to No Manager Response messages. The No Manager Response process activity continues to send notifications until a response is given.

This process activity occurs when either of these notification activities time out before being completed:

The process begins at the Start activity (Node 1). At Node 3 the process notifies the person who prepared the expense report that the approver did not respond to any notifications requesting approval.

The process records the approver's information at Node 5 then identifies and resends the request to the approver's manager (Node 6).

No Manager Response Process Activities

This section provides a description of each activity in the process, listed by the activity's display name. Each node corresponds to an icon shown in the previous diagram.

AP Approval Process

The AP Approval process has a result type of AP Approval Process Result, indicating that when the process completes, it has a result of Approved or ShortPay. This subprocess cannot be initiated as a top level process; it can only be run as a subprocess when called by another, higher level process. To view the properties of the AP Approval process, select the process in the navigator tree, then choose Properties from the Edit menu.

The AP Approval process has 15 different activities, one of which is reused, so 14 activity nodes are described below.

This process begins at Node 1 with the Start activity. At Node 2, the process determines, based on the audit rules, whether the expense report requires accounts payable review. At Node 5 the process automatically approves expense reports that do not require accounts payable review. If an expense report requires accounts payable review, the process checks whether the review is complete (Node 7). If the review is not complete, the process pauses until the accounts payable department reviews the expense report.

Note: To indicate a completed review, the accounts payable department clicks the Complete Audit button in the Audit Expense Reports page.

The process determines whether the accounts payable department has adjusted the report (Node 10) and, if necessary, notifies the preparer (Node 11). At Node 12 the process determines whether all expense report lines pass accounts payable department approval. The process approves expense reports with no short paid items (Node 13) and the process ends with a result of Approved (Node 15). If an expense report contains short paid items, the process ends with a result of ShortPay (Node 14).

AP Approval Process Activities

This section provides a description of each activity in the process, listed by the activity's display name. Each node corresponds to an icon in the illustration above.

Shortpay Unverified Receipt Items Process

The Shortpay Unverified Receipt Items process creates a new expense report for each line that is missing required receipts or contains an inadequate justification. This process has a result type of None which means that when the process completes there is no specific result. The Shortpay Unverified Receipt Items process cannot be initiated as a top level process, it can only be run as a subprocess when called by another, higher level process. To view the properties of the Shortpay Unverified Receipt Items process, select the process in the navigator tree, then choose Properties from the Edit menu.

This process has 11 different activities, one of which is reused, so 10 activity nodes appear in the workflow diagram. To examine the activities of the process in more detail, we have numbered each node for easy referencing below. The numbers themselves are not part of the process diagram.

the picture is described in the document text

The process begins at Node 1 with the Start activity. At Node 2 the process creates a new expense report from any lines that have missing required receipts and/or creates a new expense report from the lines that have inadequate justifications. At Node 3 the process determines whether an expense report was created due to inadequate justifications and, if so, transitions to the Spawn Policy Violation Shortpay Subprocess activity (Node 4).

At Node 6 the process determines whether an expense report was created due to missing receipts and, if so, transitions to the Spawn Missing Receipts Shortpay Subprocess (Node 4). At Node 10 the process approves the original expense report.

Shortpay Unverified Receipt Items Process Activities

This section provides a description of each activity in the process, listed by the activity's display name. Each node corresponds to an icon shown in the illustration above.

Bothpay Process

Workflow transitions to the Bothpay process if the Check If Both Pay function activity returns a value of Yes. The Check If Both Pay activity checks the setting of the Payment Due From field in the Card Program window to determine whether the employee, the company, or both the employee and the company are responsible for remitting payment for corporate credit card transactions. The Check If Both Pay function activity checks the Payment Due From field setting after the AP Approval Process or the Shortpay Unverified Receipt Items process is complete.

The Bothpay process cannot be initiated as a top level process, it can only be run as a subprocess when called by another, higher level process. To view the properties of the this process, select the process in the navigator tree, then choose Properties from the Edit menu.

This process has 7 different activities which appear as nodes in the workflow diagram below. To examine the activities of the process in more detail, we have numbered each node for easy referencing. The numbers themselves are not part of the process diagram.

the picture is described in the document text

The process begins at Node 1 with the Start activity. At Node 2 the process checks whether the expense report contains credit card vendor information. If not, a notification is sent to the system administrator (Node 3) to resolve the issue. At Node 4 the Build Bothpay Expense Reports subprocess checks whether the report includes both cash and credit card transactions. If it does, the subprocess creates a new expense report for the credit card issuer (this new expense report generates a new invoice when it is exported to Payables). Otherwise, the expense report is not split and generates only one invoice (for either the employee or the credit card issuer) when exported to Payables.

At Node 5 the process checks whether the expense report was split. If the report was split, the process notifies the person who created the report (Node 6) and the process ends at Node 7.

Bothpay Process Activities

This section provides a description of each activity in the process, listed by the activity's display name. Each node corresponds to an icon shown in illustration above.

Missing Receipts Shortpay Process

The Missing Receipts Shortpay Process informs the person who prepared the report that the accounts payable department short paid one or more lines of the report due to missing receipts and that these lines have been transferred to a new expense report. The preparer can delete the new expense report, submit the missing receipts to the accounts payable department, or route the new expense report to management for approval despite the missing receipts.

This process has a result type of Approval, which indicates that when the process completes, it has a result of Approve or Reject. This subprocess cannot be initiated as a top level process, it can only be run as a subprocess when called by another, higher level process.

To view the properties of the Missing Receipts Shortpay process, select the process in the navigator tree, then choose Properties from the Edit menu.

The Missing Receipts Shortpay process has 9 different activities, one of which is reused, so 10 activity nodes are described below.

The process begins at Node 1 with the Start activity. At Node 3 the process informs the preparer that the accounts payable department short paid one or more lines of the expense report due to missing receipts and that these lines have been transferred to a new expense report. The preparer can delete the new expense report, submit the missing receipts to the accounts payable department, or route the new expense report to a manager for approval without the receipts. If the preparer chooses to delete the new expense report, the process does so at Node 5.

If the preparer had sent the missing receipts without replying to the missing receipts notifications, then the short pay of the expense report closes the notifications workflow for missing receipts.

If the preparer chooses to provide the missing receipts, the process updates the new expense report and begins the AP Standard Expense Report process at the AP Approval process (Node 7). The workflow then calls the AP Standard Expense Report process (Node 8). If the preparer forwards the new expense report to a manager for approval, the process updates the expense report and begins the Expense Report process at the Manager (Spending) Approval process (Node 6). The workflow then calls the AP Standard Expense Report process (Node 8).

If you have Oracle Approvals Management installed, you can use Approvals Management to route the expense report for management approval instead of the Manager Approval process.

Missing Receipts Shortpay Process Activities

This section provides a description of each activity in the process, listed by the activity's display name. Each node corresponds to an icon in the above illustration.

Policy Violation Shortpay Process

The Policy Violation Shortpay Process informs the person who created the expense report that the accounts payable department short paid one or more lines due to inadequate justifications and that these lines have been transferred to a new expense report. The preparer can either delete the new expense report or provide additional information to justify the disputed expenses.

This process has a result type of Approval which indicates that when the process completes, it has a result of Approve or Reject. This subprocess cannot be initiated as a top level process; it can only be run as a subprocess when called by another, higher level process. To view the properties of the Policy Violation Shortpay process, select the process in the navigator tree, then choose Properties from the Edit menu.

The Policy Violation Shortpay process has 9 different activities, one of which is reused, so 10 activity nodes are described below.

The process begins at Node 1 with the Start activity. At Node 3 the process informs the employee that the accounts payable department short paid one or more lines of the expense report due to inadequate justifications and that these lines have been transferred to a new report.

The preparer responds to the notification by deleting the new expense report (Node 8) or providing accounts payable with missing information.

If the preparer provides additional information, the process forwards the information to your accounts payable department for review (Node 5). The process then updates the new expense report (Node 6) and transitions to the AP Standard Expense Report process (Node 7).

Policy Violation Shortpay Process Activities

This section provides a description of each activity in the process, listed by the activity's display name. Each node corresponds to an icon in the above illustration.

Rejection Process

The Rejection process informs the preparer or the accounts payable department that the expense report has been rejected by management. After modifying the report the preparer can resubmit the expense report for approval. However, if the expense report is not resubmitted within the time period specified, the report is deleted.

The Rejection process has a result type of AP Reject Process Result, which indicates that when the process completes, it has a result of Resubmit Report or Abort. This subprocess cannot be initiated as a top level process, it can only be run as a subprocess when called by another, higher level process. To view the properties of the Rejection process, select the process in the navigator tree, then choose Properties from the Edit menu.

The Rejection process has 7 different activities, one of which is reused, so 8 activity nodes appear in the workflow diagram. To examine the activities of the process in more detail, each node is numbered for easy referencing. The numbers themselves are not part of the process diagram.

the picture is described in the document text

The process begins at Node 1 with the Start activity. If the report was previously reviewed by the Payables department but rejected by management, a notification is sent to the Payables department (Node 3). The process then informs the preparer that the report has been rejected by management (Node 4). The process then pauses for a specified period of time until the expense report is resubmitted (Node 6). If the expense report is not resubmitted within the specified time period, it is deleted (Node 7).

Note: Rejected expense reports can be corrected and resubmitted.

Rejection Process Activities

This section provides a description of each activity in the process, listed by the activity's display name. Each node corresponds to an icon in the above illustration.

Credit Cards Workflow

The Credit Cards workflow consists of independent workflow processes and notifications that perform various activities. The following table provides a summary of each process.

Credit Card Workflow Processes

Process Purpose Trigger Event Conditions
Aging Credit Card Transactions Notifies employees and managers of outstanding transactions by aging bucket. Also escalates manager notification. Credit Card Outstanding Transactions Management (Aging) concurrent program is run. Send Notifications parameter is set to any of the Notify... values.
Deactivated Transactions Notifies employees when unused transactions are deactivated and categorized as Historical. The Credit Card Historical Transactions Management program is run. Unused transactions for the employee are deactivated.
Inform Manager of Inactive Employee Transactions Notifies managers of unsubmitted transactions for inactive employees. Also automatically assigns and unassigns the securing attribute to facilitate transaction submission. Credit Card Transactions Inactive Employees Process concurrent program is run. Credit card transactions exist for inactive employees.
Payment to Card Issuer Notifies employees when payments are made to the credit card issuer. Payment is made to credit card issuer in Oracle Payables. OIE: CC Payment Notify profile option is set to Yes. This process only applies to the Both Pay payment scenario.
Payment to Employee Notifies employees when payments are made to them. A direct deposit payment is made to an employee in Oracle Payables. OIE: CC Payment Notify profile option is set to Yes. This process only applies to the Individual Pay payment scenario.
Payment to Employee by Check Notifies employees when payments are made to them. A check payment is made to an employee in Oracle Payables. OIE: CC Payment Notify profile option is set to Yes. This process only applies to the Individual Pay payment scenario.
Process Invalid Credit Card Transactions Notifies the system administrator when invalid transactions are detected during the import and validation process. Any combined load and validate concurrent program is run. Invalid transaction identified.
Process Unassigned Credit Cards Notifies system administrator when new credit cards are created. Also attempts to match new accounts to employees, and can be defined to automatically activate new accounts if a unique match is found. Either the MasterCard or American Express combined load and validate concurrent program is run. Credit card records do not exist in the Credit Cards window.
Unapproved Expense Report Notify managers of unapproved expense reports that contain credit card transactions. Credit Card Outstanding Transactions Management (Details) concurrent program is run. Send Notifications parameter is set to Yes.
Unused Credit Card Transactions Notify Managers and employees of unsubmitted credit card transactions. Credit Card Outstanding Transactions Management (Details) concurrent program. Send Notifications parameter set to Yes.

Note: The workflow processes and related concurrent programs cannot process credit card transactions for terminated employees once the system date is past the final process date of the employee. See: Terminating Employees. For Human Resources shared installs, this check is not applicable.

See: Specifying Values for Internet Expenses Profile Options.

To view the properties of the Credit Cards process, select the process in the navigator tree, then choose Properties from the Edit menu.

The Credit Cards item type has several associated attributes. Some of these attributes reference expense report and employee information in the database tables AP_EXPENSE_REPORT_HEADERS and HR_EMPLOYEES. These attributes are used and maintained by the notification activities throughout the process.

Accessing the Credit Cards Workflow Processes

You can view the Credit Cards workflow process in a Process window using Oracle Workflow Builder.

To display the process in Oracle Workflow Builder:

  1. Choose Open from the File menu, and connect to the database.

    Alternatively, you can connect to the workflow definitions file apwxwkfl.wft, located in the product directory tree of your Oracle Applications server.

  2. Expand the data source, then the Item Type branch within that data source.

  3. Expand the Processes branch within your item type then double–click on a process activity to display the diagram of the process in a Process window.

Setting Up Workflow Builder for the Credit Card Processes

Before you can use the Credit Card process to initiate a workflow, you must set up workflow activity attributes, timeouts, and performers using Workflow Builder. This table lists the setup steps and indicates whether each is required or optional:

Step Number Step Description Required or Optional
1 Set workflow activity attributes. See: Setting Workflow Activity Attributes for the Credit Card Processes. Required
2 Set workflow timeouts. See: Setting Workflow Timeouts for the Credit Card Processes. Required
3 Set Workflow Attributes. See: Setting Workflow Attributes for the Credit Card Processes. Required
4 Set expense reports performers. See: Setting Expense Report Performers for the Credit Card Processes. Required
5 Defer workflow process at submit time. See: Deferring the Workflow Process for the Credit Card Processes. Optional

Setting Workflow Activity Attributes for the Credit Card Processes

Loop Counter. The Inform Manager of Inactive Employee CC Expenses process has two loop counters associated with the Inform Preparer Inactive Employee notification and the Remind Preparer Inactive Employee Expenses notification. The value that you define for this loop counter limits the number of times the notifications are sent. The default limit is 2.

Activate Assigned Cards. The Process Unassigned Credit Cards process can automatically activate new credit card accounts when Internet Expenses finds a unique employee match for the owner of the card. If you set this option to Yes, the new cards will be automatically activated. The default setting is No.

See: Setting Up Workflow Builder for the Expenses Process for more information.

Setting Workflow Timeouts for the Credit Card Processes

Set the workflow timeouts for the credit card process the same way that you would for the expenses process. See: Setting Up Workflow Builder for the Expenses Process for more information.

Inform Preparer Inactive Employee Expenses. The Inform Preparer Inactive Employee Expenses notification is triggered as part of the Inform Manager of Inactive Employee CC Expenses process. You can set the number of days for this notification. The default number of days is 2.

Inform Sys Admin of Adding Securing Attribute Failure. The Inform Sys Admin of Adding Securing Attribute Failure notification is triggered as part of the Inform Manager of Inactive Employee CC Expenses process. You can set the number of days for this notification. The default number of days is 2.

Wait Activity. The Wait activity is associated with the Inform Manager of Inactive Employee CC Expenses process. The value for this activity determines how long the system will wait before sending the notification. The default value is 2 days.

To modify the wait period:

  1. Click the Node Attribute tab.

  2. Select Relative Time for the Name field.

  3. Remove all other values.

  4. Click the Node tab.

  5. Choose a Timeout period of Relative Time, and specify a number of days, hours, and minutes.

  6. Save your work.

Setting Workflow Attributes for the Credit Card Processes

AP Exception Role Attribute. The Inform Manager of Inactive Employee CC Expenses process uses this attribute to determine who to send the Inform Preparer Inactive Employee Expenses notification to. The Inform Preparer Inactive Employee Expenses notification is sent when Internet Expenses cannot find an active manager for the employee. Perform steps 1-2 in Setting Expense Report Performers for the Expenses Process.

Setting Expense Report Performers for the Credit Card Processes

Set the expense report performers for the credit card process the same way you would for the expenses process. See: Setting Expense Report Performers for the Expenses Process for more information.

Inform Sys Admin of Adding Securing Attribute Failure notification. The Inform Sys Admin of Adding Securing Attribute Failure notification is triggered by the Inform Manager of Inactive Employee CC Expenses process. You can define a performer to receive this notification. It is recommended that you set this performer to the Expense Report Workflow Administrator. If you do not define a performer, the notification goes to the workflow administrator as defined in the System:Error workflow item type.

Deferring the Workflow Process for the Credit Card Processes

Defer the workflow process for the credit card process the same way that you would for the expenses process. See: Deferring the Workflow Process for the Expenses Process for more information.

Credit Cards Workflow Item Type Attributes

This table lists the item type attributes of the Credit Cards workflow. For more information, refer to Credit Cards Process Activities.

Display Name Description Type Length/Format/Lookup Type
Amount The payment (reimbursement) amount. Text 30
Bank Account The name of the bank account to which the employee's reimbursement is sent via direct deposit. Text 80
Bank Name The name of the bank to which the employee's reimbursement is sent via direct deposit. Text 80
Card Program ID The Card Program ID number of the employee's corporate credit card. Number Not applicable
Check Number The number of the check sent to the employee as reimbursement for business expenses. Text 30
Credit Card Company The name of the company issuing the corporate credit card. Text 80
Currency The reimbursement currency. Text 25
Date 1 The beginning date that corporate credit card transactions were incurred. Text 30
Date 2 The ending date that corporate credit card transactions were incurred. Text 30
Date Object 1 From dispute date Date Not applicable
Date Object 2 To dispute date Date Not applicable
Employee Display Name How the employee's name appears in notifications Text 80
Employee ID The employee's unique identification number Number Not applicable
Employee Name The employee's name Text 80
Expense Report Number The expense report for which the employee received reimbursement Text 30
List List of disputed credit card transactions Document Not applicable
Manager Name The manager's name Text 80
Minimum Amount The minimum amount of disputed transactions required to initiate the Notification of Outstanding Disputed Charges process Number Not applicable
Number of Days The number of days that corporate card transactions have been outstanding Number Not applicable
Payment Date The date payment was created for an approved expense report Text 30

Related Topics

Defining Workflow Process Components, Oracle Workflow Developer's Guide

Credit Cards Process Activities

This section provides a description of the activities in each process, listed by the activity's display name.

To avoid duplication, the Start and End activities are described only once in the Standard Function Activities section.

Standard Function Activities

Aging Credit Card Transactions Process

This process is initiated when an Oracle Payables user runs the Credit Card Outstanding Transactions Management (Aging) concurrent program with the Send Notifications parameter set to Yes.

This section provides a description of each activity in the process, listed by the activity's display name.

Unsubmitted Credit Card Transactions Process

This process is initiated when an Oracle Payables user creates the Credit Card Outstanding Transactions Management (Details) report with the Send Notifications parameter set to Yes.

the picture is described in the document text

This section provides a description of each activity in the process, listed by the activity's display name. Each node corresponds to an icon shown in the above illustration.

Unapproved Expense Report Process

This process is initiated when an Oracle Payables user creates the Credit Card Outstanding Transactions Management (Details) report with the Send Notifications parameter set to Yes.

See: Standard Function Activities.

Payment to Card Issuer Process

This process is initiated when payment is created in Oracle Payables for an employee's credit card transactions.

Payment to Employee Process

This process is initiated when payment is created in Oracle Payables for an employee's credit card transactions.

Payment to Employee by Check Process

This process is initiated when payment is created in Oracle Payables for an employee's credit card transactions.

Inform Manager of Inactive Employee CC Expenses Process

This process is initiated when an employee is terminated or on temporary leave and has credit card transactions that were not submitted on expense reports. The inactive employee's securing attribute is automatically assigned to the manager as part of this process.

the picture is described in the document text

the picture is described in the document text

Process Invalid Credit Card Transactions Process

If the system finds invalid transactions during the validation phase of the Upload and Validation program.

the picture is described in the document text

Process Unassigned Credit Cards Process

The Process Unassigned Credit Cards process attempts to match employees with credit card accounts.

the picture is described in the document text

Expense Receipts Workflow

The Expense Receipts workflow manages the tracking of overdue receipts. The workflow has four independent processes that send various notifications to preparers, depending on the status of the receipts for the expense report.

This table describes the processes that make up the Expense Receipts workflow:

Process Purpose Trigger Event Conditions
Receipts Overdue Sends overdue receipts notifications. The notifications allow users to send replies in relation to the status of missing receipts. The replies are Already Sent Receipts, Will Send Receipts, or Receipts Missing. Expenses Overdue Receipts Tracking concurrent program 1) Notification Rule Set is defined and assigned to the operating unit; 2) The "Receipts overdue or missing after expense report submitted" rule is defined for the rule set; 3) Receipts have not been received within the specified time; 4) Receipts Status is Required.
Receipts Missing Sends a notification when all required receipts are missing for an expense report, or when the preparer must submit some form of missing receipts declaration. Expenses Overdue Receipts Tracking concurrent program 1) Notification rule set is defined and assigned to the operating unit; 2) Receipts Status is Missing.
Receipts Received Sends a notification when Payables receives receipts for an expense report. Receipts are received in the Expenses Audit pages. Notification rule set is defined and assigned to the operating unit.
Receipts Aborted Aborts the Receipts Overdue Process and/or the Receipts Missing Process, and purges the tracking of missing receipts. User withdraws an expense report; receipts are received or waived; expense report is rejected by managers or auditors; expense report is returned by the system administration; or when the original expense report receipt status is no longer required, such as after a shortpay. Not applicable

Prerequisite

Before you can run the Expense Receipts workflow and the Expenses Overdue Receipts Tracking concurrent program, you must set up notification rules. See: Managing Receipt Notifications for more information.

Receipts Overdue Process

The Receipts Overdue Process is initiated by the Expenses Overdue Receipts Tracking concurrent program. This program tracks overdue receipts on expense reports. You can run the Expenses Overdue Receipts Tracking concurrent program for the operating unit you choose or all operating units. See: Expenses Overdue Receipts Tracking Program, Oracle Payables User Guide for more information.

The Expenses Overdue Receipts Tracking Program determines if receipts are overdue by comparing the active Notification rule setup to the difference between the expense report submit date and the system date. If receipts are overdue, then the process initiates the sending of notification reminders to the user to send the receipts. The process ends if the receipts are received, waived, or shortpaid. The process also ends if the expense report is withdrawn, rejected, or returned.

the picture is described in the document text

Receipts Missing Process

The Receipts Missing Process sends notification reminders to employees for appropriate documentation to replace missing receipts. The Receipts Missing Process is only initiated when the Notification rule setup requires physical documents in place of missing receipts.

The Receipts Missing Process is called by the Expenses Overdue Receipts Tracking concurrent program, when the program determines that overdue receipts are in a status of "Missing". The "Receipt Missing" status can occur in one of three ways:

the picture is described in the document text

Receipts Received Process

The Receipts Received Process sends notifications to acknowledge receipts received according to the Notification rule setup. This process begins when the auditor indicates that the receipts were received by entering a receipt package received date on the expense report.

the picture is described in the document text

Receipts Aborted Process

The Receipts Aborted Process stops the tracking of overdue or missing receipts for an expense report. This process begins after any of these events:

The Receipts Aborted Process includes these steps:

Expense Holds Workflow

The Expense Holds workflow has two independent processes that send notifications to users when holds are placed and released on expense reports by the Expense Report Export program. The two processes that make up the Expense Holds workflow are:

The Expense Holds workflow sends notifications regarding the placing of a hold on expense reports by the Expense Report Export program under either of these conditions:

Prerequisite

Before you can run the Expense Holds workflow, you must set up hold rules. See: Setting Up Hold Rules for more information.

Expense Payment Held Process

The Expense Payment Held Process manages the sending of notifications regarding the placing of holds on expense reports. This process sends notifications for each aspect of placing expense reports on hold.

the picture is described in the document text

Bothpay Process

If you use the Both Pay scenario, the process sends notifications regarding the placing of holds on expense reports according to the Both Pay option setting in the active Hold rule set. All notifications refer to the entire expense report; notifications are not sent for the credit card provider invoice to be imported into Payables.

Whether or not payment is held on the credit card provider invoice, notifications are sent if the expense report requires receipts and the receipts are overdue. This means, for example, if the Credit Card Payment Holds option is set to "Never hold credit card payment", the expense report is still placed on hold and a notification is sent, even if the expense report only contains credit card expenses.

Expense Payment Hold Released Process

The Expense Payment Hold Released Process manages the sending of notifications regarding the releasing of holds on expense reports. This process is invoked when the Expense Report Export program determines that a receipt has been received or waived. The event that immediately raises the payment hold released event is when a hold is manually released.

This notification is only sent once there are no outstanding hold issues for all related expense reports. For example, if expense report ER3 is on hold because the receipts were not received for expense report ER1, then if the receipts are received for ER1 but ER3 is put back on hold because the receipts have not been received for expense report ER2, the hold release notification is not sent. This is because the hold on ER3, although potentially released because of ER1 still persists because of ER2.

This process sends notifications that are initiated in these ways only when the receipts are received or waived for the expense report that caused the hold:

the picture is described in the document text

Initiating Deferred Workflow Processes

Deferred workflow processes handle notifications and time-consuming tasks that can be automated and placed in the background so that users can continue working in the application without waiting for the requested task to complete. These deferred workflow processes need at least one background engine to monitor background activities in order to ensure consistent processing. Therefore, you must submit a request to enable a concurrent program for workflow background processing.

To submit a request:

  1. Using the Oracle Applications System Administrator responsibility, navigate to the Submit Requests form.

  2. Submit the Workflow Background Process concurrent program as a request.

  3. Schedule the process to repeat itself at appropriate intervals.

Related Topics

Running Reports and Programs, Oracle Applications User's Guide

Overview of Setting Up, Oracle Workflow Administrator's Guide