Search Results pay_au_process_modules_s

Overview

PAY_APM_INS is an Oracle E-Business Suite PL/SQL package body owned by the APPS schema. The name follows the Oracle Payroll naming convention in which the PAY_ prefix denotes a Payroll product module and the _INS suffix denotes an "insert" API. The package is classified as an API of type OTHER rather than as a public or private API, which indicates it is intended primarily as an internal, supporting component of the Australian Payroll process-module framework rather than as a general-purpose interface.

Its documented purpose is to provide insert routines for records held in the Australian Payroll process modules tables, PAY_AU_PROCESS_MODULES and PAY_AU_PROCESS_MODULES_S. These tables store the definitions of payroll process modules — the ordered steps that a payroll run executes for a given legislative or country-specific business process. PAY_APM_INS collaborates closely with the sibling package PAY_APM_BUS (business rules) and PAY_APM_SHD (the shadow/audit table handler), and it raises errors through the standard Oracle HRMS error-handling stack (HR_API, HR_MULTI_MESSAGE, HR_UTILITY, FND_MESSAGE), which confirms it is designed to operate within the HRMS API framework rather than as a standalone data-manipulation routine.

Key Procedures and Functions

The ETRM metadata documents three callable units:

• INS — The principal worker routine of the package. It performs the insertion of a process-module row (and its associated key value), applying the surrounding HRMS API validation, error-registration and commit-handling conventions. It is the entry point intended to be called when a new process module must be created programmatically.
• SET_BASE_KEY_VALUE — A supporting routine that establishes the base key value used to identify the row being inserted. It ensures the correct surrogate key is registered before the insert is executed, maintaining consistency between the base table and its shadow table.
• A third documented procedure or function exists in the package, bringing the total to three callable units; it is not individually named in the available extract, but it forms part of the same insert/key-management sequence described above.

No parameter lists are published in the ETRM extract, so signatures must be confirmed by inspecting the package header in the target environment before invoking these units from custom code.

Tables Accessed

• PAY_AU_PROCESS_MODULES — The base Australian Payroll process-modules table, accessed through its APPS synonym. PAY_APM_INS writes new process-module definitions into this table; it is the primary target of the INS routine.
• PAY_AU_PROCESS_MODULES_S — The corresponding shadow (audit) table. Every HRMS datetracked table has a paired _S table, and PAY_AU_PROCESS_MODULES_S is populated with the audit/date-tracked image of each inserted row.
• SYS.DUAL — Referenced for trivial single-row expressions such as sequence lookups, which is typical of HRMS insert APIs.

The dependencies also show calls to HR_UTILITY and HR_API for date-track and key-generation processing, and FND_MESSAGE / HR_MULTI_MESSAGE for error message construction.

Usage Notes

PAY_APM_INS is not referenced by any other database object, indicating that it sits at the leaf of the dependency tree; instead, it is invoked directly by application code or by sibling packages such as PAY_APM_BUS that manage process-module maintenance. The package is typically called during the setup of Australian Payroll process modules, either from a Payroll setup form, from a concurrent program that seeds or migrates process-module definitions, or from custom PL/SQL that must create process modules programmatically.

Because PAY_APM_INS is not a public API, customers should not treat it as a supported extension point. Custom code that must insert process-module rows should prefer the supported business API in PAY_APM_BUS and allow that package to delegate the physical insert to PAY_APM_INS, preserving validation, error severity handling and the base/shadow key synchronisation performed by SET_BASE_KEY_VALUE. Any direct call should be made in a controlled transaction with explicit commit handling, since HRMS APIs raise parameterised errors rather than performing silent rollbacks.