Hold Handling

Hold Notifications Configuration

Holds Setup

Hold Setup determines the handling of invoice hold workflows and defines recipients of hold notification(s). You also control available options when handling Hold tasks. Hold Setup is configured in the Configuration Manager in the Hold Setup area.

Remember to select the particular organization that you wish to configure prior to navigating .

Adding and managing hold reasons

In Hold Setup you must configure Hold Reasons for Hold Names corresponding to the holds defined in the ERP system. Hold Reasons are used to determine how holds are handled by the PROCESSIT workflow. To configure a new hold reason: Click Add, select a Hold Name from the drop down list, and set the details for the hold reason according to the desired specifications.

The Options for each hold reason are described in the following segments.

Excluded

You can specify holds that are excluded from PROCESSIT handling. Any hold and any number of holds can be excluded.

Each hold that is not specifically set to be excluded is considered included.

Yes: This setting excludes the hold from being processed in PROCESSIT. The hold is ignored by PROCESSIT and the workflow can complete with this hold on the invoice.

No: The hold is included and is handled in PROCESSIT. Notifications are issued including this hold. Invoice workflows do not complete as longs as this hold is applied to the invoice. The hold description is displayed in all hold notifications, if the hold is applied.

Visible

This option can be specified for excluded holds only.

Yes: While the hold is not being handled in PROCESSIT, it is visible as information only in notifications for other holds applied to the invoice.

No: The hold it completely ignored by PROCESSIT, and is not visible as information in any notifications.

Preprocess

There are two hold process cycles: preprocess and postprocess. Preprocess runs first and they cannot run simultaneously.

Yes: The hold is handled in the hold preprocess cycle, before postprocess holds. Typically for example Distribution Variance hold, which you want to resolve before dealing with matching holds.

No: The hold is handled when there are no active preprocess holds on the invoice.

Hold Recipient(s) Setup

For each hold name, you can define recipients ordered by rank. The Hold Recipient setup determines the user who receives a particular invoice hold task notification. This is done by selecting a hold name row and defining recipients in the lower panel. You can set any number of defined hold recipient ranks for each hold name.

Rank 1 is highest rank. If a rank is not a valid recipient when the recipient for an invoice hold notification is determined, the next rank is selected.

The rank specific settings for Validate recipient and Release holds from the highest configured rank is applied for the hold.

PROCESSIT selects the notification recipient as the highest ranked valid recipient.

If no valid recipient can be determined from any rank, the organization superuser receives the hold task notification. The hold workflow runs as standard validation and is not releasable.

Specify Hold Recipient Rank

To configure a hold recipient rank for a hold reason:

1. Select the hold reason from the hold reason table list.
2. Click Add.
3. Specify the settings for the rank in the new table row.
4. Click Save.

You can always edit existing rank settings. Edit the appropriate row and click Save.

Delete a Hold Recipient record

If you wish to delete a recipient rank setup, select the appropriate row and click Delete. Note that deleting a match hold receiver setup cannot be undone. You will have to recreate the setup.

PO roles and Requisition roles

When matching to a purchase order, the match criteria are maintained at PO shipment level. Matching holds applied to the invoice are tied to the shipment and not directly tied to the PO distributions. Since requisitions create PO distributions you can have situations where a matching hold relates to multiple requisitions and thus multiple recipients.

In order to find a recipient determined by a requisition role, PROCESSIT locates the recipient for each PO distribution under the shipment specific to the hold, and where the PO distribution is being matched on the invoice. If none or multiple recipients are returned, the result is not used and the loop continues to next rank.

During an invoice hold process workflow, the following process is performed for each included hold:

1. Find the setting to apply for the hold.
2. Loop through the ranks until a rank returns exactly one single valid recipient.
3. If no rank returns a valid recipient, the organization superuser receives the invoice hold task notification.

Ranks

Used to determine the initial recipient of the hold notification. It will try Rank 1 first and if this does not result in a valid user it will try Rank 2 and so on. At the end it will notify the superuser.

Role/Person

Specifies the initial recipient (for the Rank). Can be entered as

• Role
• Specific User
• SQL

SQL Statements to determine recipient

By using SQL Statements to define the recipient user, you can configure recipients of which multiple recipients may be found for a hold. It is your responsibility to maintain SQL statements if they are used.

Release Holds

All holds can be configured as Releasable or Not Releasable for each defined recipient rank. By default, all holds are not releaseable if no recipient ranks are defined.

Regardless of PROCESSIT setup, holds can only be released if the hold is defined as manual releasable in Oracle.

To be in control of the rank specific settings, you can set the superuser as the lowest rank recipient for all holds.

