Search Results void_batches

Overview

APPS.CN_TRANSACTION_LOAD_PKG is the load engine of the Oracle E-Business Suite TeleSales/Channel Revenue Management (formerly Oracle Trade Management / Incentive Compensation) commission processing stack. Its stated purpose, taken from the package header, is to load transactions from the commission lines API staging table CN_COMM_LINES_API into the commission header tables stored in CN_COMMISSION_HEADERS. In effect, the package bridges the interface layer (“API” rows written by external or feeder processes) and the application’s own working tables, so that commission and incentive transactions are validated, batched, and made available to downstream calculation programs.

The package is owned by APPS and carries an API classification of OTHER. It exposes seven documented program units and is referenced by two other packages, confirming it is an internal integration point rather than a public API for external consumers. The last annotated history entries (2001, 2005) indicate the logic has been stable across the 11i and R12 releases, including 12.1.1 and 12.2.2.

Key Procedures and Functions

• LOAD — The concurrent-program entry point. It initiates a load from the API table and returns standard concurrent request outputs (error buffer and return code), accepting parameters for sales representative, date range, class/role flag, and organization.
• LOAD_WORKER — Worker procedure invoked by the concurrent program CN_PROC_BATCHES_PKG.Runner. It performs the physical load for a given physical batch, scoped by salesrep, date range, and class/role flag.
• CHECK_API_DATA — Validates staged API data prior to loading. The header notes it is called by both CN_TRANSACTION_LOAD_PKG itself and by CN_TRANSACTION_LOAD_PUB, making it the shared validation gate for the inbound interface.
• ASSIGN — Associates a logical batch with an organization, effectively grouping loaded transactions for subsequent processing.
• PRE_CONC_DISPATCH — Pre-processing step executed before the concurrent worker is dispatched, taking salesrep, date range, and organization parameters.
• POST_CONC_DISPATCH — Complementary post-processing step after dispatch completes.
• VOID_BATCHES — Reverses or voids identified physical and logical batches, supporting correction and reprocessing scenarios.

Tables Accessed

The package reads and writes the commission header family — CN_COMMISSION_HEADERS, CN_COMMISSION_HEADERS_ALL, and CN_COMMISSION_HEADERS_S — which hold the loaded transaction records. Its primary source is CN_COMM_LINES_API and CN_COMM_LINES_API_ALL, the interface tables populated before the load. Period validation relies on CN_PERIOD_STATUSES_ALL, while batch tracking uses CN_PROCESS_BATCHES with its _S1, _S2, and _S3 set members. CN_REVENUE_CLASSES and CN_REPOSITORIES_ALL supply classification and repository context. DBMS_LOCK is used for concurrency control so competing load runs do not collide, and DUAL appears in routine scalar logic.

Usage Notes

Because the user searched for check_api_data, the most relevant documented fact is that CHECK_API_DATA is the routine that inspects and validates rows staged in the commission lines API tables before the load proceeds; it is shared between the load package and CN_TRANSACTION_LOAD_PUB. Practically, this means validation failures surface before any header rows are created, so diagnostic effort should begin with the API staging tables and the errors raised during this check. The package is normally driven through the Oracle Trade Management concurrent programs (via LOAD and CN_PROC_BATCHES_PKG.Runner calling LOAD_WORKER), not from forms directly. Custom code should call CN_TRANSACTION_LOAD_PUB rather than the internal procedures, since the _PUB wrapper applies the supported validation and sequencing. When troubleshooting loads in 12.1.1 or 12.2.2, verify the organization context and date range parameters, since both are used consistently by LOAD, CHECK_API_DATA, and the dispatch procedures.