Results for “tp_attribute_category”

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

Overview

QPBV_AGREEMENTS is a PL/SQL view owned by the APPS schema in Oracle E-Business Suite, defined within the Oracle Advanced Pricing (QP) product family. It exposes header-level information about pricing and sales agreements maintained in the Oracle Order Management repository, presenting the internal agreement identifier, pricing and rules configuration, contact and sales representative assignments, effective dating, and descriptive name attributes in a single queryable form. The view is registered as VALID in both 12.1.1 and 12.2.2, and because it is owned by APPS it is typically granted to reporting and integration responsibilities that require a simplified, read-only presentation of agreement data.

The "BV" naming convention indicates a business view used primarily for inquiry, reporting, and downstream integration rather than for direct DML. It abstracts the base/tables translation table join pattern required by the multi-language architecture, so a consumer does not need to explicitly join the translation table or supply the language predicate.

Underlying Base Objects

The view is defined over two documented synonyms in APPS: OE_AGREEMENTS_B, the base (transaction) table that stores agreement header records, and OE_AGREEMENTS_TL, the translation table that stores the language-dependent agreement name. The join is performed on AGREEMENT_ID, with the language predicate TL.LANGUAGE = USERENV('LANG') restricting the result to the session language.

• OE_AGREEMENTS_B — source of all operational columns including keys, flags, dates, and identifiers.
• OE_AGREEMENTS_TL — source of the NAME column, aliased in the view as AGR_NAME.

Key Columns

The query relevant to the user's search term, agreement_contact_id, is exposed directly as a column on this view. Notable columns include:

• AGREEMENT_ID — primary identifier linking header and translation rows; the primary join key.
• NAME (base table) and AGR_NAME (translation) — the agreement name; AGR_NAME is the language-resolved value returned by the view.
• AGREEMENT_NUM, REVISION, REVISION_DATE, REVISION_REASON_CODE — revision-tracking attributes.
• AGREEMENT_CONTACT_ID and INVOICE_CONTACT_ID — contact references for the agreement and the invoice contact respectively.
• SALESREP_ID — the assigned sales representative.
• PRICE_LIST_ID, TERM_ID, INVOICING_RULE_ID, ACCOUNTING_RULE_ID — pricing, payment term, and rule references.
• OVERRIDE_IRULE_FLAG, OVERRIDE_ARULE_FLAG — flags indicating whether invoicing or accounting rules are overridden.
• SIGNATURE_DATE, START_DATE_ACTIVE, END_DATE_ACTIVE — key dates governing agreement validity.
• INVOICE_TO_ORG_ID, SOLD_TO_ORG_ID — customer organization references.
• AGREEMENT_TYPE_CODE, FREIGHT_TERMS_CODE, SHIP_METHOD_CODE, PURCHASE_ORDER_NUM — commercial attributes.
• TP_ATTRIBUTE_CATEGORY and the standard WHO columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY) — descriptive flexfield context and audit information.

Common Use Cases and Queries

Typical uses include resolving the contact assigned to an agreement, reporting active agreements by date window, and joining agreements to price lists or sales representatives. Because the view already applies the language predicate, queries need not reference OE_AGREEMENTS_TL directly.

SELECT agreement_id,
       agreement_num,
       agr_name,
       agreement_contact_id,
       salesrep_id,
       start_date_active,
       end_date_active
FROM   apps.qpbv_agreements
WHERE  agreement_contact_id IS NOT NULL;

Filtering for currently effective agreements by contact:

SELECT agreement_num, agr_name, revision
FROM   apps.qpbv_agreements
WHERE  agreement_contact_id = :p_contact_id
AND    TRUNC(SYSDATE) BETWEEN start_date_active
                          AND NVL(end_date_active, TRUNC(SYSDATE));

Because QPBV_AGREEMENTS is a view over OE_AGREEMENTS_B and OE_AGREEMENTS_TL, it is read-only; agreement maintenance must be performed through the Advanced Pricing and Order Management forms or the corresponding base-table APIs. For integration extracts, the AGREEMENT_ID should be carried as the stable key, with AGR_NAME used only for display.