Understanding Approval Rules

Deny and Undeny Rules

PeopleSoft Expenses uses these rules for deny and undeny functionality:

• When an approver who is authorized to approve all transaction lines in an expense report clicks the Deny button for a transaction, PeopleSoft Expenses sets the transaction status to Denied. The transaction cannot be modified or resubmitted. If multiple approvers exist, PeopleSoft Expenses does not route the transaction to any subsequent approvers.

  For example, MGR1, MGR2, and MGR3 are required to approve expense reports. If MGR1 denies the expense report, PeopleSoft Expenses does not route the report the MGR2 or MGR3.

• When an approver who is authorized to approve some transaction lines clicks the Deny button, PeopleSoft Expenses denies all transaction lines that the approver is authorized to approve. Any subsequent approvers cannot undeny those transaction lines.

  If the approver is responsible for all transaction lines on the report and clicks the Deny button, the report terminates and is removed from any subsequent approvers' queues.

• 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 sets the transaction status to Denied. The system removes the transaction from the approval pool.

• When an approver denies a transaction by deselecting the Approve check box, but approves the overall transaction, the system routes the transaction to any subsequent approvers. The subsequent approvers can undeny the previously denied transaction line only if they have the authority to access the transaction line for approval.

Final Approval Rules

PeopleSoft 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 approve for payment, approve for billing, or both.

• PeopleSoft 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, PeopleSoft Expenses changes the status to Approved for Payment. If no reimbursement is due back to the employee, PeopleSoft Expenses sets the status to Paid.

• If a transaction is in the Staged or Paid status, PeopleSoft Expenses does not enable the Deny or Send Back actions for subsequent approvers and the transaction displays a Pending Billing Approval status. The exception to this rule is that a post payment auditor can deny lines on an expense report or deny the entire transaction.

Privilege Rules

PeopleSoft Expenses uses these rules for privileges:

• If multiple approvers are authorized and one of the approvers adds a new line to an expense transaction, PeopleSoft Expenses records the user ID and date of the line added and routes the transaction to the next approver, if applicable.

• If an approver adds a line or modifies a line to change the value of a routing ChartField in any distribution, PeopleSoft Expenses does not route the transaction back to the beginning of the approval process; only subsequent approvers will see the line.

Adding Transaction Lines During Approval Processing Rules

When approvers add new transaction lines during the approval process, the system routes the new lines to subsequent approvers based on the ChartField values assigned to the new transaction line. Approvers must have the appropriate permissions to be able to add new lines during the approval process.

See Understanding Approval Privilege Templates.

PeopleSoft Expenses uses these rules when adding transaction lines during the approval process:

• When an approver adds an expense transaction line, the approver can modify the newly added line, regardless of his or her approval privileges, until the approver has submitted the transaction by clicking the Approve button.

• If the approver does not have Delete or Full privileges, only the newly added transaction line can be deleted by the approver.

• Any errors that the system identifies when entering a new expense transaction line must first be corrected before any action can be taken on the transaction.

• The system stamps any added expense transaction lines with the approver's operator ID and date on the line detail pages for expense reports and travel authorizations, and on the summary page grids for cash advances and time reports.

• When the approver clicks the Save Changes button, the transaction is validated and saved but no approval-related action is taken.

• When the approver clicks the Approve button, any new transaction lines are added to the transaction when it continues through the approval framework approval process.

• When the approver clicks the Deny button, the new transaction line is set to a status of denied. No additional changes can be made to the new transaction line, and any transaction lines that the approver has the authority to approve are permanently denied.

• When the approver clicks the Send Back button, the transaction is returned to the submitter and includes any transaction lines added by the approver.

• When the approver clicks the Hold button, the system submits the transaction and any added transaction lines to the approval process, but holds the transaction from any further processing.

  For example, MGR1, MGR2, and MGR3 are pooled approvers that are potentially required to approve expense reports. If MGR1 puts the expense report on hold, PeopleSoft Expenses removes the report from MGR2 or MGR3's queue until MGR1 releases the transaction.

• When a designated approver for a transaction adds an expense transaction line, the system considers this action an approval action.

• When an expense transaction line is added by an approver, the system routes the transaction, including the added transaction line, to the next designated approver.

  The added expense transaction lines are routed to subsequent approvers by means of the ChartField configurations entered on the transaction line and the approval framework configurations that are defined for your approvers. Each subsequent approver can take action based on his or her defined approval permissions.

  When no other subsequent approvers exist, the new transaction line is approved when the transaction is approved.

Routing Rules

PeopleSoft Expenses uses these rules for routing:

• This is the general defaulting rule used in rerouting (escalation), delegation, or reassignment functionality:

  • 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 PeopleSoft Expenses Manage Approvals - Transaction Definition (EX_TRANS_DEFN) component.

• 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 the approver but does not enable him or her 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 does not route the transaction to that approver again.

• If supervisor A of an employee submits a report for the employee, the system routs the transaction to the supervisor of supervisor A.

• If a Supplemental Project Approver is defined in an expense workflow but no approvers are defined in the Approver Assignment for the project range, then the workflow skips this approver type all together.

Reassigning Rules

When you use the Define Security - Reassign Work page to reassign work from one approver to another, PeopleSoft Expenses validates user IDs and transactions:

• PeopleSoft 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.

  Example: MGR1 cannot reassign work to MGR1.

• If the originator of an expense transaction is the same as the reassigned approver, PeopleSoft Expenses performs the reassignment, but when the new approver attempts to perform an approval action, that approver receives a message indicating that he or she is not authorized to approve a transaction that he or she submitted.

  Example: MGR1 reassigns the work to MGR2. PeopleSoft Expenses encounters an expense transaction that MGR2 created and submitted to MGR1 for approval.

• If the alternate approver is the same person as the approver whose work is being reassigned, the system reassigns the work in the following way:

  Example: MGR1 assigns the work to MGR2. MGR1 is also the alternate approver for MGR2. The system ignores the delegation and reassigns the work to MGR2.

• 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:

  • MGR1 designates MGR2 as the alternate approver.

  • MGR2 designates MGR3 as the alternate approver.

  • MGR3 designates MGR4 as the alternate approver.

  • MGR4 designates MGR1 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 once in the approval chain of alternates. In the preceding example, the system would route the transaction to MGR4 and stop there because the alternate is an approver who has already been processed in the loop.

Approval Constraints

PeopleSoft 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 whom you defined on the employee profile.

• You cannot route cash advances to project manager or project supplemental approvers.

Final Approval Status Rules

PeopleSoft Expenses uses these rules for final approvals:

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

• For expense reports, PeopleSoft 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 is staged for payment or paid.

• For expense reports, the system sets the billing status to Approved for Billing upon approval by the last active approver type who is authorized to approve for billing. If subsequent approvers are active, the system routes the transaction to them.

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