Results for “as_pe_int_categories_v”

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

Overview

AS_PE_INT_CATEGORIES_V is an Oracle E-Business Suite view owned by the APPS schema and delivered within the AS – Sales Foundation product family. Its status is documented as VALID in ETRM, and the object is classified as a VIEW. The view exposes configuration data that associates quota records with interest-type and interest-code definitions, and it surfaces a column named MAPPING_TYPE that governs how those associations are classified. Because the Sales Foundation module underpins Oracle Advanced Pricing, Trade Management, and related sales compensation functionality, this view acts as a read-only reporting and integration surface over the underlying interest-category setup. Integrators and report authors typically use it to resolve the numeric foreign keys stored on transactional tables into meaningful interest-category context, without querying the base table directly.

Underlying Base Objects

The view is defined over the base object AS_PE_INT_CATEGORIES, which is referenced through a synonym in the APPS schema. The view text is a straightforward projection of the base table: it selects PE_INT_CATEGORY_ID, the standard WHO audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN), the concurrent-program columns (REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE), QUOTA_ID, MAPPING_TYPE, INTEREST_TYPE_ID, PRI_INTEREST_CODE_ID, SEC_INTEREST_CODE_ID, and a literal NULL placeholder in the position that the base table fills with SECURITY_GROUP_ID. The columns listed in the ETRM column dictionary are therefore PE_INT_CATEGORY_ID, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, QUOTA_ID, MAPPING_TYPE, INTEREST_TYPE_ID, PRI_INTEREST_CODE_ID, SEC_INTEREST_CODE_ID, and SECURITY_GROUP_ID. Because the view adds no joins or filters, row-level security is effectively flattened: the SECURITY_GROUP_ID value is masked as NULL, which is significant for multi-org or secured implementations.

Key Columns

• PE_INT_CATEGORY_ID – Primary identifier for the interest-category row; used as the join key from dependent transaction tables.
• QUOTA_ID – References the quota record to which the interest category applies.
• MAPPING_TYPE – Classifies the nature of the mapping between the quota and the interest definitions; this is the attribute most frequently searched by implementers when diagnosing how interest categories are resolved.
• INTEREST_TYPE_ID – Foreign key to the interest-type definition governing the category.
• PRI_INTEREST_CODE_ID – Primary interest code associated with the category.
• SEC_INTEREST_CODE_ID – Secondary interest code, where a two-tier code structure is configured.
• WHO and concurrent-program columns – Provide audit lineage and identify the concurrent request that last modified the row.
• SECURITY_GROUP_ID – Returned as NULL by the view definition, so security-group filtering must be handled elsewhere.

Common Use Cases and Queries

The view is most often queried to translate stored identifiers into descriptive reporting output and to audit the distribution of MAPPING_TYPE values across quotas. A typical lookup retrieves all categories for a given quota or interest type.

SELECT pe_int_category_id, quota_id, mapping_type, interest_type_id, pri_interest_code_id, sec_interest_code_id FROM apps.as_pe_int_categories_v WHERE quota_id = :p_quota_id;

Analysts auditing configuration commonly aggregate by mapping type to detect unbalanced or unexpected setups:

SELECT mapping_type, COUNT(*) FROM apps.as_pe_int_categories_v GROUP BY mapping_type;

Integration routines join the view to quota and interest-code reference objects to build interface extracts, using PE_INT_CATEGORY_ID as the stable key. Because SECURITY_GROUP_ID is nulled, queries intended for secured environments should join back to the base table or apply an appropriate organization filter. All access should be granted through the APPS synonym, and the view should be treated as read-only.