Search Results get_account_type

Overview

OKS_QPATTRIB_PVT is a private (PVT) PL/SQL package body in the APPS schema that belongs to the Oracle Service (OKS) module family. Its name indicates that it supplies qualifying attribute values from service agreements and contracts to Oracle Advanced Pricing (QP) attribute mapping routines. In Oracle EBS 12.1.1 and 12.2.2, Oracle Pricing relies on attribute mapping to resolve source values from arbitrary business objects — here, service agreements held in the OKC tables — so that qualifiers, pricing rules, and modifier conditions can be evaluated against contract data. The package exposes a small set of accessor functions that return attributes such as account type, agreement name, GSA indicator, and party identifier for a given contract header identifier (p_chr_id).

The package is classified as PVT, meaning it is an internal implementation object rather than a published API. The header comment ("$Header: OKSRSQPB.pls 120.0 2005/05/25") shows it originated early in the 11i/12i release cycle and was deliberately shipped with "noship" in the header, underscoring its private status. Notably, although the package contains four documented functions, the source excerpt shows only GET_PARTY_ID carrying an active implementation; the other functions are stubs that return NULL, which is consistent with an extensibility placeholder pattern used throughout EBS pricing integration points.

Key Procedures and Functions

• GET_ACCOUNT_TYPE — Intended to return the customer profile class(es) associated with the contract's bill-to customer, expressed as a QP_ATTR_MAPPING_PUB.T_MULTIRECORD collection. In the delivered source the body is commented out and the function returns NULL, so no account-type qualifier value is produced.
• GET_AGREEMENT_NAME — Intended to return the service agreement name for the supplied contract header. The delivered implementation is a stub that returns NULL.
• GET_GSA — Intended to return the GSA (General Services Administration / government contract) indicator for the contract identified by p_chr_id. This is the function matching the user's search term. The delivered body contains only a NULL statement, so it returns no value in standard installations; customers requiring GSA qualification against service agreements must extend or replace this routine.
• GET_PARTY_ID — The only implemented function. It opens a cursor over OKC_K_PARTY_ROLES_B to retrieve the object1_id1 value for the row where chr_id equals p_chr_id and rle_code equals 'CUSTOMER', fetches a single row, closes the cursor, and returns the party identifier. All exceptions are trapped and NULL is returned.

Tables Accessed

The only documented table reference is OKC_K_PARTY_ROLES_B, accessed through an APPS synonym by GET_PARTY_ID. This table stores the party roles attached to contract headers and is the standard mechanism for identifying the customer on a service agreement. Additional tables appear in the commented-out GET_ACCOUNT_TYPE logic — HZ_CUST_SITE_USES_ALL, HZ_CUST_ACCT_SITES_ALL, OKC_K_HEADERS_B, and AR_CUSTOMER_PROFILES — but these are inactive in the shipped code and should not be relied upon. The package performs read-only access; no inserts, updates, or deletes are documented.

Usage Notes

Because OKS_QPATTRIB_PVT is a PVT package it is not intended for direct invocation by forms, concurrent programs, or customer code. It is referenced by two other packages, which invoke its functions as attribute-source callbacks during pricing attribute mapping for service agreements. In a typical EBS 12.1.1 or 12.2.2 configuration, Oracle Pricing evaluates a qualifier against a service contract; the mapping framework calls these functions to obtain candidate values such as the customer party ID. GET_PARTY_ID is the only function that yields data out of the box, which effectively limits delivered attribute mapping for service agreements to the customer party identifier.

Implementation projects that need agreement name, account type, or GSA qualification in pricing rules must supply custom logic, typically by layering a custom package over this one or by extending the attribute mapping definition. Any customization should preserve the documented signatures and be regression-tested after EBS patch application, since oracle-shipped stubs may be replaced during upgrades.