Search Results cn_transaction_load_pub




Overview
Explore in AI Chat

Overview

CN_TRANSACTION_LOAD_PUB is a public PL/SQL package in the APPS schema that supports the Oracle E-Business Suite Trade Management (formerly Oracle Commission/Billing Management) module. Its principal responsibility is to load and stage transactional commission and processing data into the ETRM repository so that downstream processing — calculation, adjustment, and reconciliation of sales commissions — can proceed. In the ETRM data model, transactional input must be consolidated into the commission header, line, and process-batch structures before the calculation engine can evaluate compensation rules. CN_TRANSACTION_LOAD_PUB serves as the controlled entry point for that staging activity, accepting transactional input from feeder systems and ETRM components and persisting it into the relevant base tables. The package is classified as a PUB (public) API, meaning its interfaces are intended for invocation by other ETRM packages and, where applicable, by custom extensions, rather than being strictly internal. It is documented as VALID and is present in both Oracle EBS 12.1.1 and 12.2.2 releases, with the 12.2.2 ETRM metadata confirming the package body and its declarations. The package relies on the FND_API utility package for standardized API behavior such as message handling and return status, indicating conformance to Oracle's public API conventions.

Key Procedures and Functions

The documented ETRM metadata exposes a single entry point: the LOAD procedure. As the sole documented program unit, LOAD encapsulates the transaction loading logic of the package. Its purpose is to accept a set of commission-related transaction records and persist them into the ETRM tables, establishing the header, line, and batch context required for subsequent commission processing. Because the metadata does not publish a parameter list, the exact signature is not restated here; implementers should reference the package specification through the ETRM repository or the data dictionary. The LOAD procedure is presumed to orchestrate insertion and update operations against the commission header, commission line, and process batch structures in a coordinated manner, applying the transaction identifiers and source data supplied by the caller. Its inclusion of FND_API dependencies suggests the procedure adheres to the standard API framework, including consistent return codes and error message propagation.

Tables Accessed

The package references a set of APPS synonyms representing the core ETRM transaction tables:

These tables together reflect the staging and batch-oriented nature of the load process: transactional detail is first qualified against period and repository context, grouped into commission headers, and controlled through process batches.

Usage Notes

CN_TRANSACTION_LOAD_PUB is typically invoked as part of the ETRM transaction processing flow rather than directly by end users. Within the standard product, it is referenced by the CN_GET_TX_DATA_PUB package, which extracts transaction data from source systems and calls the load routine to stage that data in the commission tables. It is also referenced by its own package body, confirming internal calls to the LOAD procedure. In practice, the package is reached either through ETRM concurrent programs that drive periodic transaction loads or through custom PL/SQL extensions that need to introduce external transaction data into the commission repository. Because it is a PUB API in the APPS schema, custom code should call it using the standard APPS.CN_TRANSACTION_LOAD_PUB qualification and observe the FND_API return status to detect errors. Direct DML against the underlying commission tables should be avoided in favor of this API, since the load logic enforces the batch, header, and line relationships required for consistent downstream calculation. The package is available in both EBS 12.1.1 and 12.2.2; behavior is expected to be consistent across these releases given the stable ETRM schema. Always validate the exact procedure signature in the target instance before developing custom integrations, as the published metadata does not enumerate parameter definitions.