Search Results okc_wf_chk_approve




Overview
Explore in AI Chat

Overview

OKC_WF_CHK_APPROVE is an Oracle E-Business Suite PL/SQL package body owned by the APPS schema, classified under the ETRM documentation as an "OTHER" API. It belongs to the Oracle Contracts (OKC) product family and serves as the workflow callback and approval-checking engine for contract approval cycles. Its primary business function is to determine, at runtime within an Oracle Workflow process, which approvers and informed parties apply to a given contract approval task, to record the outcome of that task once the approver responds, and to support the notification layer that presents the approval request to the end user. The package is explicitly a helper to the contract approval workflow rather than a general-purpose contract API; the ETRM metadata records no database objects that reference it, confirming that it is invoked dynamically by the workflow engine through standard item-type and activity attribute definitions rather than by static PL/SQL callers.

Key Procedures and Functions

The documented package exposes seven procedures or functions, each corresponding to a standard Oracle Workflow callback point:

  • SELECTOR — The master workflow selector activity. It dispatches control to the appropriate sub-selector so that the correct approver or informed list is resolved for the current approval task.
  • INITIALIZE — Performs setup work at the start of the approval activity, establishing the working context (contract identifier, task, and related state) before any selection logic executes.
  • SELECT_APPROVER — Resolves the list of users or roles who must act on the approval task. This is the core determination of the approval routing.
  • SELECT_INFORMED — Resolves the list of users or roles who are notified of the approval action for information only, without an approval obligation.
  • RECORD_APPROVED — Persists the result of an approval action, recording that the task was approved and advancing the contract's approval state accordingly.
  • RECORD_REJECTED — Persists the result of a rejection action, recording that the task was rejected so that the workflow can route the contract back for correction or termination.
  • NOTE_FILLED — Handles the response attribute for approver-entered comment text, ensuring that free-form notes attached to an approval response are captured and made available to the workflow.

Parameter lists are not documented in the ETRM metadata and are intentionally not reproduced here.

Tables Accessed

The ETRM documentation records a single table referenced through an APPS synonym: FND_USER. The package reads FND_USER to translate approver and informed-party selections into valid application users—resolving user names, active status, and the identities required by the Workflow notification engine. In addition to this directly documented table, the package's listed dependencies on OKC_API, OKC_CHANGE_CONTRACT_PUB, WF_CORE, WF_ENGINE, WF_ROLES, FND_API, FND_MSG_PUB, FND_PROFILE, and PER_PEOPLE_F indicate that contract header and approval-cycle data, workflow role membership, human-resources person records, profile option values, and FND message-stack handling are all reached indirectly through those APIs rather than through direct SQL against base tables.

Usage Notes

OKC_WF_CHK_APPROVE is not intended for direct invocation from forms, concurrent programs, or custom PL/SQL. It is registered against Oracle Workflow activities in the contract approval item type, and Oracle Workflow invokes its procedures as callback functions at the selector, initialize, approver-selection, informed-selection, approve, reject, and note-fill points of the approval process flow. Because it depends on FND_PROFILE and FND_API, correct behavior requires that the standard EBS session context (responsibility, user, org, and MO operating unit) be initialized before the workflow engine fires these callbacks. The presence of FND_MSG_PUB in the dependency list indicates that error and validation messages are surfaced through the standard FND message stack, so callers should not expect the package to raise raw Oracle errors. Version differences between 12.1.1 and 12.2.2 are limited to the standard EBS patching lineage; the documented interface and dependency set are consistent across both releases, with the package remaining VALID in the APPS schema.