Search Results cn_ledger_journal_entries

Overview

The APPS.CN_LEDGER_JOURNAL_ENTRIES_API package body is a PL/SQL application programming interface within the Oracle E-Business Suite Incentive Compensation (CN) module. Its name indicates that it governs the creation and manipulation of journal entries posted to the Incentive Compensation ledger. In the ETRM 12.2.2 metadata this object is classified as an API, confirming that it is an intent-revealing, supported entry point intended to be called by other EBS code rather than executed directly by an end user.

The package exists in both Oracle EBS 12.1.1 and 12.2.2 with status VALID in the APPS schema. Its core responsibility is to transform incentive compensation calculation results — commissions, bonuses, and related earnings tied to sales representatives and periods — into balanced journal entries that can be transferred to the General Ledger. It therefore sits at the boundary between the Incentive Compensation transactional tables and the financial accounting tables, encapsulating the business rules for batch creation, entry construction, and period validation so that callers need not write to the underlying tables directly.

Key Procedures and Functions

The ETRM documentation records four documented program units within this package. Two are named explicitly: NEW_JE and NAMES_FROM_IDS.

• NEW_JE — The primary entry point for creating a new ledger journal entry. As its name suggests, it constructs a journal entry record (or set of records) for a given business context, applying Incentive Compensation-specific logic such as resolving balance types, associating the entry with an existing journal entry batch, and stamping period and sales-representative references. This is the procedure most external callers invoke when they need the API to generate and register a compensated journal entry.
• NAMES_FROM_IDS — A utility routine that accepts identifier values and returns the corresponding human-readable names. This pattern is common in CN APIs, where internal numeric IDs for balance types, sales representatives, or periods must be translated into descriptive text for display, logging, or reporting. It is a convenience function rather than a transactional one.

The remaining two documented program units are not itemized in the supplied metadata; based on the surrounding dependencies, they are supplementary helpers supporting the two named routines. No parameter lists are documented and none should be inferred.

Tables Accessed

The package operates against the following tables (referenced through APPS synonyms):

• CN_LEDGER_JOURNAL_ENTRIES — The primary transactional table holding the journal entry lines the API creates and maintains.
• CN_LEDGER_JE_BATCHES — The batch header table; every journal entry must belong to a batch, and the API resolves or creates that batch context.
• CN_LEDGER_JOURNAL_ENTRIES_S — The sequence source that supplies unique primary key values for new journal entry rows.
• CN_LEDGER_BAL_TYPES — Defines the balance types used to classify entries (for example, earnings versus draws).
• CN_SRP_PERIODS and CN_PERIODS — Period definition and sales-representative period tables used to validate that an entry falls within an open, eligible compensation period.
• CN_SALESREPS — The sales representative master, used to associate entries with the correct payee.
• DUAL — The standard Oracle single-row table, typically used for sequence lookups or constant evaluation.

Usage Notes

Because the package is classified as an API, it is intended to be invoked from server-side PL/SQL rather than executed manually. Typical callers include the Incentive Compensation concurrent programs that generate and post journal entries, and any custom extension or hook code that needs to create compensated entries in a supported manner. The absence of any dependent objects referencing this package (it "is not referenced by any database object" per the ETRM metadata) indicates that it is a top-level integration surface: EBS forms, concurrent managers, or customer-written procedures call in, and the package itself does not sit beneath a higher abstraction layer. Customers extending Incentive Compensation should call NEW_JE in preference to inserting directly into CN_LEDGER_JOURNAL_ENTRIES, thereby preserving key generation, period validation, and batch integrity enforced by the API.