Search Results conc_dispatch

Overview

APPS.CN_TRANSACTION_LOAD_PKG is a core concurrent-loading package within the Oracle E-Business Suite TeleSales/Compensation (CN) module, commonly referred to as ETRM or Channel Revenue Management. Its principal business function is to move commissionable transaction data from the open interface table CN_COMM_LINES_API into the commission headers repository, ultimately populating CN_COMMISSION_HEADERS. The package header comment states its purpose succinctly: procedures to load transactions from cn_comm_lines_api to cn_commission_headers.

The body is versioned at file header cnloadb.pls, revision 120.20, dated 2010/07/09. It is classified as an OTHER API in the ETRM 12.2.2 metadata set, meaning it is not a published open interface API but rather an internal worker package invoked by concurrent processing. It maintains two global process identifiers, g_logical_process and g_physical_process, both initialized to 'LOAD', which are used for logging and batch traceability. Several user-defined exceptions are declared to control flow, including no_trx_lines, fail_validate_ruleset, conc_fail, and invalid_date.

Key Procedures and Functions

The documented package exposes seven procedures/functions. The LOAD procedure is the primary entry point that drives the transaction load, orchestrating validation and insertion of commission transactions. LOAD_WORKER performs the lower-level row processing, typically called from LOAD to handle a bounded work set.

CHECK_API_DATA validates the staging rows in CN_COMM_LINES_API before they are promoted; per the history comments this procedure was amended to add org_id joins to its subqueries. ASSIGN applies the assignment logic that maps transactions to the appropriate commission structure, and the history notes record that it was modified for bug fix 2781346 together with the addition of a no-trx-lines exception handler.

Two procedures directly match the user's search term, conc_dispatch: PRE_CONC_DISPATCH executes preparatory logic before the concurrent manager dispatches the load worker, and POST_CONC_DISPATCH performs cleanup, status reconciliation, and any post-processing after dispatch. Together they bracket the concurrent execution of the load. VOID_BATCHES is responsible for marking transaction batches as void, reversing or invalidating commissionable lines already loaded. The package also contains local helper routines, notably a debugmsg procedure that forwards truncated messages to cn_message_pkg.DEBUG, and a get_physical_batch_id function that retrieves a unique batch identifier from the sequence cn_process_batches_s3.

Tables Accessed

The package reads and writes across the following documented tables. CN_COMM_LINES_API and CN_COMM_LINES_API_ALL form the source staging interface from which transactions are validated and loaded. CN_COMMISSION_HEADERS, CN_COMMISSION_HEADERS_ALL, and CN_COMMISSION_HEADERS_S are the target commission repositories and their sequence-backed key source. CN_PROCESS_BATCHES together with sequences CN_PROCESS_BATCHES_S1, S2, and S3 govern batch identification and control, with S3 supplying physical batch IDs. CN_PERIOD_STATUSES_ALL is consulted to validate that transactions fall within an open accounting or commission period, supporting the invalid_date exception. CN_REVENUE_CLASSES provides revenue classification for loaded lines, while CN_REPOSITORIES_ALL supports assignment and repository resolution. DBMS_LOCK is used for serialization, and DUAL supports the sequence lookup in get_physical_batch_id.

Usage Notes

CN_TRANSACTION_LOAD_PKG is invoked in ETRM 12.1.1 and 12.2.2 primarily through concurrent programs that load commission transactions, and its procedures are referenced by two other packages according to the documented metadata. It should not be called directly from forms or ad hoc SQL without understanding the batch sequencing and locking behavior, since DBMS_LOCK serialization and the cn_process_batches sequences assume controlled concurrent invocation. Custom development should prefer the supported public APIs; this body is best treated as an internal implementation module for the transaction load and conc_dispatch concurrent workflow.