Search Results cn_aggrt_trx_pkg




Overview
Explore in AI Chat

Overview

CN_AGGRT_TRX_PKG is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite Releases 12.1.1 and 12.2.2. It forms part of the Oracle Trade Management (formerly Oracle Channel Revenue Management) commission calculation infrastructure and is classified as an "OTHER" API. Its core responsibility is the aggregation of transaction-level commission data into summarized rollup records that feed downstream commission calculation and settlement processing. In the commission lifecycle, individual transactions and commission lines must be consolidated before they can be evaluated against compensation plans and tiers; CN_AGGRT_TRX_PKG performs this consolidation step. The package is a valid, compiled object in the ETRM environment, and its dependency list is narrow, referencing only SYS.STANDARD, which indicates that it relies almost entirely on SQL operations against application tables rather than on other PL/SQL APIs. It is referenced by CN_CALC_ROLLUP_PVT, the private rollup engine used by the commission calculation flow, confirming its role as a supporting aggregation utility within the calculation stack.

Key Procedures and Functions

The documented interface exposes a single public program unit:

  • AGGREGATE_TRX — The primary entry point of the package. It drives the aggregation of transaction data, consolidating qualifying commission transactions into rollup structures associated with a submission batch and process batch. No parameter list is documented in the ETRM metadata, so parameters should not be assumed; callers must consult the package specification in the database for the exact signature.

Because the package body is not exposed in the metadata, any additional private helpers referenced internally are undocumented and should be treated as implementation detail. The public surface is limited to AGGREGATE_TRX, which is consistent with the package's narrow, single-purpose design.

Tables Accessed

The package operates against the following tables through APPS synonyms:

  • CN_COMMISSION_HEADERS_ALL and CN_COMMISSION_HEADERS_S — The base commission header (transaction) tables. AGGREGATE_TRX reads transaction headers that qualify for aggregation and likely updates or references them to flag aggregation status. The _S table provides the underlying row source for the _ALL synonym.
  • CN_CALC_SUBMISSION_BATCHES_ALL — Identifies the submission batch under which a commission calculation run is grouped. Aggregation output is tied to a specific submission batch, allowing results to be isolated per run and reprocessed independently.
  • CN_PROCESS_BATCHES_ALL — Tracks the process batch (job-level grouping) associated with the aggregation run, supporting parallel or multi-phase processing and error recovery.
  • PLITBLM — An Oracle Applications internal index-organized table commonly used as a temporary work area within PL/SQL APIs for bulk and array processing. Its presence indicates that AGGREGATE_TRX performs set-based volume processing rather than row-by-row logic.

Usage Notes

CN_AGGRT_TRX_PKG is not intended to be invoked directly by end users. It is called programmatically by CN_CALC_ROLLUP_PVT, which itself is invoked from the commission calculation concurrent programs and related rollup logic in Trade Management. Administrators typically trigger aggregation indirectly by submitting the commission calculation or rollup concurrent request, which passes the relevant submission batch and process batch identifiers through the calling stack. Customizations that extend commission processing should call AGGREGATE_TRX only after a valid submission batch and process batch context has been established, and should respect the batch and commit semantics enforced by CN_CALC_ROLLUP_PVT. Because the package is a private-style utility referenced by only one dependent package, Oracle does not document it as a supported public API; upgrades between 12.1.1 and 12.2.2 may alter the body without notice. Direct modifications or direct calls from custom code should therefore be avoided, and any extensions should be built on the documented rollup interfaces rather than on this package. Database-level grants should also be reviewed before attempting direct invocation.