Search Results product_descripition

Overview

CS_BRM_3D_SERVICE_REQUEST_V is an APPS-owned database view within the Oracle E-Business Suite Service (CS) module. Its description identifies it as the "3D Service Request View used by the Business Rule Monitor." The view exposes a consolidated, denormalized projection of service request (incident) data, including status, type, urgency, severity, ownership, customer, and product attributes, joined to descriptive translation tables so that human-readable names accompany the underlying identifier columns.

A defining characteristic of this view is its RECORD_STATUS column, which is hard-coded to the literal value 'HISTORIC'. This signals that the view is designed to return historical or audited versions of service request records rather than the live transactional rows. It draws its "current-state" measurements from audit columns (prefixed OLD_) on the CS_INCIDENTS_AUDIT_B table, effectively reconstructing the state of a service request as captured in the audit trail. The companion OBJECT_TYPE column is likewise a constant, set to 'CS_BRM_3D_SERVICE_REQUEST_V', giving downstream consumers a stable literal tag for the source object. The view is implemented in APPS and carries VALID status in the ETRM metadata, indicating it is a supported and active dictionary object in both 12.1.1 and 12.2.2.

Underlying Base Objects

The view text joins a set of incident, audit, reference, party, and product tables, most referenced through APPS synonyms:

• CS_INCIDENTS_B_SEC (VIEW) — supplies the secure incident base row, including customer linkage (CUSTOMER_ID).
• CS_INCIDENTS_AUDIT_B (SYNONYM) — the audit history table that drives the view, providing OLD_INCIDENT_* columns used as the effective status, type, urgency, severity, owner, and date values.
• CS_INCIDENT_STATUSES_TL, CS_INCIDENT_TYPES_TL, CS_INCIDENT_URGENCIES_TL, CS_INCIDENT_SEVERITIES_TL (SYNONYMS) — translation (TL) tables supplying the NAME values for each coded attribute, joined with an outer join on LANGUAGE = USERENV('LANG').
• PER_PEOPLE_F (VIEW), JTF_RS_RESOURCE_EXTNS (SYNONYM) — resolve the incident owner to a person and resource record (FULL_NAME).
• HZ_PARTIES, HZ_CUST_ACCOUNTS (SYNONYMS) — provide company name (PARTY_NAME) and account number.
• MTL_SYSTEM_ITEMS_VL (VIEW) — supplies concatenated segments and description for the customer product.
• Documented packaged dependencies include HR_GENERAL, HR_PERSON_NAME, HR_SECURITY, which support name formatting and row-level security.

Key Columns

• RECORD_STATUS — constant 'HISTORIC'; the searched column, confirming audited/historic context.
• OBJECT_TYPE / OBJECT_ID — constant type tag and the incident identifier.
• INCIDENT_ID — the service request primary key.
• INCIDENT_STATUS_ID / INCIDENT_STATUS_NAME — status code and translated name.
• INCIDENT_TYPE_ID / INCIDENT_TYPE_NAME, INCIDENT_URGENCY_ID / _NAME, INCIDENT_SEVERITY_ID / _NAME — coded classification and descriptions.
• INCIDENT_OWNER_ID / INCIDENT_OWNER_NAME — assigned resource and full name.
• INCIDENT_DATE, EXPECTED_RESOLUTION_DATE, OBLIGATION_DATE, CLOSE_DATE — key service-level dates.
• CUSTOMER_ID, COMPANY_NAME, ACCOUNT_NUMBER — customer and account context.
• CUSTOMER_PRODUCT_ID, PRODUCT_NAME, PRODUCT_DESCRIPITION — item instance and product details (note the documented spelling of the last column).
• CREATED_BY, CREATION_DATE, LAST_UPDATE_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — auditing/WHO columns.

Common Use Cases and Queries

Typical consumers include Business Rule Monitor logic, service-analytics reports, and integration extracts that require the historical progression of service requests. The constant RECORD_STATUS allows a caller to filter or label rows as historic without inspecting underlying audit tables.

• Query historical incidents for a given customer: SELECT INCIDENT_ID, INCIDENT_STATUS_NAME, RECORD_STATUS FROM CS_BRM_3D_SERVICE_REQUEST_V WHERE CUSTOMER_ID = :p_customer_id;
• Report aging by status: SELECT INCIDENT_STATUS_NAME, COUNT(*) FROM CS_BRM_3D_SERVICE_REQUEST_V WHERE RECORD_STATUS = 'HISTORIC' GROUP BY INCIDENT_STATUS_NAME;
• Filter by owner and date: SELECT INCIDENT_ID, INCIDENT_OWNER_NAME, INCIDENT_DATE FROM CS_BRM_3D_SERVICE_REQUEST_V WHERE INCIDENT_OWNER_ID = :p_owner AND INCIDENT_DATE >= :p_from_date;

Because RECORD_STATUS is a literal, it should be treated as an informational discriminator rather than a variable filter value, and joins to the audit base table should be preserved to maintain historical fidelity.