Yes: User will have the option to release hold from notification. The notification will remain active and visible in the users worklist until he releases the hold or a timeout causes the workflow to close the notification and proceed.

No: User cannot release from notification but he can close (Continue) the notification which will remove it from the worklist (this is typically 3way match holds where the appropriate action is to receive the goods). Notification will be reissued if hold persist following next invoice validation (run by PROCESSIT).

Validate Recipient

Position Validation

This is used to validate that the recipient holds a valid position within the default approval hierarchy associated with the document type (configured for invoice approval in PROCESSIT) in the operating unit.

This is typically to catch situations where the initial recipient has moved on. For example if the requester no longer holds the position he did when the requisition was submitted. He is still the requester on the original requisition but may but no longer works in the department and has no interest in the invoice. In such a case, the hold workflow sends the notification to next rank.

Timeout Option

PROCESSIT is not notified when the invoice status in Oracle changes and releasing the hold in Oracle will not trigger PROCESSIT to continue.

PROCESSIT checks invoice status in Oracle and lets you configure the frequency with which this takes place and how it proceeds. This is done by configuring the Timeout Option per hold per operating unit.

If nothing has been configured PROCESSIT will timeout and revalidate the invoice after 30 days.

Reminder (E)

Workflow will timeout as specified in table D4_REMINDER_LEVELS. At timeout the notification will be closed if all included holds have been released, or reissued as reminder or escalation as configured. This option is typically used with releasable holds.

Revalidate (T)

Workflow will timeout as specified by configuration parameters. The option is typically used with nonreleasable holds.

The controlling configuration parameters are:

D4_TIME_TO_WAIT - Hold Schedule - Time To Wait In Days defines the frequency in days with which PROCESSIT checks Oracle to see if the hold is released. If all holds included in the notification are released the notification closes and the subflow proceeds.

D4_MAX_TIME_TO_WAIT - Hold Schedule - Max Time To Wait In Days defines the maximum time the workflow in days that the workflow waits to check the hold status before it closes the subflow and revalidates the invoice (and issue new notifications for persisting holds). This value should be higher than the value specified by D4_TIME_TO_WAIT. holds.

You must specify both parameters before the system signals the revalidation that triggers another hold notification process.

Reminders are still executed according to the specified settings, but when the max time to wait is reached, the process is restarted.

Reminder or Revalidate (B)

Using this options means the workflow applies whichever occurs first. This option is typically used with releasable holds.

Copy Setup

To copy a setup for a particular hold reason to another organization:

1. Select an Organization in Copy Setup to organization.
2. Click Copy.

Copying setup overwrites the existing setup for the organization you are copying to.

Workflow for Invoice Holds

Hold Details Window

All invoice hold task notifications are handled in the Hold Details window.

Hold Task Notifications

The AP invoice hold status is checked subsequent to each completed invoice validation request performed by PROCESSIT workflows. The status is checked by the parent handle holds process. If holds are applied, a hold task notification sub-processes is started.

An invoice is validated by the workflow whenever the handle holds process completes, if the handle holds process has notification sub-processes, and task notifications have been issued.

Invoice holds status

For each hold on an invoice, PROCESSIT tracks the following:

• Invoice Id and Hold_id.
• User releasable flag as of ap_hold_codes.
• Whether the hold is configured to be an Excluded hold
• Released by as of ap_holds table. Updated with every status check.
• Current notification process id. This indicates that the hold is contained in an active notification process. If an active hold is not contained in an active notification process the hold is considered un-notified.
• Releasable or non-releasable. This is determined when the notification is created, based on the rank setting for the recipient. Impacts the available actions and reminder schedule. For non-releasable notifications, closing the notification does not close the notification process. The process remains active and the status remains notified until the entire notification process is closed.
• Notification status, used to track if the notification is rejected.
• Initial recipient, recipient determined by the hold recipient setup.
• Recipient rank for the initial recipient.
• Recipient role associated with the rank at the time when the initial recipient was set.
• Current notification owner.

Issue notifications

The parent handle holds process checks the invoice holds status and issues task notifications if holds are applied. If there are active included holds on the invoice in Accounts Payable, the hold workflow is started. If there are no holds, the status check is complete.

1. Set hold release check frequency for the parent handle holds process corresponding to the Time to wait in days parameter.
2. Loop through all the active non-excluded holds in the current category context and set the initial recipient for each hold. For each hold, these fields are checked:
   • Recipient rank
   • Recipient role
   • Releasable/non-releasable
3. Start one process for each recipient of active holds in the current category context
   1. Select all active holds in the current category context for the recipient.
      • Hold task is Releasable if at least one included hold is releasable.
      • Hold task is Non-releasable if none of the included holds are releasable.
   2. Set or update the current notification process id and notification type statuses on all included holds.
