Search Results pay_ter_bus




Overview
Explore in AI Chat

Overview

PAY_TER_BUS is an Oracle Applications (APPS) PL/SQL package belonging to the Oracle Payroll (PAY) schema family in Oracle E-Business Suite 12.1.1 and 12.2.2. Its object name follows the naming convention used for "business" layer packages that encapsulate the validation logic associated with a shadow or template entity—in this case the PAY_TER (Template Element / Template-related) object. The package functions as the business-rule tier sitting above the shadow-table maintenance routines, providing centralized validation services that are called before inserts, updates, or deletes are committed against payroll template and shadow balance data. ETRM classifies the package under API classification OTHER, indicating that it is an internal application programming interface rather than a public, documented open interface. It is a dependent object: it reads from PAY_TER_SHD (the shadow table/package for the TER entity) and is in turn referenced by the DML-oriented packages PAY_TER_INS, PAY_TER_UPD, and PAY_TER_DEL, as well as by itself. Its status is VALID in the APPS schema.

Key Procedures and Functions

The ETRM documentation records three documented procedures on this package, all of which are validation entry points rather than data-manipulation routines:

  • INSERT_VALIDATE — Validates the attribute values supplied when a new template/shadow record is being created. It is invoked by the insert-side DML package (PAY_TER_INS) prior to the physical row insertion, allowing business-rule violations to be raised before any data is written.
  • UPDATE_VALIDATE — Validates the modified attribute set when an existing template/shadow record is being changed. It is called by PAY_TER_UPD to confirm that the proposed new values remain consistent with the shadow balance and template configuration rules.
  • DELETE_VALIDATE — Validates whether an existing record may legitimately be removed. It is called by PAY_TER_DEL to enforce referential and business constraints before the delete is performed.

No parameter lists are documented in the ETRM metadata, and the procedures are not published as callable open APIs. Their names indicate a symmetric validate-before-act pattern shared with the companion INS/UPD/DEL packages.

Tables Accessed

The package operates against the shadow balance and template configuration tables of Oracle Payroll, reached through APPS synonyms. The documented tables are: PAY_ELEMENT_TEMPLATES, PAY_SHADOW_BALANCE_CLASSI, PAY_SHADOW_BALANCE_FEEDS, PAY_SHADOW_BALANCE_TYPES, PAY_SHADOW_BAL_ATTRIBUTES, PAY_SHADOW_DEFINED_BALANCES, PAY_SHADOW_ELEMENT_TYPES, PAY_SHADOW_ELE_TYPE_USAGES, PAY_SHADOW_FORMULA_RULES, PAY_SHADOW_GU_BAL_EXCLUSIONS, PAY_SHADOW_INPUT_VALUES, PAY_SHADOW_ITERATIVE_RULES, PAY_SHADOW_SUB_CLASSI_RULES, and PAY_TEMPLATE_FF_USAGES. Collectively these tables define balance types, feeds, classifications, attributes, element types and their usages, formula and iterative rules, input values, balance exclusions by GRE/legal entity, and template fast-formula usages. The package reads these tables to confirm that a proposed template or shadow record is internally consistent with the defined balance and element-type model. It also references the PAY_TER_SHD package, which supplies shadow-table access and column-level resolution services.

Usage Notes

PAY_TER_BUS is not normally invoked directly by end users. It is a supporting business layer called by the PAY_TER_INS, PAY_TER_UPD, and PAY_TER_DEL packages, which in turn are driven by Oracle Payroll setup forms, the Template Element / Balance setup user interface, and installation or upgrade concurrent programs that load shadow balance and element template metadata. Because the package is classified as OTHER and is undocumented as a public API, customers and implementers should treat it as internal: custom code should call the supported DML packages or the appropriate open interfaces rather than PAY_TER_BUS directly. When troubleshooting validation errors during template or shadow balance maintenance, the exception raised from INSERT_VALIDATE, UPDATE_VALIDATE, or DELETE_VALIDATE will typically surface through the calling form. The package is also self-referencing, indicating internal recursive or helper calls within the same business-rule layer.