Search Results update_contribution_usage

Overview

APPS.PAY_CNU_API is a PL/SQL package body that exposes the Contribution Usage API used by Oracle Payroll in Oracle E-Business Suite 12.1.1 and 12.2.2. Its principal business function is to maintain the definition of contribution usages within the French payroll contribution framework. Contribution usages associate an element, a process type, and a group code with a contribution usage type, rate information, and contribution codes, thereby determining how payroll contributions are calculated and applied over a defined effective period.

The package is classified as a public API in the ETRM metadata (owner APPS, API classification API). It is referenced by one other package, confirming that it is a shared building block accessed by higher-level payroll setup logic rather than an end-user-facing component. The package body carries the header identifier pycnuapi.pkb 115.6, and its highest-numbered entry point, CREATE_CONTRIBUTION_USAGE, is the specific procedure associated with the searched term create_contribution_usage.

Key Procedures and Functions

The ETRM metadata documents three procedures in this package. Their parameter lists should be taken only from the published API signature; the descriptions below summarize documented purpose.

• CREATE_CONTRIBUTION_USAGE — Creates a new contribution usage record for a given group code, process type, element name, and contribution usage type over an effective date range. It accepts an effective date, a from/to date pair, rate type and rate category, contribution code and type, an optional retroactive contribution code, and an optional business group identifier. It returns the new object version number and contribution usage identifier, and additionally accepts a code rate identifier as an IN OUT parameter so that callers may pass an existing rate reference or receive the one created or resolved by the procedure. A validation mode parameter allows the caller to exercise the logic without committing data.
• UPDATE_CONTRIBUTION_USAGE — Modifies an existing contribution usage record, allowing the effective dates, rate attributes, contribution codes, and related setup values to be changed while maintaining the object version number required for optimistic locking.
• DELETE_CONTRIBUTION_USAGE — Removes an existing contribution usage definition, identified by its contribution usage identifier and object version number, so that the record is no longer considered during payroll contribution processing.

Tables Accessed

The package operates against PAY_FR_CONTRIBUTION_USAGES, accessed through the APPS synonym. This is the single documented table referenced by the package. The create procedure queries existing rows in this table through an internal adjustment cursor (csr_adjust) that selects contribution usage identifiers and object version numbers where the group code, process type, element name, contribution usage type, and business group match, where date_to is null, and where the stored date_from precedes the incoming from-date. This lookup supports detection of a prior open-ended record that must be adjusted or superseded before the new contribution usage is inserted, preserving date-range integrity. The update and delete procedures write to and remove rows from the same table.

Usage Notes

PAY_CNU_API is intended for programmatic maintenance of contribution usage setup. It is typically invoked from Oracle Payroll configuration logic, from concurrent programs that load or migrate French contribution setup data, and from custom PL/SQL that must create, amend, or retire contribution usages without direct table manipulation. Direct DML against PAY_FR_CONTRIBUTION_USAGES is discouraged; the API supplies date-range handling, object version management, and validation that ad hoc SQL would otherwise duplicate. Callers should supply a meaningful effective date, observe the validation-only mode before committing, and retain the returned object version number for subsequent update or delete calls, since that value enforces optimistic locking. Because the package is referenced by another package and is not user-facing, it should be treated as a dependent interface whose signature must be preserved across patching.