Search Results pos_bus_class_request_n1

Overview

POS.POS_BUS_CLASS_REQS is a transaction table in the Oracle EBS Procurement subsystem (POS schema) that stores business classification requests raised against suppliers. A business classification identifies attributes such as minority group status, small business designations, or certification credentials that qualify a supplier for particular sourcing or contracting programs. Each row in this table represents a discrete request to add, update, or remove a classification on an existing supplier mapping, and it records both the request metadata and the resulting classification attribute values.

The table resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10, which is typical for transactional data subject to updates. Under the heuristic Data Vault classification inferred from the foreign key structure, this table is modeled as a link — it associates a supplier mapping (POS_SUPPLIER_MAPPINGS) with a classification definition (POS_BUS_CLASS_ATTR). This is a modeling suggestion rather than a declared architectural fact; the table also carries descriptive attributes (certification details, status, type), which in a strict Data Vault design would be split into a separate satellite.

Key Information Stored

The table contains 16 documented columns. The surrogate primary key is BUS_CLASS_REQUEST_ID, a NUMBER populated by sequence and enforced through the unique index POS_BUS_CLASS_REQUEST_U1 on APPS_TS_TX_IDX. This same column is the only documented unique index, making it the sole business-key candidate; all other indexes are non-unique and support query performance rather than row identity.

The most significant columns are:

• MAPPING_ID — foreign key to POS_SUPPLIER_MAPPINGS identifying the supplier mapping the request applies to.
• CLASSIFICATION_ID — foreign key to POS_BUS_CLASS_ATTR identifying the supplier business classification being added, changed, or removed.
• REQUEST_TYPE — VARCHAR2(30) indicating the nature of the request (for example, add, update, or remove).
• REQUEST_STATUS — VARCHAR2(30) tracking the workflow state of the request.
• LOOKUP_TYPE and LOOKUP_CODE — the lookup category and value used to describe the classification.
• EXT_ATTR_1 — VARCHAR2(240) currently storing a minority group code.
• CERTIFICATION_NO, CERTIFICATION_AGENCY, EXPIRATION_DATE — certification identifiers, issuing agency, and validity end date.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard Who columns for audit and concurrency.

Three non-unique indexes accelerate access: POS_BUS_CLASS_REQUEST_N1 on MAPPING_ID, N2 on REQUEST_TYPE, and N3 on REQUEST_STATUS.

Common Use Cases and Queries

Typical use cases include supplier diversity reporting, audit of certification validity, and reconciliation of pending classification changes. A frequent pattern joins the table to its parent mappings and classification definitions:

SELECT r.BUS_CLASS_REQUEST_ID, r.REQUEST_TYPE, r.REQUEST_STATUS,
       r.CERTIFICATION_NO, r.EXPIRATION_DATE
FROM   POS.POS_BUS_CLASS_REQS r
WHERE  r.MAPPING_ID = :mapping_id
AND    r.REQUEST_STATUS = 'PENDING';

Reporting queries commonly filter on REQUEST_TYPE or REQUEST_STATUS (both indexed) and on EXPIRATION_DATE to surface expired or soon-to-expire certifications. Aggregation by LOOKUP_CODE or EXT_ATTR_1 supports minority group and classification spend analysis. Because the Who columns are present, change tracking over time is straightforward, though no delete or versioning columns are documented, so history must be inferred from status transitions.

Related Objects

The following objects are most significant to POS_BUS_CLASS_REQS:

• POS.POS_SUPPLIER_MAPPINGS — joined on MAPPING_ID; provides the supplier mapping context.
• POS.POS_BUS_CLASS_ATTR — joined on CLASSIFICATION_ID; supplies the classification attribute definition.
• POS_BUS_CLASS_REQUEST_PK — primary key constraint on BUS_CLASS_REQUEST_ID.
• POS_BUS_CLASS_REQUEST_U1 — unique index on BUS_CLASS_REQUEST_ID (the business-key candidate).
• POS_BUS_CLASS_REQUEST_N1 / N2 / N3 — non-unique performance indexes on MAPPING_ID, REQUEST_TYPE, and REQUEST_STATUS respectively.
• FND_LOOKUPS — referenced implicitly through LOOKUP_TYPE and LOOKUP_CODE.
• Supplier classification workflow / approval APIs — consume REQUEST_STATUS and REQUEST_TYPE to drive processing.

Together these objects allow reporting on supplier classification requests and their certification outcomes across the procurement lifecycle.