Understanding Approvals Concept Understanding Approvals Understanding Approvals Step

Understanding Approvals Concept

Understanding Approvals

Understanding Approvals Step 1 The Expenses approval functionality enables reviewers, approvers, and auditors to review and approve multiple expense transactions with one approval action. You control the approver actions that can be used on the Summary Approval Options page. Using this page, you can disable summary approvals if it violates company policy for expense approvals and disable transactions for approval if they have exceptions. You can also configure approvals so that an approver with multiple roles can see the same transaction only once.

Understanding Approvals Step 2 Depending on how you set up Expenses, reviewers, approvers, and auditors can approve some or all expense transactions in their queue with one action.

Understanding Approvals Step 3 You can also approve all expense transaction types on one page or approve by transaction type using the tabs at the top of this page.

Understanding Approvals Step 4 You can drill down to view additional information and take action on transactions at the detail level.

Understanding Approvals Step 5 You can change the sort order of transactions and view them sequentially in the new order.

Understanding Approvals Step 6 You can search for transactions in a pending approval status.

Understanding Approvals Step 7 You can view expense history for one or more employees prior to approval.

Understanding Approvals Step 8 You establish pooled approvers by assigning multiple approvers to the same routing range of Chart. Fields or by adding multiple profiles to the approver list. In both cases, you must select the Notify All Approvers option in the Submission Notifications group box on the Approver Routing List page. The system defaults to require only one approver out of the pool to approve a transaction.

Understanding Approvals Step 9 You can modify the number of approvers that are needed to reflect the number of approvers your organization requires by changing the Number of Approvers Needed value on the Approval Step Definition page.

Understanding Approvals Step 10 These rules apply to pooled approver functionality: • If you configure the system to require only one approver from a pool of approvers, and one of the approvers performs an approval action, the system withdraws the transaction from the queue of the other approvers. • If you establish multiple profiles on the approver list with multiple approvers assigned to each profile, the system only requires one approval from the pool if you set the Number of Approvers Needed field to 1.

Understanding Approvals Step 11 If you define a profile on an approver list that is associated with a refinement or filter that excludes a transaction, the system excludes the approvers that are assigned to that profile from the pool. For example, Auditor 1, Auditor 2, and Auditor 3 profiles are on the prepayment auditor approver list. Auditor 2 uses a refinement that selects only expense reports that contain project-related expenses. When an employee submits an expense report that does not contain project-related expenses, the approver pool consists of approvers assigned to the Auditor 1 and Auditor 3 profiles.

Understanding Approvals Step 12 If the system excludes all approvers in a pool because of refinements associated with their profiles, the system automatically approves the transaction for that role.

Understanding Approvals Step 13 Approval Privilege Templates consist of a collection of attribute privileges that define the type of access to fields and records that approvers can access in their approval queue. The approval privileges range from viewing accounting dates to adding expense lines.

Understanding Approvals Step 14 Privilege Templates enable approvers to view and modify areas of a transaction and, in some cases, to add or delete other areas of a transaction. Some privileges may supersede others. For example, if an approver has the authority to add or delete an expense line, then they automatically have the authority to add or delete distributions, change amounts, and change Chart. Fields.

Understanding Approvals Step 15 Risk Templates are used to control spending and enforce corporate policy for expenditures. Risk Templates define risk levels that are associated with an expense transaction. This provides approvers the information they need to make an informed decision during the approval process. If the system determines that a transaction has risk, a Risk icon is displayed on approval pages to notify the approver.

Understanding Approvals Step 16 Risk Templates determine how an expense transaction that has risk, is routed to an approver, such as by email or email notification.

Understanding Approvals Step 17 If a Risk Template is not selected, the system uses the Enable Email Approvals option to determine if an approver can approve transactions using email.

Understanding Approvals Step 18 If all approvers on an approver list are defined with amount-based rules that exclude a submitted transaction, then the system routes the transaction to the employee's supervisor. If the supervisor has already approved the transaction, then the system routes the transaction to the next approval stage. If it is the last stage for approving an expense report or cash advance for payment, then the system sets the status to Approved for Payment.

Understanding Approvals Step 19 An Approver Type is a role, and Expenses delivers these approver types.

Understanding Approvals Step 20 In this example, an approver type of Reviewer has been defined.

Understanding Approvals Step 21 In this example, an approver type of Department Manager has been defined. All managers assigned to this role are authorized to approve some or all expense transactions. You can use the Department Manager role instead of using a HR Supervisor role. Or, you can use the role in conjunction with the HR Supervisor for approvals of transactions meeting defined conditions, such as report total amount. You define these approvers through an approver list.

Understanding Approvals Step 22 In this example, an HR Supervisor approver type has been defined.

Understanding Approvals Step 23 In this example, a Project Supplemental Approver has been defined. Use this approver type instead of project manager approvals, or in conjunction with project manager approvals for project-related transactions that meet defined conditions, such as report total amount or reports with billable project hours. You define these approvers through an approver list.

Understanding Approvals Step 24 In this example, a Pre Payment Auditor approver type has been defined.

Understanding Approvals Step 25 In general, employees cannot approve or audit their own expense transactions. Expenses compares the employee ID on the transaction with the employee ID that is associated with the user ID of the approver or auditor.

