Search Results resolution_description




Overview
Explore in AI Chat

Overview

BIC_SERVICE_REQUEST_DETAIL_V is a reporting view historically catalogued under the BIC – Customer Intelligence product family, which is now marked obsolete in Oracle EBS. The view consolidates service request (incident) header data from Oracle Service with lookup-based decode information, presenting a flattened, read-only result set suitable for downstream reporting, extracts, and integration staging. The view surfaces the incident's problem code together with its translated meaning, and likewise exposes the resolution code and its meaning, so that report consumers do not need to join to lookup tables themselves. The view is defined with the WITH READ ONLY clause, which prevents DML against the view and enforces its role as a query-only presentation layer.

The ETRM metadata records the object as "Not implemented in this database," meaning that although the definition is documented, the database instance in question does not physically contain the view. Report design and integration mapping should therefore verify object existence before dependency is assumed.

Underlying Base Objects

The documented view text derives from three base objects:

Both lookup joins are outer joins (indicated by the (+) syntax), so incidents with null or unmapped problem and resolution codes are retained with null descriptions. The ETRM metadata documents "Referenced base objects: none documented," so the authoritative join relationships are best read directly from the view text reproduced above.

Key Columns

The view exposes twelve columns:

  • INCIDENT_ID — primary identifier of the service request/incident.
  • CUSTOMER_ID — customer identifier associated with the incident.
  • CUST_ACCOUNT_ID (from INA.ACCOUNT_ID) — the customer account identifier.
  • SR_NUMBER (from INA.INCIDENT_NUMBER) — the user-facing service request number.
  • CREATION_DATE (from INA.INCIDENT_DATE) — the date the incident was raised.
  • CLOSE_DATE and LAST_UPDATE_DATE — closure and audit timestamps.
  • CURRENT_CONTACT_NAME — hard-coded as NULL; a placeholder column carried for interface uniformity.
  • PROBLEM_CODE and PROBLEM_DESCRIPTION — the raw problem code and its lookup meaning (CLP.MEANING); this is the pairing most relevant to a problem_description search.
  • RESOLUTION_CODE and RESOLUTION_DESCRIPTION — the resolution code and its lookup meaning (CLR.MEANING).

Common Use Cases and Queries

Typical uses include service request aging reports, problem/resolution categorization extracts, and data feeds into customer intelligence or data warehouse layers. Because CURRENT_CONTACT_NAME is always null, consumers needing contact information must source it elsewhere.

To return problem descriptions for a set of service requests:

  • SELECT SR_NUMBER, PROBLEM_CODE, PROBLEM_DESCRIPTION FROM BIC_SERVICE_REQUEST_DETAIL_V WHERE PROBLEM_DESCRIPTION IS NOT NULL;
  • SELECT SR_NUMBER, CREATION_DATE, PROBLEM_DESCRIPTION, RESOLUTION_DESCRIPTION FROM BIC_SERVICE_REQUEST_DETAIL_V WHERE CREATION_DATE BETWEEN :from_date AND :to_date ORDER BY CREATION_DATE;

Given the "not implemented" status and the obsolete BIC product classification, always confirm the view exists (for example, via ALL_VIEWS) or substitute equivalent queries against CS_INCIDENTS_ALL_B joined to CS_LOOKUPS directly.