Search Results pa_alloc_rules_s

Overview

The APPS.PA_ALLOC_COPY_RULE_PKG package body supports the Oracle Projects (PA) allocation engine by providing the logic required to duplicate an existing allocation rule into a new rule definition. Allocation rules in Oracle Projects define how source amounts (for example, pool costs, budget balances, or resource list values) are distributed across target expenditure types, organizations, cost types, or projects. Rather than forcing users to recreate a complex rule manually, this package allows a complete rule — including its source, basis, target, offset, and descriptive flexfield attributes — to be copied and assigned a new name and description.

The header comment identifies the file as PAXALCRB.pls 120.2, dated 2005, indicating the package has been stable across the 12.1.1 and 12.2.2 release lines. The package is classified as OTHER in the ETRM API registry, meaning it is an internal implementation utility rather than a formally published public API. It is referenced by zero other packages, which confirms it is a leaf-level component invoked directly from the calling layer rather than reused programmatically elsewhere.

Key Procedures and Functions

The package exposes a single documented procedure:

• COPY_RULE — Performs the rule duplication. It accepts an input rule identifier, a destination rule name, and a destination description, and returns a completion code and error buffer through its x_retcode and x_errbuf out parameters. This standardized retcode/errbuf signature follows the Oracle concurrent program convention, indicating the procedure is designed to be executed as a concurrent program or from a host PL/SQL block that reports status back to the request framework.

Internally, COPY_RULE declares a cursor over PA_ALLOC_RULES_ALL that selects the full attribute set of the source rule using SELECT ... FOR UPDATE OF rule_name. The FOR UPDATE clause locks the source row to prevent concurrent modification during the copy. Note that CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN are explicitly commented out of the select list — the copy deliberately omits WHO columns so that the target row receives fresh audit values on insert. This is directly relevant to users searching for g_created_by: the package does not reference a global g_created_by variable in the documented excerpt; audit columns are instead populated by the standard FND_STANDARD/WHO column mechanism at insert time.

A second private cursor, Is_Rbs_Valid, validates a row-based security (RBS) header against PA_RBS_HEADERS_V, confirming that the resource list and RBS version attributes carried on the rule point to a currently valid security definition before the copy proceeds.

Tables Accessed

• PA_ALLOC_RULES_ALL — The primary multi-org table holding allocation rule headers and their source, basis, target, and offset attributes. Read for the source row and written for the new copied row.
• PA_ALLOC_RULES_S — The security (org-striped) view/table used during insert to enforce operating unit access.
• PA_ALLOC_RESOURCES and PA_ALLOC_GL_LINES — Hold the resource and general ledger line detail associated with a rule; copied alongside the header so the new rule reproduces the same distribution behavior.
• PA_ALLOC_SOURCE_LINES and PA_ALLOC_TARGET_LINES — Source and target line detail for the allocation definition.
• PA_BUDGET_TYPES — Validates the budget type referenced by the basis or budget entry method attribute.

Usage Notes

This package is typically invoked from the Allocation Rules maintenance form in Oracle Projects, where the Copy action passes the source rule ID, the new name, and the new description. It may also be scheduled as a concurrent program because of its x_retcode/x_errbuf signature. In 12.1.1 and 12.2.2 the package is unchanged, so customizations that call it should treat the interface as stable but internal; Oracle does not guarantee backward compatibility on OTHER-classified packages. The procedure acquires a row lock on the source rule, so concurrent copies of the same rule will serialize, and callers should supply unique target rule names to avoid unique-key violations on PA_ALLOC_RULES_ALL.