Understanding Approvals Step 26 Expenses uses these rules for deny functionality or to reverse a denied expense report: • When an approver who is authorized to approve all transaction lines in an expense report clicks the Deny button for a transaction, Expenses sets the transaction status to Denied. The transaction cannot be modified or resubmitted. If there are multiple approvers, Expenses does not route the transaction to any subsequent approvers. • When an approver, who is authorized to approve some transaction lines, clicks the Deny button, Expenses denies at the line level. The transaction is eligible for routing to subsequent approvers, if applicable. • When approvals are performed by a pool of approvers, the first approver who denies the transaction and is authorized to approve all of the transaction lines will set the transaction status to Denied.

Understanding Approvals Step 27 Expenses uses these rules for final approvals: • You must authorize at least one active approver type to approve expense report transactions for payment. • You must authorize active approver types for expense report transactions to either approve for payment, approve for billing, or both. • Expenses sets the status for travel authorizations, cash advances, time reports, and time adjustments to Approvals In Process until the final approver approves the transaction. • Expense reports display a status of Approvals In Process until the final approver who is authorized to approve for payment has approved the transaction. Upon final approval, Expenses changes the status to Approved for Payment. If no reimbursement is due back to the employee, Expenses sets the status to

Understanding Approvals Step 28 Expenses uses these rules for privileges: • If there are multiple approvers and one of the approvers adds a new line to an expense transaction, Expenses automatically sets the line to Approved for Payment. Subsequent approvers cannot deny the line. However, they can use the Modify Approved Transactions page to modify or remove the line. • If an approver adds a line or modifies a line to change the value of a routing Chart. Field in any distribution, Expenses does not route the transaction back to the beginning of the approval process; only subsequent approvers see the new or changed line.

Understanding Approvals Step 29 Expenses uses these rules for routing. The general defaulting rule used in rerouting (escalation), delegation, or reassignment functionality is: • If the system cannot determine the appropriate approver based on the configuration, the system routes the transaction to the HR supervisor or designated approver in the employee's profile. • If the system cannot determine an HR supervisor or designated approver through the employee's profile, the system routes the transaction to the Expense System Administrator that you define in the transaction definition.

Understanding Approvals Step 30 Expenses uses these rules for routing: • If the escalation process picks up a transaction for rerouting, and the approver who is designated as the target for rerouting is the same person as the employee or submitter, the system routes the transaction to the approver's supervisor. • If the rerouting process picks up a transaction for rerouting, and the approver who is designated as the target for rerouting is the same person as the employee or submitter, the system routes the transaction to them but does not enable them to take any transaction approval action on the approval pages. • If you reassign a transaction to an approver who has already approved the transaction, the system will not route the transaction to that approver again.

Understanding Approvals Step 31 When you use the Define Security Reassign Work page to reassign work from one approver to another, Expenses validates user IDs and transactions: • Expenses generates an error and terminates the reassign operation if you enter the same approver in the Reassign Work To field on the Define Security - Reassign Work page. For example, MGR 1 cannot reassign work to MGR 1. • If the originator of an expense transaction is the same as the reassigned approver, Expenses performs the reassignment but when the new approver attempts to perform an approval action, they receive a message indicating that they are not authorized to approve a transaction that they submitted. For example, MGR 1 reassigns the work to MGR 2. Expenses encounters an expense transaction that MGR 2 created

Understanding Approvals Step 32 If the alternate approver is the same person as the approver whose work is being reassigned, the system reassigns the work as follows: MGR 1 assigns the work to MGR 2. MGR 1 is the alternate approver for MGR 2. The system ignores the delegation and reassigns the work to MGR 2.

Understanding Approvals Step 33 If an approver reassigns work to another approver who has designated an alternate approver, who in turn has designated an alternate approver who is the original approver, it is considered a circular reference and the reassignment stops at the first approver it encounters who is not the originator. Example: • MGR 1 designates MGR 2 as the alternate approver. • MGR 2 designates MGR 3 as the alternate approver. • MGR 3 designates MGR 4 as the alternate approver. • MGR 4 designates MGR 1 as the alternate approver. The approval engine loops through the delegated approvers until it can find no more alternates, or until an alternate appears who has already appeared

Understanding Approvals Step 34 Expenses has some approval constraints. The system routes time reports and time report adjustments containing only non-project hours to the HR supervisor or designated approver that you defined on the employee profile.

Understanding Approvals Step 35 You cannot route cash advances to project managers or project supplemental approvers.

Understanding Approvals Step 36 For travel authorizations, cash advances, time reports, and time adjustments, all active approvers must approve the transactions before the system marks the transaction header with a final approval status. Final approval status is Approved for these transactions.

Understanding Approvals Step 37 For expense reports, Expenses sets the transaction header status to Approved for Payment upon approval by the last active approver type who is authorized to approve for payment. If subsequent approvers are active, the system routes the transaction to them; however, the expense report is eligible for payment processing, regardless of any subsequent approver actions. If the expense report is in Approved for Payment status, subsequent approvers can deny it or send it back for revision during the prepayment approval process. However, subsequent approvers cannot deny or send back for revision if the expense report has been staged for payment or paid.

Understanding Approvals Step 38 For expense reports, a transaction status of Approved for Payment and a project manager flag value of N sets the expense report to be eligible for staging to Project Costing.

Understanding Approvals Step 39 This concludes the "Understanding Approvals" topic. End of Procedure.