Search Results posting_detail_id

Overview

The CN_POSTING_DETAILS_ALL table is a core transactional data store within the Oracle E-Business Suite Incentive Compensation module (CN). It serves as the detailed ledger for all compensation-related transactions, capturing the granular results of the commission calculation engine. Each record represents a specific posting detail line, which is the fundamental unit for tracking earned credits, adjustments, and payments assigned to a sales representative (payee). Its primary role is to provide a complete, auditable history of compensation events, linking calculated amounts to their source transactions, applicable compensation plans, and final posting batches for payment processing. The table supports multi-organization architectures through its "_ALL" suffix, storing data across operating units.

Key Information Stored

The table's structure is designed to establish critical relationships and capture essential transaction attributes. The primary key, POSTING_DETAIL_ID, uniquely identifies each detail line. Key foreign key columns define its integration with other module entities: COMMISSION_HEADER_ID links to the source transaction header, SRP_PLAN_ASSIGN_ID ties the detail to the specific plan assignment of the payee, and CREDIT_TYPE_ID categorizes the nature of the credit (e.g., revenue, product). The POSTING_BATCH_ID associates the detail with a specific posting batch for payment runs, while QUOTA_ID can link the earning to a specific quota achievement. Other significant data points stored include the processing date, the posting type (indicating if it's an original, reversal, or adjustment), and the credited amount for the sales representative.

Common Use Cases and Queries

This table is central to compensation reporting, audit inquiries, and reconciliation processes. A common use case is tracing the detailed breakdown of a sales representative's payment. Analysts query this table to validate calculated amounts against source transactions or to investigate discrepancies. Another critical scenario involves auditing the impact of a plan or rule change by analyzing posting details before and after a specific processing date. A typical reporting query joins to related headers and payee information:

• SELECT pd.posting_detail_id, pd.processed_date, pd.credited_amount, ch.transaction_number, spa.salesrep_id FROM cn_posting_details_all pd, cn_commission_headers_all ch, cn_srp_plan_assigns_all spa WHERE pd.commission_header_id = ch.commission_header_id AND pd.srp_plan_assign_id = spa.srp_plan_assign_id AND spa.salesrep_id = :rep_id AND pd.processed_date BETWEEN :start_date AND :end_date;

Data from this table is also essential for rolling up earnings to period summaries and feeding into general ledger interfaces.

Related Objects

CN_POSTING_DETAILS_ALL is a central hub with documented foreign key relationships to several key tables in the Incentive Compensation schema. These relationships are fundamental to maintaining data integrity and enabling comprehensive joins for reporting:

• CN_COMMISSION_HEADERS_ALL: Joined via COMMISSION_HEADER_ID. Links the posting detail to its source transaction (e.g., an order or invoice).
• CN_SRP_PLAN_ASSIGNS_ALL: Joined via SRP_PLAN_ASSIGN_ID. Associates the detail with the specific compensation plan assignment for the payee.
• CN_CREDIT_TYPES_ALL_B: Joined via CREDIT_TYPE_ID. Categorizes the type of credit being posted.
• CN_POSTING_BATCHES_ALL: Joined via POSTING_BATCH_ID. Ties the detail line to a batch created for payment or journal posting.
• CN_QUOTAS_ALL: Joined via QUOTA_ID. Optionally links the earning to a specific quota record for performance tracking.