Results for “cs_incident_statuses”

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

Overview

The view BIC_FCTV_SR_REWORKED belongs to the Oracle EBS BIC – Customer Intelligence product family, a module now classified as obsolete in the ETRM reference library. The view materializes a fact-style dataset describing service requests (incidents) that have been re-worked — that is, incidents that were previously marked closed and subsequently reopened or transitioned back into a non-closed status. It is designed for use by the Customer Intelligence analytics and data-warehouse layer, where dimensional views such as BIC_DIMV_TIME and BIC_DIMV_CUSTOMERS supply the surrounding time and customer dimensions.

The view is documented as not implemented in the current database, meaning it exists as a legacy artefact carried forward in the ETRM metadata for Oracle EBS 12.1.1 and 12.2.2 but is not deployed in a standard installation. Its role in reporting/integration is analytical: it exposes the population of reopened service requests, qualified by period, severity, type, owner and customer, for use in contact-centre performance and rework-rate reporting.

Underlying Base Objects

Although the ETRM 12.2.2 record lists no owner and no formally documented referenced base objects, the view definition itself reveals the following sources:

• CS_INCIDENTS_ALL_B — the base incidents table, aliased INC.
• CS_INCIDENTS_AUDIT — the incident audit/status-history table, aliased INCA; the join on INCA.INCIDENT_STATUS_ID = INCA.OLD_INCIDENT_STATUS_ID captures status transitions.
• CS_INCIDENT_STATUSES — joined twice (STAT and STAT1) to compare the current status against the prior (closed) status.
• CS_INCIDENT_SEVERITIES — aliased ISEV, for severity name and description.
• CS_INCIDENT_TYPES — aliased ITYP, for incident type name and description.
• BIC_DIMV_TIME (DT) — the time dimension supplying period and calendar attributes.
• BIC_DIMV_CUSTOMERS (DC) — the customer dimension supplying party, geography and segmentation.
• JTF_RS_RESOURCE_EXTNS (PF) — outer-joined for the resource/owner extension, though the owner name columns are selected as NULL.

The view is created WITH READ ONLY, so it is strictly a query object.

Key Columns

• INCIDENT_ID — primary identifier of the service request.
• CLOSE_FLAG / CLOSE_FLAG1 — the pivotal columns for this view's business rule. CLOSE_FLAG comes from the current status and is filtered to != 'Y'; CLOSE_FLAG1 comes from the old status and is filtered to = 'Y'. Together they isolate reworked (reopened) incidents.
• INCIDENT_OWNER_FK, INCIDENT_STATUS_FK, INCIDENT_SEVERITY_FK, INCIDENT_TYPE_FK — foreign keys to the owner, status, severity and type dimensions.
• INCIDENT_DATE, CLOSE_DATE — creation and closure timestamps.
• INCIDENT_SEVERITY, SEVERITY_DESC, INCIDENT_TYPE, INC_TYPE_DESC — descriptive attributes.
• PARTY_ID, COUNTRY, CITY, STATE, CUSTOMER_CATEGORY_FK, MARKET_SEGMENT_FK — customer dimension attributes.
• ACT_PERIOD_NAME, START_DATE, ACT_PERIOD_START_DATE, ACT_PERIOD_END_DATE, ACT_YEAR, ACT_PERIOD_NUM, ACT_QUARTER, ACT_HALF_YEAR, ACT_YEAR_START_DATE, ACT_QUARTER_START_DATE — time dimension attributes used to bucket reworks by fiscal period.
• LAST_NAME, FIRST_NAME, EMPLOYEE_NAME — exposed as NULL placeholders.

Common Use Cases and Queries

The view supports rework-rate analysis: measuring how often closed service requests are reopened, by period, severity, type, owner or customer segment. A typical query filters on the close-flag pair and aggregates by fiscal period:

SELECT act_period_name, incident_severity, COUNT(*) reworked_cnt
FROM   bic_fctv_sr_reworked
WHERE  close_flag  != 'Y'
AND    close_flag1  = 'Y'
GROUP  BY act_period_name, incident_severity
ORDER  BY act_period_name;

A second scenario joins the customer attributes to identify segments with elevated rework rates:

SELECT customer_category_fk, country, COUNT(*) cnt
FROM   bic_fctv_sr_reworked
GROUP  BY customer_category_fk, country;

Because the view is not implemented in the database and BIC – Customer Intelligence is obsolete, current implementations should treat it as reference material only; equivalent functionality is typically reproduced by querying CS_INCIDENTS_AUDIT directly against CS_INCIDENT_STATUSES.CLOSE_FLAG.