4. Set timeouts for each notification process according to the hold configuration
   • Releasable and in the Match holds category apply setting from Reminder Group as defined in D4_REMINDER_LEVELS
   • Releasable and in the Other holds category have no timeout settings.
   • Non-releasable hold notification have settings applied from the Max time to wait in days parameter
5. Status check is complete. Notification sub-processes started.

Notification and workflow continuation

Parent process

The parent handle holds process controls all notification sub-processes. It waits for all its notification sub-processes to complete before it is complete. The parent process is started subsequent to every completed AP invoice validation process in the workflow.

The parent handle holds process completes when the holds status check completed with no holds applied and no notification are sub-processes started, and all started notification sub-processes are complete.

Notification sub-processes

Hold task notifications belong to notification processes. Closing a notification does not necessarily close the notification process. A notification processes can be completed in the following ways:

• All holds included in the notification have been released. This can be as result of user releasing all holds from a notification or result of the hold released check controlled by the Time to wait in days parameter
• Process is closed because Max time to wait in days limit has been reached
• Process is closed by a user requesting Revalidation

Workflow continuation

When the handle holds process completes the workflow continues. The way it continues depends on how the handle holds process completed.

• Holds status check completed with no active holds applied and no notification sub-processes started
  1. Block posting hold is released if applied.
  2. Complete invoice workflow
• All notification sub-processes are complete
  1. The AP invoice validation process runs.
  2. A new handle holds process starts when validation process is done.

Activity history

The activity history available to users in the worklist includes action history for:

• Holds released for invoice number.
• Additional holds release approval required and a notification for the invoice is sent for approval from [user] to [recipient]
• When a hold is rejected and a notification is reassigned to a super user.
• When a non-releasable holds notification is closed by [user].
• When a Holds notification for an invoice is closed by workflow due to a time-out or through the hold status check
• Holds notification reassigned: Holds notification for invoice # was reassigned from [user] to [recipient] by [user]
• Holds notification escalated: Holds notification for invoice # was escalated from [user] to [recipient]
• Rejected holds notification resubmitted: Rejected holds notification for invoice # was resubmitted from [user] to [recipient]

Audit trail

As with all activities in the invoice life cycle, the hold actions are covered by the invoice Audit trail which can be viewed in the Auditor. All actions covered in the activity history can be viewed here, as well as the rank and the role by which the initial recipient was determined for each hold.

Released by user

If the PROCESSIT user base is configured as FND user joined with employee, the user who releases the hold in PROCESSIT is also the user who released the hold in Oracle.

Notification Content

Invoice holds are handled in the Hold Details screen.

Contained holds

The notification contains a block displaying:

• All excluded holds, which displays the hold description for every hold on the invoice configured as excluded and displayed.
• All included holds contained in the notification process, both released and non-released.

For each contained hold, the following is displayed:

• Hold description
• Status
• Whether the hold is user releasable or not.
  • Releasable if: Hold is active and User releasable flag and Releasable hold are both Yes on the holds status.
  • Not releasable if: Hold is active and either User releasable flag or Releasable hold is No on the holds status.
• Hold was released [Release date] if the hold is already released.
• Initial recipient username and initial role.

Line information

Line information for all the active holds is included in the notification.

The hold line information column titles reflect the wording used in Oracle core PO and AP forms.

No line information is shown for holds which are not applied to a shipment.

Invoice Information

For each hold, information from invoice lines which are matched to the same shipment (line_location_id) as that of the hold is displayed.

• Hold Name: hold meaning
• Line: line number
• Description: line description
• Qty: quantity invoiced
• Price: unit price invoiced
• Amount: line amount

PO Information

For each shipment on hold these fields are displayed:

• PO: PO number
• PO Line: PO line number
• Description: PO line description
• PO UOM: PO line uom
• PO Price: PO line price
• PO Ship: PO shipment line number
• Ship to: PO shipment line ship to location
• Ordered: qty ordered on shipment line
• Received: qty received on shipment line
• Cancelled: qty cancelled on shipment line
• Billed: qty billed on shipment line
• Amount Billed: amount billed on shipment line

PO distribution info

For each shipment on hold, these fields are displayed for all po distribution lines which are matched on the invoice:

• PO: PO number
• PO Line: PO line number
• PO Ship: PO shipment line number
• PO Dist: PO distribution line number
• Ordered: qty ordered on PO distribution line
• Delivered: qty delivered on PO distribution line
• Cancelled: qty cancelled on PO distribution line
• Billed: qty billed on PO distribution line
• Amount Billed: amount billed on PO distribution line
• Requisition: requisition number from distribution line
• Requester: deliver_to_person_id from po distribution line, fnd_user.description or per_all_people_f.full_name
• Preparer: preparer of requisition, fnd_user.description or per_all_people_f.full_name

