Search Results cn_proc_batches_pkg




Overview
Explore in AI Chat

Overview

CN_PROC_BATCHES_PKG is the core batch processing engine of the Oracle E-Business Suite Incentive Compensation (CN) module, owned by the APPS schema and validated in ETRM 12.1.1 and 12.2.2. Its principal business function is the calculation and submission of compensation batches: it assembles the population of transactions and participants to be processed, applies the applicable compensation plans and formulas, evaluates plan rulesets, and writes the resulting calculation results into the Incentive Compensation submission tables. The package effectively bridges the formula-driven calculation logic (CN_FORMULA_COMMON_PKG) and the transaction loading layer (CN_TRANSACTION_LOAD_PKG / CN_TRANSACTION_LOAD_PUB) with the calculation submission public and private APIs (CN_CALC_SUBMISSION_PUB and CN_CALC_SUBMISSION_PVT), which in turn invoke CN_PROC_BATCHES_PKG for the heavy-lifting batch processing routines.

Key Procedures and Functions

Fifteen documented program units make up the package. The orchestration entry points are MAIN, which drives the overall batch run, and RUNNER, which executes the processing loop. PROCESSOR and PROCESSOR_CURR perform the per-batch and currency-specific processing respectively, while CALC, CALC_CURR, and CALCULATE_BATCH perform the actual compensation calculation for a batch, including its multi-currency variant. COLLECTION and CALCULATION_SUBMISSION gather the eligible data set and submit it for calculation. Supporting utilities include GET_PERIOD_NAME and GET_PERSON_NAME_NUM for resolving period and person identifiers, POPULATE_PROCESS_BATCH for building the process batch records, VALIDATE_RULESET_STATUS for confirming plan rulesets are in a valid state before calculation, CHECK_END_OF_INTERVAL for interval boundary handling, and FIND_SRP_INCOMPLETE_PLAN for identifying incomplete sales rep plan assignments. Parameter signatures are not documented in the ETRM metadata and should be verified against the package specification in the target instance.

Tables Accessed

The package operates predominantly against the calculation submission schema: CN_CALC_SUBMISSION_BATCHES and its _ALL variant hold the batch headers the package creates and updates; CN_CALC_SUBMISSION_ENTRIES and CN_CALC_SUBMISSION_ENTRIES_ALL hold the individual calculation entries; CN_CALC_SUB_QUOTAS stores quota attainment data used during calculation; and CN_CALC_SUB_VALIDATIONS_ALL records validation outcomes. Plan and rule configuration is read from CN_COMP_PLANS, CN_COMP_PLANS_ALL, and the dimension/hierarchy structures CN_DIM_EXPLOSION_ALL, CN_DIM_HIERARCHIES_ALL, CN_HIERARCHY_NODES_ALL, and CN_HIERARCHY_NODES_S, which drive plan eligibility and rollup logic. Transaction and commission detail are sourced from CN_COMMISSION_HEADERS_ALL and CN_COMMISSION_LINES_ALL, while CN_NOTIFY_LOG_ALL is used for notification logging. All access is via APPS synonyms and resolves to SYS.STANDARD for standard PL/SQL constructs.

Usage Notes

CN_PROC_BATCHES_PKG is not intended for direct ad hoc invocation by end users. In a standard EBS deployment it is invoked from the Incentive Compensation calculation concurrent programs and from the calculation submission public API CN_CALC_SUBMISSION_PUB, which is the supported integration point for external or custom callers. It is also called by CN_CALC_SUBMISSION_PVT, CN_FORMULA_COMMON_PKG, CN_TRANSACTION_LOAD_PKG, and CN_TRANSACTION_LOAD_PUB, and it is itself referenced by five packages, confirming its role as a shared internal service. Customizations should avoid calling the internal processors (CALC, PROCESSOR, RUNNER) directly and instead use the public submission API to preserve supported upgrade paths across 12.1.1 and 12.2.2. As the package relies heavily on plan and hierarchy configuration, rulesets should be validated via VALIDATE_RULESET_STATUS before batch submission to avoid partial or failed calculation runs. Dependencies on CN_COMP_PLANS_ALL and the hierarchy tables also mean that concurrent plan configuration changes during a running batch can produce inconsistent results, so calculation windows should be scheduled accordingly.