Search Results pl_dsgn

Overview

BEN_CWB_REFRESH_PKG is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite, and belongs to the Advanced Benefits (BEN) module, specifically the Compensation Workbench (CWB) subsystem. Its documented role is to concentrate into a single callable unit the refresh operations that keep Compensation Workbench data synchronized with the underlying benefits and enrollment structures. As stated in the package header comments, the package "contains calls for refreshing person_info, pl_dsgn, summary and consolidation of summary," and it is designed to be invoked by a concurrent process rather than by interactive user code.

The refresh logic is driven by an effective date. If no value is supplied for the effective date parameter, the package falls back to the latest event occurred date (lf_evt_ocrd_dt) of the life event or enrollment period context, ensuring that the refreshed data reflects the correct point in time for the Compensation Workbench processing cycle.

Key Procedures and Functions

The package exposes exactly one documented procedure: REFRESH. ETRM records no additional procedures or functions in this package.

• REFRESH — The single entry point. It accepts standard concurrent program return parameters (errbuf and retcode), a plan/group identifier, the last event occurred date, an optional effective date, and a set of flag parameters that independently control which refresh activities are performed: refreshing the summary, refreshing person information, refreshing the plan design, consolidating the summary, initializing rank, refreshing exchange data, and optionally refreshing rates from rule (the latter defaulting to "N"). The procedure therefore acts as an orchestrating wrapper: it conditionally executes the person info refresh, plan design refresh, summary refresh and summary consolidation based on the caller-supplied flags.

Because the flags are passed in rather than determined internally, the same procedure can serve multiple concurrent programs with differing refresh scopes, and it can also be called programmatically with a tailored combination of flags.

Tables Accessed

ETRM documents the following tables (accessed through APPS synonyms) as being referenced by this package:

• BEN_CWB_PERSON_INFO — holds Compensation Workbench person-level information; the target of the person info refresh controlled by p_refresh_person_info_flag.
• BEN_CWB_PERSON_RATES — stores person rate information, refreshed when the rate-from-rule option is enabled.
• BEN_CWB_PL_DSGN — stores Compensation Workbench plan design data, refreshed under the control of p_refresh_pl_dsgn_flag. This is the table corresponding to the pl_dsgn element named in the package comments.
• BEN_CWB_SUMMARY — the summary data store; refreshed and consolidated per the summary and consolidation flags.
• BEN_ENRT_PERD — the enrollment period definition, used to establish the period context and effective dating for the refresh.
• BEN_POPL_ENRT_TYP_CYCL_F — the populated enrollment type cycle table, which determines which enrollment cycles and populations participate.
• PER_ASSIGNMENT_EXTRA_INFO — assignment-level extra information required to align person data with assignments during the refresh.

Usage Notes

BEN_CWB_REFRESH_PKG is intended to be executed by a concurrent process. The presence of errbuf and retcode in the REFRESH signature is the standard EBS convention for concurrent program PL/SQL, confirming that a concurrent program definition exists (or is expected) around this procedure. Typical invocation occurs during Compensation Workbench setup and cycle maintenance, when administrators must re-synchronize person information, plan design, summaries and consolidated summaries after changes to benefits enrollment or plan configuration.

The package is not documented as being referenced by any other packages, which suggests it sits at the top of its call stack and is not a shared utility. Custom code should therefore treat it as an orchestration entry point: pass the group plan identifier, the event occurred date and the desired refresh flags, and check retcode for success or failure. Because the effective date defaults to the event occurred date when omitted, callers that require a specific effective date should pass p_effective_date explicitly to avoid ambiguities in time-based refreshes.