Results for “posted_date”

50+ results




Overview
Explore in AI Chat

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

CN_LEDGER_JE_BATCHES_ALL is a table in the CN (Incentive Compensation) product module of Oracle E-Business Suite, owned by the CN schema. It stores batches of journal entries generated by the Incentive Compensation engine. Each row represents a logical grouping of subledger accounting entries created during incentive compensation processing, most commonly in association with a payment run. The table serves as a header-level container whose child records are the individual journal lines maintained in CN_LEDGER_JOURNAL_ENTRIES_ALL.

From a Data Vault modeling perspective, the mined foreign-key structure classifies this object as hub-leaning. This is a heuristic suggestion rather than an Oracle-prescribed designation: the table behaves primarily as a business entity hub keyed on BATCH_ID, with downstream link and satellite relationships to payment runs, journal entries, and security groups.

Key Information Stored

The table is documented with 16 physical columns. The most significant are listed below.

  • BATCH_ID — Surrogate primary key, enforced by the CN_LEDGER_JE_BATCHES_PK constraint. Also appears in the unique index CN_LEDGER_JE_BATCHES_U1 as a business-key candidate alongside ORG_ID.
  • ORG_ID — Operating unit identifier, forming the second column of the U1 unique index; supports multi-org security and partitioning of incentive compensation data.
  • BATCH_NAME — User-facing identifier for the journal entry batch.
  • STATUS — Lifecycle state of the batch (for example, unposted or posted).
  • BATCH_DATE — Business date assigned to the batch.
  • POSTED_DATE — Date the batch was transferred to the general ledger.
  • TOTAL — Aggregate monetary value of the journal entries in the batch.
  • REASON — Descriptive or explanatory text associated with the batch.
  • LAST_REQUEST_ID — Concurrent request identifier of the process that last generated or updated the batch.
  • SECURITY_GROUP_ID — Foreign key to FND_SECURITY_GROUPS, supporting data security at row level.
  • WHO columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN provide standard auditing.

Common Use Cases and Queries

Functional users and developers query this table to reconcile incentive compensation journal batches, verify posting status, and trace a batch back to its originating payment run or concurrent request. A representative query retrieving posted batches for an operating unit follows:

  • SELECT batch_id, batch_name, status, batch_date, posted_date, total FROM cn_ledger_je_batches_all WHERE org_id = :p_org_id AND status = 'POSTED' ORDER BY batch_date DESC;
  • Join to child lines: SELECT b.batch_id, j.je_line_id, j.amount FROM cn_ledger_je_batches_all b JOIN cn_ledger_journal_entries_all j ON j.batch_id = b.batch_id WHERE b.batch_id = :p_batch_id;
  • Trace to payment run: SELECT p.payrun_id, b.batch_name FROM cn_payruns_all p JOIN cn_ledger_je_batches_all b ON b.batch_id = p.batch_id;

Typical reporting includes batch aging by status, totals by operating unit and posting date, and exception reports for batches that remain unposted. Because incentive compensation amounts feed the general ledger through these batches, audit and period-close queries frequently pivot on POSTED_DATE and BATCH_DATE.

Related Objects

  • CN_LEDGER_JOURNAL_ENTRIES_ALL — Child detail table; joined on BATCH_ID. Holds the individual journal lines belonging to each batch.
  • CN_PAYRUNS_ALL — References this table via BATCH_ID; links a payment run to the batch of journal entries it produced.
  • FND_SECURITY_GROUPS — Referenced through SECURITY_GROUP_ID for row-level security enforcement.
  • FND_CONCURRENT_REQUESTS — Traceable through LAST_REQUEST_ID to identify the concurrent program execution that created or updated the batch.

Together these objects form the incentive compensation to general ledger accounting chain: payment runs produce batches, batches contain journal entries, and security groups govern visibility across operating units.