Search Results cp_count_trigger_name




Overview
Explore in AI Chat

Overview

APPS.PAY_PAYRPHTS_XMLP_PKG is the generated PL/SQL package body that backs the Oracle E-Business Suite XML Publisher (BI Publisher) report associated with the Payroll "Trigger Status" concurrent program output. In Oracle EBS 12.1.1 and 12.2.2, XML Publisher concurrent programs are compiled as PL/SQL packages whose body encapsulates the report's data model, parameter defaulting, format triggers, and Report Builder placeholder accessors. This particular package serves the PAYRPHTS report, which produces a listing of payroll-related triggers and their current enabled/disabled status. Its header comment ($Header: PAYRPHTSB.pls 120.0 2008/01/11 07:08:06 srikrish noship $) confirms it is a server-side, non-shipped-logic package generated for the report definition rather than a general-purpose API.

The package's principal responsibilities are: confirming the report runtime environment in BeforeReport, resolving user-facing lookup meanings for report parameters, exposing placeholder values to the XML template, and providing no-op or pass-through hooks required by the XML Publisher/RDF integration layer. The documented API classification is OTHER, meaning it is not part of a published interfaces set and should be considered report-internal.

Key Procedures and Functions

  • BEFOREREPORT — Executed automatically before the report's main query runs. It normalizes the two report parameters by applying NVL defaults: P_Status_1 defaults to 'DISABLED' and P_Detail_1 defaults to 'Y'. It also ensures a row exists in FND_SESSIONS for the current session, and optionally reads a TRACE action parameter from PAY_ACTION_PARAMETERS (the SQL trace call itself is commented out). Returns TRUE to allow the report to proceed.
  • AFTERREPORT — Post-report hook; the documented implementation simply returns TRUE with no additional logic.
  • CF_COUNT_TRIGGER_NAMEFORMULA — A Report Builder format-trigger formula that assigns the incoming CS_COUNT_TRIGGER_NAME value to the CP_COUNT_TRIGGER_NAME placeholder and returns 1. This is the mechanism by which a computed column value is surfaced to the XML template.
  • CF_ENABLED_FLAGFORMULA — Resolves the parameter value stored in P_STATUS_1 into its descriptive meaning by querying HR_LOOKUPS for lookup type TRIGGER_STATUS, stores the result in CP_STATUS, and returns it. This is the direct source of the cp_status value users see in the report output.
  • CP_COUNT_TRIGGER_NAME_P — Placeholder accessor returning the current value of CP_COUNT_TRIGGER_NAME for template reference.
  • CP_STATUS_P — Placeholder accessor returning the current value of CP_STATUS; this is the function the XML template calls to display the resolved trigger status text.

Tables Accessed

  • FND_SESSIONS — Read and inserted into during BeforeReport. A row is inserted for the current userenv('sessionid') only if one does not already exist, which satisfies Form/Report session registration requirements used by the concurrent manager runtime.
  • PAY_ACTION_PARAMETERS — Queried (read-only) to retrieve the diagnostic TRACE parameter; the exception handler suppresses NO_DATA_FOUND, making the lookup optional.
  • HR_LOOKUPS — Queried in CF_ENABLED_FLAGFORMULA to translate the TRIGGER_STATUS lookup code into its display meaning, populating CP_STATUS.

Usage Notes

This package is not intended to be called directly from forms or custom code. It is invoked implicitly by the Oracle Reports/XML Publisher runtime whenever the corresponding payroll trigger status concurrent program is submitted, with the runtime calling BeforeReport, the format-trigger formulas for each row or column, and AfterReport in standard order. The CP_STATUS and CP_COUNT_TRIGGER_NAME placeholders are referenced from the XML template via the accessor functions, so any custom template that relies on trigger status display must use the same placeholder names. Because the package is documented as referenced by zero other packages, changes to it carry no cross-package dependency risk, but it should still be treated as report-generated code and regenerated rather than hand-patched during upgrades. In 12.2.2 the package resides under the APPS schema and is subject to standard EBS editioning and customization standards.