Search Results generic_conc_processor




Overview

APPS.CN_PAYMENT_WORKSHEET_PVT_W is a private PL/SQL wrapper package in the Oracle EBS Incentive Compensation (CN) module. It is declared AUTHID CURRENT_USER and sits over the core business logic package CN_PAYMENT_WORKSHEET_PVT, exposing a thin, invoker-rights API surface for payment worksheet creation and processing. Payment worksheets are the staging construct through which Incentive Compensation aggregates calculated commissions and bonuses, allowing administrators to review, adjust, and release pay to sales representatives.

The _W suffix indicates the wrapper layer generated to bridge PL/SQL business logic with the Oracle Application Framework (OAF) / Forms runtime, whose generic infrastructure cannot bind strongly typed PL/SQL collection parameters directly. The public API classification is OTHER, meaning it is not a formally published open interface but an internal technical artifact. The header comment against 12.1.1 and 12.2.2 (version 120.1.12000000.3) confirms the package is unchanged in this respect across the two releases.

The package is directly relevant to the searcher's term generic_conc_processor: that token is the name of the wrapper's principal concurrent-program entry point.

Key Procedures and Functions

Six procedures are documented. Four are Rosetta conversion routines that translate between strongly typed PL/SQL records and the weakly typed JTF_NUMBER_TABLE arrays used by the generic OAF/concurrent framework:

  • rosetta_table_copy_in_p4 — converts the JTF_NUMBER_TABLE input arguments into the salesrep_tab_typ structure expected by the underlying private package.
  • rosetta_table_copy_out_p4 — performs the reverse conversion, returning salesrep_tab_typ data back out as JTF_NUMBER_TABLE arrays.
  • rosetta_table_copy_in_p7 — copies the seven numeric table parameters into the calc_rec_tbl_type calculation record collection used for worksheet calculation.
  • rosetta_table_copy_out_p7 — reverses the above, emitting calc_rec_tbl_type contents as numeric arrays.
  • generic_conc_processor — the concurrent-program driver. It accepts a pay run identifier, an organization identifier, a character argument, and two numeric tables, and returns the standard x_errbuf and x_retcode out parameters required by the concurrent manager. It orchestrates payment worksheet generation for a pay run.
  • create_worksheet — a conventional API-style procedure following the EBS API standard (version, message list, commit, validation level, and standard return-status/message outputs). It creates a payment worksheet and returns loading and status indicators describing the outcome.

Tables Accessed

Only one table is documented as referenced through APPS synonyms: PLITBLM. This is a generic EBS PL/SQL table/collection staging object used by the Rosetta and concurrent processing infrastructure to carry multi-row data between the Forms or concurrent layer and the database package. The actual incentive compensation base tables (payment worksheet headers, lines, and calculation results) are manipulated by the underlying CN_PAYMENT_WORKSHEET_PVT package rather than directly by this wrapper. No other packages are documented as referencing this one, confirming its role as a leaf-level technical component.

Usage Notes

This package is not typically called from customer-written code. It is invoked in two patterns:

  • Concurrent program: generic_conc_processor is registered as a concurrent program executable so that worksheet generation for a pay run can be submitted from the standard request submission form, entirely within the concurrent manager's error-handling contract.
  • OAF / Forms invocation: the Rosetta copy-in/copy-out procedures and create_worksheet are called by the Incentive Compensation administrative UI when a user creates or recalculates a payment worksheet.

Because the package is AUTHID CURRENT_USER, callers require direct object privileges; grant execution only to the appropriate Incentive Compensation responsibility users or custom concurrent programs. Direct modification is unsupported — Oracle retains ownership under the standard proprietary notices, and the wrapper should be treated as an internal implementation detail of the CN module across 12.1.1 and 12.2.2.