Search Results create_contract_grpngs




Overview

OKC_CONTRACT_GROUP_PVT is a private (PVT) PL/SQL package body in the Oracle E-Business Suite Contracts (OKC) module, owned by the APPS schema. In Oracle EBS 12.1.1 and 12.2.2, it provides the internal implementation layer for creating, maintaining, validating, and locking contract groups and the groupings that associate individual contracts with those groups. The package is the private counterpart to the public OKC_CONTRACT_GROUP API: the "PVT" classification indicates that its procedures are not intended for direct external invocation but are called internally by the public API wrapper, sibling private packages, and ETRM (Enterprise Trade and Relationship Management) components.

From a business standpoint, contract groups allow users to organize related contract documents into logical collections — for example, a portfolio of related agreements, a project-based grouping of contracts, or a master relationship spanning multiple instruments. OKC_CONTRACT_GROUP_PVT enforces the rules, defaulting, and referential integrity that keep those groupings consistent with underlying contract data. The body header carries the standard Oracle internal version marker ($Header: OKCCCGPB.pls 120.0), and a package-level debug flag is initialized from the AFLOG_ENABLED profile option, consistent with Oracle's standard diagnostics convention.

Key Procedures and Functions

The package exposes 28 documented procedures and functions, spanning several functional families:

As shown in the documented excerpt, CREATE_CTR_GROUP first calls create_contract_group, then walks the incoming grouping collection assigning the parent group ID to each row, and finally calls create_contract_grpngs. Return status from each stage is reconciled so that an unexpected error raises G_EXCEPTION_HALT_VALIDATION and halts processing, while a non-success status is preserved in a local variable and returned via x_return_status. Unexpected exceptions are trapped and converted into a standard message through OKC_API.set_message using the package's g_unexpected_error token.

Tables Accessed

The package operates against the following documented tables via APPS synonyms:

  • OKC_K_GROUPS_B — the base table storing contract group header records (group name, description, public flag, and related attributes). CREATE, UPDATE, DELETE, LOCK, and VALIDATE operations against the group record target this table.
  • OKC_K_GRPINGS — the intersection table holding the individual contract-to-group assignments (the groupings). CREATE_CONTRACT_GRPNGS, UPDATE_CONTRACT_GRPNGS, and DELETE_CONTRACT_GRPNGS read and write here.
  • PLITBLM — a PL/SQL index-by table used as the standard Oracle mechanism for returning accumulated error messages from the API layer. Its presence confirms the package follows Oracle's message-stack convention (populating x_msg_count and x_msg_data).

Usage Notes

Because OKC_CONTRACT_GROUP_PVT is a private package, it is not called directly from Oracle Forms or concurrent programs. Instead, the public OKC_CONTRACT_GROUP API and other OKC server-side code invoke it to perform the actual DML and validation work. The package is documented as referenced by two other packages, indicating it sits within a small calling hierarchy.

Typical invocation paths include:

  • Contract authoring forms and the OKC Contracts UI, which route create, update, delete, and lock requests through the public API into these private procedures.
  • Concurrent programs and batch loaders that bulk-create or maintain contract groups and groupings, again via the public API surface.
  • Custom integration code, which should always call the public OKC_CONTRACT_GROUP API rather than this private body. Developers who find create_contract_grpngs during trace or dependency analysis should treat it as an internal worker routine: it expects a valid initialized API context and a populated grouping collection, and its x_return_status values (success, expected error, unexpected error) should be interpreted using the standard OKC_API constants. Direct calls bypass supported interfaces and are not upgrade-safe across 12.1.1 and 12.2.2.