Results for “resolution_code”

50+ results




Overview
Explore in AI Chat

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

Overview

CS_NEW_INCIDENTS_V_SEC is a secured database view owned by the APPS schema in Oracle E-Business Suite, belonging to the CS (Service) product family. It is defined directly on top of the view CS_NEW_INCIDENTS_V and exists to expose incident (service request) data to reporting and integration consumers while honoring Oracle EBS security semantics. The view is documented as VALID in both Release 12.1.1 and 12.2.2, and its structure and dependencies are consistent across those releases.

Functionally, the view flattens the key attributes of a service incident — codes, customer and contact context, product identification, ownership, and lifecycle dates — into a single denormalized row by joining to a set of code-translation, party, and item views. This makes it suitable for direct consumption by BI Publisher reports, Discoverer workbooks, OBIEE extracts, and custom concurrent programs without requiring the caller to reconstruct the multitudes of lookup joins manually. Because the view is a "secured" variant, it is the appropriate entry point for external consumers who should not be granted access to unsecured incident data.

Underlying Base Objects

CS_NEW_INCIDENTS_V_SEC selects from CS_INCIDENTS_B_SEC, the secured base view over the incidents entity, aliased INC. This is the driving row source for incident facts such as INCIDENT_ID, PROBLEM_CODE, RESOLUTION_CODE, INCIDENT_DATE, CLOSE_DATE, CUSTOMER_ID, and ACCOUNT_ID. From CS_INCIDENTS_ALL_TL (TL), aliased TL, it retrieves the language-specific SUMMARY, joined on INCIDENT_ID and filtered by TL.LANGUAGE = USERENV('LANG').

Descriptive attributes are resolved through lookup views: CS_INCIDENT_STATUSES_VL (STATUS.NAME as STATUS_CODE), CS_INCIDENT_TYPES_VL_SEC (TYPE.NAME as INCIDENT_TYPE), CS_INCIDENT_SEVERITIES_VL (SEV.NAME as SEVERITY), and CS_INCIDENT_URGENCIES_VL (URGENCY.NAME as URGENCY). Ownership is sourced from CS_SR_OWNERS_V (OWN.RESOURCE_NAME as OWNER), matched on both owner ID and resource type. Customer and contact context comes from JTF_PARTIES_ALL_V (PARTY.PARTY_NAME as COMPANY_NAME), JTF_CUST_ACCOUNTS_ALL_V (ACCOUNT.ACCOUNT_NUMBER), CSC_HZ_PARTIES_SELF_V, and CS_HZ_SR_CONTACT_POINTS, which together yield the contact first and last names. Product identification is supplied by MTL_SYSTEM_ITEMS_KFV (CONCATENATED_SEGMENTS as PRODUCT_NAME, DESCRIPTION as PRODUCT_DESCRIPTION), with the organization id resolved by a call to the CS_STD package function GET_ITEM_VALDN_ORGZN_ID.

Key Columns

  • INCIDENT_ID — primary identifier of the service incident; used for all joins and drill-through.
  • DATE_CLOSED — exposed from the base column CLOSE_DATE; the incident's closure date and the attribute most commonly searched for reporting on resolution timelines.
  • INCIDENT_DATE — date the incident was created.
  • STATUS_CODE, INCIDENT_TYPE, SEVERITY, URGENCY — decoded code names obtained from the VL lookup views.
  • OWNER — resource name of the current incident owner from CS_SR_OWNERS_V.
  • COMPANY_NAME, ACCOUNT, PERSON_FIRST_NAME, PERSON_LAST_NAME — customer, account, and contact identification.
  • PRODUCT_NAME, PRODUCT_DESCRIPTION — inventory item description joined via MTL_SYSTEM_ITEMS_KFV.
  • CURRENT_SERIAL_NUMBER_NV, PLATFORM_ID, PLATFORM_VERSION_ID — installed-base context for the affected product.
  • SUMMARY — language-specific incident summary text.

Common Use Cases and Queries

A frequent requirement is measuring how long incidents remain open. The DATE_CLOSED column supports this directly:

SELECT incident_id,
       incident_date,
       date_closed,
       TRUNC(date_closed) - TRUNC(incident_date) AS days_to_close,
       status_code,
       severity,
       owner
FROM   apps.cs_new_incidents_v_sec
WHERE  date_closed BETWEEN :p_from_date AND :p_to_date
ORDER  BY date_closed;

Another typical use is a status distribution by owner for a given period:

SELECT owner,
       status_code,
       COUNT(*) AS incident_count
FROM   apps.cs_new_incidents_v_sec
WHERE  incident_date >= :p_from_date
GROUP  BY owner, status_code;

A third is a customer-facing open incident list:

SELECT incident_id,
       company_name,
       person_first_name,
       person_last_name,
       product_name,
       severity,
       incident_date
FROM   apps.cs_new_incidents_v_sec
WHERE  date_closed IS NULL
ORDER  BY incident_date;

Because the view applies the secured base and validated language joins, queries run against it automatically inherit the caller's EBS responsibility-level security and return only data the user is entitled to see.