Search Results pay_jp_soe_pkg




Overview
Explore in AI Chat

Overview

PAY_JP_SOE_PKG is an Oracle E-Business Suite Payroll package operating in the APPS schema and specifically targeting the Japanese payroll localization (the "JP" infix and the SOE designation refer to the Japanese Statutory/Statement of Earnings processing context). Its documented header carries the revision marker pyjpsoe.pkh 120.1, dated 2006/12/11, confirming that the package has been part of the Oracle Payroll codebase since the early R12 development cycle and remains present through EBS 12.1.1 and 12.2.2. The package is classified under ETRM as OTHER, meaning it is not a published open interface or public API but an internal utility package invoked by other payroll components.

Functionally, PAY_JP_SOE_PKG provides two related capabilities. The first is interrogation of payroll run state: it answers whether messages, retro entries, or element entries have already been processed for a given source, creator, or element entry. The second is action locking: it manages the interlock mechanism that prevents two payroll actions from processing the same assignment concurrently, returning structured lock status and lock action records. These two capabilities are tightly coupled, because the Japanese payroll run must verify that prior actions have completed before it can lock and proceed with the next action.

Key Procedures and Functions

  • MESSAGES_EXIST_FLAG — Returns a flag indicating whether message records exist for a given source identifier and source type.
  • RETRO_ENTRIES_PROCESSED_FLAG — Returns a flag indicating whether retroactive entries associated with a specified creator have already been processed.
  • ENTRY_PROCESSED_FLAG — Returns a flag indicating whether a specific element entry has been processed within an effective date range.
  • LOCK_ACTION — Returns a lock_action_t record describing the locking relationship between a locked action and a locking action type, including assignment action, payroll action, action type, and effective date.
  • LOCK_STATUS — Returns a lock_status_t record conveying the lock status and action status for a locked action and locking action type pair.
  • GET_LOCK_ACTION_VAL and GET_LOCK_ACTION_NUM — Return individual character and numeric attributes of a lock action, allowing callers to retrieve single values without materializing the full record.
  • GET_LOCK_STATUS_VAL — Returns a single status attribute from the lock status structure.
  • LOCK_ROW — Performs the row-level locking operation against the payroll action interlock data.
  • ROLLBACK — Reverses lock or processing state within the current transaction context.
  • REVERSE_ASSACT — Reverses an assignment action, restoring the assignment to its pre-action state.
  • RUN_ATTRIBUTES — Supplies or validates run-level attributes used during payroll action processing.
  • GET_EFFECTIVE_DATE — Resolves the effective date applicable to a lock or action context.

The package declares two PL/SQL record types, lock_status_t and lock_action_t, which are the return vehicles for the status and action query functions.

Tables Accessed

The package reads and writes PAY_ACTION_INTERLOCKS, the table that stores the interlock records governing which payroll action currently holds an assignment; this is the primary lock substrate. PAY_ASSIGNMENT_ACTIONS and PAY_PAYROLL_ACTIONS (with its _S synonym) supply action identity, status, and version information. PAY_ELEMENT_ENTRIES_F and PAY_RUN_RESULTS provide the entry and result data interrogated by the processed-flag functions. PAY_MESSAGE_LINES supports MESSAGES_EXIST_FLAG, while PAY_PRE_PAYMENTS relates to pre-payment handling within the Japanese run. PER_ALL_ASSIGNMENTS_F contributes assignment context, and DUAL and PLITBLM are used for trivial selects and PL/SQL table plumbing respectively.

Usage Notes

PAY_JP_SOE_PKG is referenced by ten other packages, indicating it is a shared internal utility rather than a standalone entry point. It is normally invoked from Japanese payroll concurrent programs and from the payroll action forms during run submission, when the system must confirm that earlier actions have been processed and then acquire an interlock before proceeding. Custom code should treat the package as internal and unsupported; direct calls risk interfering with the interlock state and leaving payroll actions in an inconsistent status. Where customization against Japanese payroll processing is required, the supported approach is to invoke the higher-level payroll action APIs, which manage PAY_JP_SOE_PKG locking internally.