Search Results posting_batch_id

Overview

The CN_POSTING_BATCHES_ALL table is a core data object within the Oracle E-Business Suite (EBS) Incentive Compensation (CN) module. It serves as the master control table for the posting process, which is a critical step in the compensation cycle. Posting is the operation that finalizes calculated incentive earnings, making them official and available for payment processing. Each record in this table represents a distinct posting batch, a logical grouping of transactions that are processed together. This batching mechanism provides administrators with control, auditability, and the ability to manage the posting workflow, including initiating, reviewing, and potentially reversing a set of postings. As an "ALL" table, it is designed to support multi-organization structures (Multi-Org) by potentially storing data partitioned by operating unit.

Key Information Stored

The table's structure is centered on managing the batch's identity, status, and processing context. The primary identifier is the system-generated POSTING_BATCH_ID, which is the primary key (CN_POSTING_BATCHES_PK). A unique human-readable identifier for the batch is stored in the NAME column (enforced by the CN_POSTING_BATCHES_UK1 unique key), allowing users to easily reference specific batches. While the provided metadata does not list all columns, typical columns in such a control table would include status flags (e.g., POSTING_STATUS), dates for creation and last update (CREATION_DATE, LAST_UPDATE_DATE), identifiers for the creator and last updater (CREATED_BY, LAST_UPDATED_BY), and context fields such as the operating unit (ORG_ID) to align with the Multi-Org model. The batch's processing parameters and final status are central to the data held.

Common Use Cases and Queries

This table is primarily accessed for administrative oversight and troubleshooting of the posting process. Common operational reports list all posting batches within a date range for review. A fundamental query retrieves batch headers along with summary details from related tables:

SELECT pb.name, pb.posting_batch_id, pb.creation_date, COUNT(pd.posting_detail_id) AS transaction_count
FROM cn_posting_batches_all pb,
cn_posting_details_all pd
WHERE pb.posting_batch_id = pd.posting_batch_id
AND pb.creation_date >= TRUNC(SYSDATE - 30)
GROUP BY pb.name, pb.posting_batch_id, pb.creation_date
ORDER BY pb.creation_date DESC;

Another critical use case is identifying batches in a specific state, such as 'PENDING' or 'POSTED', to manage workflow. Support personnel also query this table to trace issues by joining it to the detailed posting lines (CN_POSTING_DETAILS_ALL) and further back to source calculations.

Related Objects

The CN_POSTING_BATCHES_ALL table has a direct parent-child relationship with the transaction detail table, as documented in the provided metadata. The primary relationship is:

• CN_POSTING_DETAILS_ALL: This table holds the individual posted compensation transactions. It references CN_POSTING_BATCHES_ALL via the foreign key column CN_POSTING_DETAILS_ALL.POSTING_BATCH_ID. This link ensures every posted detail is associated with a controlling batch header. The join condition is typically CN_POSTING_DETAILS_ALL.POSTING_BATCH_ID = CN_POSTING_BATCHES_ALL.POSTING_BATCH_ID.

While not listed in the excerpt, this batch table is also central to the posting program logic itself, likely referenced by key public APIs in the CN package suite that manage the posting lifecycle.