Search Results delete_plan_design_result

Overview

BEN_PLAN_DESIGN_TXNS_API is a public PL/SQL package owned by the APPS schema in Oracle E-Business Suite. It belongs to the Oracle Advanced Benefits (OAB) module and underpins the Plan Design Wizard (PDW), the guided configuration tool through which benefits administrators define and maintain benefit plans, program and plan types, eligibility, rates, and coverage rules. The package serves as the transactional and integration layer for the wizard: it persists the intermediate design data captured during a wizard session, orchestrates the copy of plan design entities into the operative BEN tables, and exposes lookup and mapping utilities required by the wizard's user interface. Because the object is classified as an API in the ETRM repository and holds a VALID status in both 12.1.1 and 12.2.2, it is a supported, callable entry point rather than an internal-only unit. Its documentation lists 21 procedures and functions, and it is both dependent upon lower-level APIs (notably HR_API and the SYS.STANDARD package) and referenced by nine other packages, including the wizard API, the plan design copy process, and several BEN_PD_COPY_TO_BEN_* copy routines, confirming its role as the central design-transaction hub.

Key Procedures and Functions

The documented entry points cluster into four functional groups.

• Transaction maintenance: CREATE_PLAN_DESIGN_TXN, UPDATE_PLAN_DESIGN_TXN, and DELETE_PLAN_DESIGN_TXN manage the lifecycle of individual plan design transaction records, while CREATE_PLAN_DESIGN_RESULT, UPDATE_PLAN_DESIGN_RESULT, and DELETE_PLAN_DESIGN_RESULT maintain the associated result rows produced when a design transaction is processed.
• Mapping utilities: UPDATE_MAPPING_TARGET_DATA, AUTO_MAPPING, GET_MAPPING_INFO, GET_MAPPING_COLUMN_NAME, and GET_REQUIRED_MAPPING_COMPLETED support the column-to-entity mapping steps of the wizard, including automatic suggestion of mappings and validation that mandatory mappings are complete.
• Copy and submission control: SUBMIT_COPY_REQUEST and PDW_SUBMIT_COPY_REQUEST initiate the transfer of design data into the operational benefits tables; WRITE_TXN_TABLE_ROUTE and UPDATE_HGRID_CHILD_SELECTION support hierarchy grid interaction and transaction routing; UPDATE_DOWNLOAD_STATUS records the status of design download processing.
• Diagnostics and housekeeping: GET_LOG_DISPLAY, CREATE_LOG, GET_USER_BUSINESS_GROUP_IDS, and PURGE_PLAN_DESIGN_PROCESS provide logging, business group resolution, and purge of obsolete design process data.

Tables Accessed

Through APPS synonyms the package reads and writes design and reference tables spanning Benefits, Human Resources, and Payroll. Benefits plan and plan type definitions are held in BEN_PL_F, BEN_PL_TYP_F, and BEN_OPT_F, which store plan, plan type, and option metadata used during design and copy. BEN_COPY_ENTITY_RESULTS records the outcome of copy operations initiated through SUBMIT_COPY_REQUEST. Organization and business group context is obtained from HR_ALL_ORGANIZATION_UNITS, HR_ALL_ORGANIZATION_UNITS_TL, HR_ASSIGNMENT_SETS, and FND_USER, while message text for logging and user feedback is drawn from FND_NEW_MESSAGES. Payroll and rate-related validation draws on PAY_ALL_PAYROLLS_F, PAY_BALANCE_TYPES, PAY_BALANCE_DIMENSIONS, PAY_DEFINED_BALANCES, PAY_ELEMENT_TYPES_F, and PAY_ELEMENT_TYPES_F_TL, supporting the rate and coverage module invoked from the wizard.

Usage Notes

BEN_PLAN_DESIGN_TXNS_API is normally invoked indirectly. The Plan Design Wizard API (BEN_PLAN_DESIGN_WIZARD_API) and the copy modules (BEN_PD_COPY_TO_BEN_ONE, TWO, and FIVE, BEN_PD_RATE_AND_CVG_MODULE, BEN_PLAN_DESIGN_ELPRO_MODULE, BEN_PLAN_DESIGN_PLAN_MODULE, and BEN_PLAN_DESIGN_COPY_PROCESS) call it in sequence to record design transactions, resolve mappings, and submit copy requests. Consequently, administrators interact with it through the Plan Design Wizard forms and related concurrent programs rather than by direct invocation. Custom code should call only the documented, API-classified procedures, respect the standard EBS API conventions (initialization of WHO columns, business group context, and error handling), and avoid touching the underlying tables directly, since copy and purge logic enforces referential dependencies across the BEN and PAY schemas.