Invoice Hold Actions

Available user actions are controlled by hold reason setup.

Release holds

Available in releasable hold notification only

• For match holds notifications: Apply Holds release approval check
• If user can release all releasable holds: release all the active releasable holds contained in the notification, close the notification and the process
• If user cannot release all releasable holds: release the active releasable holds contained in the notification which passed the approval check, keep notification process active and reassign notification. .
• For other holds notifications: release all the active releasable holds contained in the notification, close the notification and the process

Close notification: Available in non-releasable hold notification only.

• Close the notification.
• keep the notification process active.

Keep Holds

For non-releasable holds: Validate - Keep the holds, the invoice workflow is completed, leaving the invoice in Payables with the holds still applied. Any further invoice handling should be performed in Accounts Payable.

Continue

For non-releasable holds: Revalidates the hold - still in hold in oracle, has the issue been resolved?

Reassign

You can reassign the invoice hold task notification to another user by selecting a user in the Reassign field and clicking Reassign.

Reject

Available within all invoice hold task notifications not previously rejected.

When you click Reject you must supply a Reject reason in the reject pop-up before the reject workflow proceeds. The reject reason is viewable in search and as a comment to the invoice.

When an invoice hold notification is rejected, all timeouts for the notification are cleared. Rejected hold notifications can not timeout or escalate.

The rejected invoice hold notification status is updated to rejected and is kept active. A rejected hold notification is sent to a workflow administrator/super user, who can correct and resubmit the invoice. The super user has two options:

• Resubmit the invoice back to the workflow, reinstating the notification in original form. The notification status is no longer rejected. Timeout settings are reset. The superuser can optionally select a user, that should receive the hold task notification.
• Revalidate to request invoice revalidation. This closes all notification hold sub-processes and the parent process immediately, and triggers the main workflow to continue. The main workflow validates the invoice and issues new notifications for active holds after the validation.

Hold Escalations and timeouts

Hold Escalations

Escalation of hold task notifications are carried out in accordance with the Reminder setup and the time to wait parameter.

Releasable hold notifications escalate,non-releasable hold notifications do not escalate. Instead, they follow the timeout options setting defined for the current recipient.

Rejected holds do not timeout or escalate.

Other holds and Rejected holds notifications

Non-releasable holds in the Other holds category are also affected by the Max time to wait in days.

Automatic release of PROCESSIT hold

If PROCESSIT hold is enabled, it is released automatically when all other holds are resolved.

Other Hold Configuration

Hold release approval check

You can configure the system to perform some approval checks when a user attempts to release a hold within PROCESSIT, in order to allow or disallow the hold release.

If the configuration parameter Enable/Disable hold release approval check is enabled, only users matching these criteria are allowed to release a hold:

• Active assignment
• Within active approval hierarchy attached to document type PURCHASE REQUISITION.

User assignment must have approval groups and approval assignments setup, depending on if position hierarchy is used or not.

If the configuration parameter Enable hold release requisition approval check is enabled, a hold notification receiver user must have approval rights to approve "fake requisition" (if exists) related to a hold. Fake requisition is build runtime following to the specification written in TRP07.

This approval check is performed for each hold separately one by one. If a user is authorized to release a hold, the hold is released. If user does not have authority to release a hold, the process continues to the next applied hold. Following this proceudre, if there are still holds applied, the invoice notification is routed to the next person in the approval hierarchy. The approval hierarchy is based on PURCHASE REQUISITION document type configuration in Oracle E-Business Suite.

Check holds

You can configure Check Hold parameters to check if an invoice will go to a hold process before it is submitted. Both the manual and automatic matching processes consider the difference between price and quantity ordered versus acceptable tolerances. If an automatic match would result in a hold, the invoice is now sent for manual match. Conversely, if a manual match task would result in a hold; the user is required to have Check Holds disabled to submit the invoice. Otherwise, the data causing the hold must be handled in the ERP system before proceeding with the invoice workflow.

If the check hold catches an invoice, the mating procedures are still carried out in accordance with standard workflow settings.

Note that check holds must be enabled for the PO_MATCH_USER for the automatic part of the check holds procedure to work.

• Enable price/quantity hold check after matching: Enable price/quantity hold check after matching.
• Enable/Disable hold release approval check: Enables hold release approval check when user trying to release hold from PROCESSIT.
• Enable hold release requisition approval check: If release approval check is enabled and this parameter is enabled then to release a hold user must have approval rights to approve requisition (if exists) related to hold.