Approving Invoices

Approval is performed in the Task details window.

GE invoices submitted for approval must be approved before they are imported to Oracle Accounts Payable. The approval process for invoices is adopted from Oracle Purchasing. PROCESSIT finds the approver and applies approval groups as configured in Purchasing.

Invoices are routed to approvers according to the configured forwarding method.

Any user on the system can approve invoices if they have the necessary approval assignments and the document type settings allow it. Users are not segregated into coders and approvers.

Whenever an invoice is submitted PROCESSIT checks to see if the current user has authority to approve the invoice. PROCESSIT checks the document type to decide if coders can approve their own invoices and applies the approval groups assigned to the specific document type and job/position assigned to the employee.

Users can approve invoices within the limit and accounts defined for their users in Oracle E-Business Suite.

User eligible to approve invoices must meet these criteria:

• The user must be active and assigned to an employee.
• The employee’s primary assignment must be assigned to an active job/position.
• The job/position must have active approval assignments for the purchase document type selected for invoice approval in PROCESSIT for the operating unit in which the invoice is entered.

Though best practice, it is not requirement that the position exists in the approval hierarchy (where position approval hierarchies are used) for an employee/user to approve a document. It only means that the document cannot be forwarded automatically if the assigned approval authority is insufficient.

Approval Task Handling

Approving an invoice is done by clicking Submit.

An approval check is performed whenever an invoice is submitted. It checks if configuration parameters and document type settings allow the role (coder/approver) to approve the invoice. It includes an amount check that is applied to all invoice lines where:

• Line type is not tax
• Line is not matched to a purchase order
• The Split to field for splitting invoices is empty.

The approval check is performed on the line amounts and the total line amount sum.

If the approving user does not have sufficient authority to approve the entire set of invoice lines, the invoice is routed to the next approver found in positions hierarchy according to forward method.

Remember you can add comments to all documents if necessary.

When an invoice has been approved, it is imported to Accounts Payable.

Save accounting

Supplied information can be saved at all times by clicking Task details window main header.

Reject invoice

Click Reject to reject the invoice. The invoice is sent for error handling to be handled by a workflow administrator.

To reject an invoice, comments must be applied.

Determine if coders can approve invoices

Coder is defined as the last person who changed GL coding and submitted it.

To determine if coders are allowed to approve invoices, use the configuration parameter Coder Can Approve. If set to Yes, the last coder for an invoice is allowed to approve that invoice. If set to No, the coder is not allowed to approve the invoice.

Previous to PROCESSIT version 7.2 R4, submitted invoices were checked with the Owner Can Approve field in Oracle E-Business Suite to determine if an account coder could approve an invoice. From PROCESSIT 7.2 R4 and forward, this has been changed to the behavior described above.

Position flexfield segment approval check

You can setup configuration to perform an additional approval check for invoices based on a flexfield segment value. The defined flexfield value is checked along with the document total. A user must have sufficient approval authority for both checks to approve the invoice. If a user does not have ordinary approval assignments in the operating unit, the approval check fails regardless if the user has sufficient authority according to the flexfield segment approval check.

Use these configuration parameters to define the setup for the position flexfield segment approval check:

• Enable Position Flexfield Segment Approval Check
• Position Flexfield Segment Used For Approval Check
• Position Flexfield Segment Value Set Dff Attribute Used For Approval Check

The Position flexfield segment approval check is a supplement the ordinary approval assignments. If one of the parameters used to define the check is empty, does not exist or is misconfigured, then the check is skipped.

This check only takes affect if position hierarchy is used.

Using the Send To field

During both accounting and approval, you can use the Send To field in Task Details invoice Header to determine the next invoice approver, if the field is enabled via configuration.

For initial dispatching accounting tasks, the Send To field operates as a header level field to populate the line splitting fields. Any empty Split To field is populated with the user value entered. If no line accounting is performed prior to submit, then the send to user (and optional split to users) receives Account Task notification for the invoice.

If the invoice is accounted, and the Send To field is populated, the send to user receives an approval task notification for the invoice. The send to user receives the approval task whether or not the user performing the sent to has sufficient approval authority to approve the invoice.

If a value is supplied in the Send To field during an approval task, the invoice is routed to that user for further approval, whether the current user has approval rights or not. The user receving the approval task must approve the invoice before it is imported.

If a Send To field value is not supplied, the invoice is routed according to standard business procedures.

You can configure the Send to and splitting fields to exclude superusers, so they can not be selected.

Return to Coder

You can click Return to Coder to change the notification type to Account invoice, and route it back to the Coder. The Coder of the invoice is always the last user to have entered or updated and submitted one or more line accounts. This is not necessarily the same user as the dispatcher.