Results for “pa_rbs_versions_pkg”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

APPS.PA_RBS_VERSIONS_PKG is the PL/SQL package body that provides the low-level data access and maintenance logic for the Resource Breakdown Structure (RBS) Versions entity within Oracle Projects. An RBS version defines a named, versioned hierarchy of resource classifications used to organize, group, and report on project resources such as people, organizations, and roles. Because resource assignments, budgeting, and reporting must remain tied to a specific RBS definition, versioning is essential: it preserves a historical, auditable structure while allowing new versions to be created as the breakdown evolves.

The package is a private implementation companion to an application programming interface. It encapsulates the DML operations required to manage RBS version rows in the multilanguage-enabled database schema, and it is classified as OTHER within the ETRM metadata, indicating that it is an internal utility API rather than a documented public interface intended for direct customer use. Its status is VALID, confirming that it compiles cleanly and that its dependent objects resolve correctly.

Key Procedures and Functions

The ETRM metadata documents four procedures in the package body:

• INSERT_ROW — Creates a new RBS version record. It inserts the base (non-translatable) information into the _B table and the translatable name/description attributes into the _TL table, thereby establishing a complete, language-aware version definition.
• UPDATE_ROW — Modifies an existing RBS version. It applies changes to the base record and, where language-dependent attributes are affected, to the corresponding translated row.
• DELETE_ROW — Removes an RBS version from the schema. It provides the controlled deletion path for version records, deleting the associated base and translation rows.
• ADD_LANGUAGE — Inserts translation rows for a new or additional installed language. This supports the Oracle EBS multilanguage model by propagating a version’s translatable attributes to languages that were not previously populated.

No parameter signatures are published in the ETRM documentation; the procedures should be invoked only through their supported callers, not by ad hoc direct calls.

Tables Accessed

The package references the following objects, resolved through APPS synonyms:

• PA_RBS_VERSIONS_B — the base table holding non-translatable RBS version attributes. Written by INSERT_ROW and UPDATE_ROW, and read during maintenance operations.
• PA_RBS_VERSIONS_TL — the translation table holding language-specific name and description values. Written by INSERT_ROW, UPDATE_ROW, and ADD_LANGUAGE.
• PA_RBS_VERSIONS_S — the sequence used to generate unique surrogate keys for new version rows created by INSERT_ROW.
• FND_LANGUAGES — the Oracle Application Object Library language definitions, queried by ADD_LANGUAGE to determine which installed languages require translation rows.
• DUAL — the standard single-row utility table, used for sequence and singleton queries.

The package itself also appears in its own dependency list, reflecting internal self-reference, and the metadata notes that PA_RBS_VERSIONS_PKG is not referenced by any database object while referencing the tables above.

Usage Notes

PA_RBS_VERSIONS_PKG is an internal repository-layer package invoked by Oracle Projects forms, concurrent programs, and higher-level public APIs that manage resource breakdown structures. Typical invocations occur when a user defines, maintains, or retires an RBS version through the Projects responsibility, or when the system installs an additional language and must backfill translations. The documented procedures are not intended for direct invocation from custom code; developers should use the supported public APIs instead. The metadata notes the package is referenced by one other package, so changes to its logic can propagate to that dependent program unit. As with all APPS schema objects, it must not be altered, and any extension should be implemented in a separate custom schema.