Search Results cn_payment_api_s

Overview

APPS.CN_PAYMENT_API_PKG is a PL/SQL package body belonging to the Oracle EBS Incentive Compensation (CN) module, deployed in the APPS schema and classified under the ETRM "OTHER" API category. Its documented purpose is to provide a programmatic insert interface against the CN_PAYMENT_API table, which stores payment transaction records generated by the Incentive Compensation payment engine. Rather than requiring external callers to issue direct DML against the underlying table, the package encapsulates the insert logic, including surrogate key generation through the CN_PAYMENT_API_S sequence. In EBS 12.1.1 and 12.2.2 the package retains the same signature and behaviour, as the header comment ("cntpmtab.pls 115.2") indicates a stable, low-revision object that has not required significant change across releases. The package is intentionally narrow in scope: it exposes a single documented procedure and contains no validation, update, or delete logic, positioning it as a low-level data access wrapper rather than a full business API.

Key Procedures and Functions

The package body documents exactly one procedure:

• Insert_Record — The "main insert procedure" of the package. It accepts a set of scalar parameters representing the attributes of a single payment API row — period, sales representative, payment date, payment type, amount, cost center, payment API identifier, pay run, source and destination credit types, role, and audit columns (created_by, creation_date) — and inserts one corresponding row into CN_PAYMENT_API. The parameter declarations mirror the CN_PAYMENT_API table columns using %TYPE anchoring, so the procedure remains type-consistent with the table definition. The only transformation applied during insertion is on the payment API identifier: the procedure invokes NVL on the supplied value, substituting CN_PAYMENT_API_S.NEXTVAL when the caller passes NULL. This design allows callers to either supply an explicit primary key or delegate key generation to the sequence. No other procedures or functions are documented in this package body.

Tables Accessed

The package references two objects, both via APPS synonyms:

• CN_PAYMENT_API — The target table and the sole DML target of the package. The Insert_Record procedure writes a single row into this table, populating the columns that correspond to its parameter list. This table holds the payment API staging records consumed by Incentive Compensation payment processing.
• CN_PAYMENT_API_S — The sequence associated with CN_PAYMENT_API. It is referenced only through CN_PAYMENT_API_S.NEXTVAL inside the NVL expression on the payment_api_id column, providing the primary key when the caller does not supply one.

No other tables are read or written by the documented code. The package performs no lookups, no cross-table validation, and no reference to lookup or flexfield views.

Usage Notes

Because the package exposes only an insert primitive, it is typically invoked by internal Incentive Compensation processing — for example, by payment run logic or by custom extensions that need to stage payment API rows in a controlled manner. The "insert_record" search term that leads users to this object reflects the common requirement to populate CN_PAYMENT_API programmatically. Callers should note the following: the procedure performs no validation of period, salesrep, credit type, or role values, so referential and business-rule integrity must be enforced by the calling program; commit and rollback control remain entirely with the caller, as the procedure issues no transaction control statements; and where the caller relies on sequence-generated keys, the generated payment_api_id is not returned through an OUT parameter, so a subsequent query is required if the value must be known. Given the ETRM classification of OTHER and the absence of any documented callers (referenced by 0 other packages), custom code should treat this package as a supported but low-level utility rather than a full-featured API, and should consider whether standard Incentive Compensation concurrent programs provide a more complete and upgrade-safe path for the same data population.