Search Results reject_transaction

Overview

PER_SP_STAGE is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that supports the Succession Planning (SP) feature set within Oracle Human Resources / Oracle Talent Management. Its documented role is to stage, copy, and promote succession plan data and related HR entities between staging tables and the live Succession Planning structures, while orchestrating the associated Oracle Workflow approvals. The package header is declared AUTHID CURRENT_USER and is registered with an API classification of OTHER in the ETRM repository for release 12.2.2, consistent with its 12.1.1 lineage (header revision perspstage.pkh 120.2, dated 2011).

The name "stage" reflects the core design pattern: changes to succession plans are first written into staging/copy-entity tables, validated, exposed to a workflow approval process, and only then committed to the operational tables. This protects the integrity of published succession plans and provides an auditable approval trail.

Key Procedures and Functions

The package exposes ten documented procedures:

• createHRApiTransaction — Creates an HR API transaction record for a given person, returning the HR API transaction identifier. Used to register staged person-level changes with the HR API framework.
• create_sp — Creates a Succession Planning staging context for a business group, returning a copy entity transaction identifier.
• stage_to_sp (the object of the user's search) — Promotes staged succession plan data into the live SP structures for a given effective date, referencing an existing copy entity transaction, and honouring a validate flag that allows the operation to be run in validation-only mode without committing.
• sp_to_stage — The inverse operation: copies live succession planning data (identified by plan and optionally business group and mode) back into the staging area for a given effective date, returning a copy entity transaction identifier.
• launch_wf — Launches the Oracle Workflow process associated with the transaction, taking the process, item type, person, copy entity transaction, and an approval-required indicator.
• reject_transaction — Workflow callback function that handles rejection of a staged transaction.
• get_approval_req — Workflow callback function that determines whether approval is required for the transaction.
• commit_transaction — Workflow callback function that finalises the transaction upon approval.
• commit_txn — Commits a copy entity transaction by its identifier.
• refresh_txn — Refreshes the state of a copy entity transaction by its identifier.

Tables Accessed

Through APPS synonyms, the package reads and writes the following documented tables:

• PER_SP_PLAN and PER_SP_SUCCESSOR_IN_PLAN — The core Succession Planning plan and successor-in-plan tables that are the target of stage-to-SP promotion and the source of SP-to-stage extraction.
• PQH_COPY_ENTITY_TXNS and PQH_TRANSACTION_CATEGORIES — The copy-entity transaction framework tables that track each staging transaction and its category.
• BEN_COPY_ENTITY_RESULTS and BEN_COPY_ENTITY_RESULTS_S — Results of copy-entity processing.
• HR_API_TRANSACTIONS and HR_API_TRANSACTIONS_S — HR API transaction registration and history.
• HR_WORKFLOW_ITEM_KEY_S — Workflow item key tracking for HR entities.
• WF_ITEMS, WF_PROCESS_ACTIVITIES, WF_ACTIVITIES, and WF_ITEM_ACTIVITY_STATUSES — Oracle Workflow definition and runtime tables used by the launch and callback procedures.
• FND_ATTACHED_DOCUMENTS — Attachments associated with the transaction, and DUAL for simple expression evaluation.

Usage Notes

PER_SP_STAGE is an internal utility layer rather than a public integration API. It is typically invoked indirectly through the Succession Planning user interface in the Oracle HRMS forms, and through concurrent programs that process staged succession plan transactions and drive the approval workflow. The workflow callback procedures (reject_transaction, get_approval_req, commit_transaction) are registered as Workflow activity functions and are executed by the Oracle Workflow engine when a staged transaction reaches the corresponding activity, not by end users. Because the package is AUTHID CURRENT_USER and references APPS synonyms directly, customisations should not call it directly without preserving the standard staging sequence: create or locate the copy entity transaction, call stage_to_sp in validation mode when testing, and only then commit. The ETRM metadata records zero dependent packages, indicating it sits at a leaf of the dependency chain and can be modified with limited blast radius within the module.