Search Results oke_chg_logs_s
Overview
The APPS.OKE_CHG_REQ_UTILS package body is a utility layer within the Oracle E-Business Suite Oracle Knowledge Management (OKE) module, specifically supporting the Contract Change Request feature. Change requests in OKE allow authorized users to propose modifications to an existing contract (for example, term changes, line alterations, or price adjustments) and route those proposals through an approval and processing lifecycle before the underlying contract version is actually modified. The OKE_CHG_REQ_UTILS package provides the shared PL/SQL logic that drives this lifecycle: it evaluates the current state of a change request, determines whether a request is eligible to be applied to (or removed from) the contract, records processing outcomes, and writes diagnostic information to the change-request log tables.
The package is documented as VALID and classified as an OTHER API, meaning it is an internal support package rather than a formally published public API. Nevertheless it depends on and is referenced by other objects in the OKE change-request processing chain, so it plays a central role in coordinating change request status transitions.
Key Procedures and Functions
The ETRM metadata documents six procedures/functions in this package body:
- STATUS_CHANGE — Transitions a change request from one status to another, applying the business rules that govern valid status progression and updating the associated status records.
- GET_PROCESS_STATUS — Returns the current processing status of a change request, allowing callers to branch logic based on whether the request is pending, in process, completed, or in error.
- UPDATE_PROCESS — Persists the outcome of processing activity against a change request, updating the change request record and writing entries to the change-request log tables.
- OK_TO_IMPLEMENT — Validates whether a change request is eligible to be implemented (applied to the contract), returning the appropriate indication to the calling program.
- OK_TO_UNDO — Validates whether a previously implemented change request may be reversed or undone, reflecting the conditions under which an implementation is reversible.
- GET_CHG_REQUEST — Retrieves the change request definition, resolving and returning the change request details used by the other utility routines.
These routines are typically invoked together to check eligibility, perform the state transition, and record the result.
Tables Accessed
The package references the following objects via APPS synonyms:
- OKE_CHG_REQUESTS — the primary change request entity; read and updated as statuses and processing outcomes are applied.
- OKE_CHG_LOGS and OKE_CHG_LOGS_S — the change-request log tables. The sequence
OKE_CHG_LOGS_Ssupplies log identifiers, whileOKE_CHG_LOGSstores the logged processing messages and results. This is the object most closely associated with the user's search term. - OKE_CHG_STATUSES_B and OKE_CHG_STATUSES_TL — the base and translated status definition tables, used to resolve valid statuses and their display names.
- OKE_K_HEADERS_V, OKE_K_TYPES_VL, and OKE_K_VERS_NUMBERS_H — knowledge/contract header, type, and version number views and tables, used to identify the contract and version affected by the change request.
- FND_USER and PER_ALL_PEOPLE_F — resolve the application user and the associated person, typically to record who initiated, processed, or approved a change request.
- DUAL — used for singleton evaluations and simple lookups.
The package also depends on FND_GLOBAL (session/user context), FND_MESSAGE (error and message text), and WF_ENGINE (Workflow Engine), indicating that change-request state changes and notifications may be routed through Oracle Workflow.
Usage Notes
OKE_CHG_REQ_UTILS is not a standalone, user-facing API. It is invoked indirectly by the OKE Change Request forms and by the concurrent programs and workflow activities that process change requests in the background. Interactive form operations — submitting a change for approval, implementing a change against the contract, or undoing a previously applied change — call into these routines to validate eligibility and persist results. Workflow-driven processing similarly depends on the package to evaluate OK_TO_IMPLEMENT and OK_TO_UNDO and to update statuses and logs as steps complete.
Because the package is not referenced by any external database object outside the OKE change-request chain and is not a published API, customizations should call the supported OKE change request APIs rather than OKE_CHG_REQ_UTILS directly, to avoid bypassing validation logic and log integrity. When troubleshooting change request behavior in EBS 12.1.1 or 12.2.2, the OKE_CHG_LOGS table populated by this package — keyed through OKE_CHG_LOGS_S — is the primary diagnostic source for determining why a change request did or did not progress.
-
SEQUENCE: OKE.OKE_CHG_LOGS_S
12.1.1
owner:OKE, object_type:SEQUENCE, object_name:OKE_CHG_LOGS_S, status:VALID,
-
SYNONYM: APPS.OKE_CHG_LOGS_S
12.1.1
owner:APPS, object_type:SYNONYM, object_name:OKE_CHG_LOGS_S, status:VALID,
-
SEQUENCE: OKE.OKE_CHG_LOGS_S
12.2.2
owner:OKE, object_type:SEQUENCE, object_name:OKE_CHG_LOGS_S, status:VALID,
-
SYNONYM: APPS.OKE_CHG_LOGS_S
12.2.2
owner:APPS, object_type:SYNONYM, object_name:OKE_CHG_LOGS_S, status:VALID,
-
12.2.2 DBA Data
12.2.2
-
12.1.1 DBA Data
12.1.1
-
12.2.2 DBA Data
12.2.2
-
12.1.1 DBA Data
12.1.1
-
PACKAGE BODY: APPS.OKE_CHG_REQ_UTILS
12.2.2
owner:APPS, object_type:PACKAGE BODY, object_name:OKE_CHG_REQ_UTILS, status:VALID,
-
PACKAGE BODY: APPS.OKE_CHG_REQ_UTILS
12.1.1
owner:APPS, object_type:PACKAGE BODY, object_name:OKE_CHG_REQ_UTILS, status:VALID,
-
12.1.1 DBA Data
12.1.1
-
12.2.2 DBA Data
12.2.2
-
APPS.OKE_CHG_REQ_UTILS dependencies on OKE_CHG_LOGS_S
12.1.1
-
APPS.OKE_CHG_REQ_UTILS dependencies on OKE_CHG_LOGS_S
12.2.2
-
12.2.2 DBA Data
12.2.2
-
12.1.1 DBA Data
12.1.1