Results for “cs_sr_uwq_group_v”

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

Overview

The APPS.CS_SR_UWQ_GROUP_V view is a Service (CS) module database object that supports the Universal Work Queue (UWQ) in Oracle E-Business Suite 12.1.1 and 12.2.2. UWQ is the agent-facing framework that aggregates and routes work items to service representatives; this view supplies it with a consolidated snapshot of Service Requests (SRs) associated with the logged-in user or the user's group. Rather than requiring UWQ to assemble incident data from many normalized tables at runtime, CS_SR_UWQ_GROUP_V flattens the relevant attributes — status, severity, escalation, ownership, contact details, product information and coverage — into a single queryable structure. The documented status of the object is VALID in the APPS schema, and it is defined as a view over base tables and synonyms, meaning it is read-only by design and intended for reporting, UWQ display, and integration consumption rather than for direct DML.

Underlying Base Objects

The view's documented base objects span several EBS schemas exposed through APPS synonyms and views. Core Service Request data is drawn from CS_INCIDENTS_B_SEC, CS_INCIDENTS_ALL_TL, CS_INCIDENT_SEVERITIES_TL, CS_INCIDENT_STATUSES_B/TL, CS_INCIDENT_TYPES_TL and CS_INCIDENT_URGENCIES_TL. Owner and group assignment information comes from JTF_RS_GROUPS_TL, JTF_RS_RESOURCE_EXTNS_TL, JTF_TASKS_B, JTF_TASK_REFERENCES_B and JTF_OBJECTS_B. Party and contact details are resolved through HZ_PARTIES, HZ_LOCATIONS, HZ_PARTY_SITES and CS_HZ_SR_CONTACT_POINTS. Product and coverage data are joined from CSI_ITEM_INSTANCES, MTL_SYSTEM_ITEMS_KFV, OKS_COV_TYPES_B and OKS_COV_TYPES_TL — the latter providing contract and coverage type information. FND_GLOBAL, FND_USER, FND_LOOKUP_VALUES, CS_LOOKUPS, HR_LOCATIONS_ALL, PER_ALL_PEOPLE_F and PER_ALL_ASSIGNMENTS_F supply user session context, lookup meanings and personnel data. Because many of these are synonyms to remote or owner-schema objects, the view depends on the standard EBS synonym layer for cross-schema access.

Key Columns

The view exposes identity and descriptive columns such as INCIDENT_ID, INCIDENT_NUMBER, SUMMARY, SR_TYPE, CUSTOMER_TICKET_NUMBER and PROJECT_NUMBER. Status and severity are surfaced as both names and IDs through STATUS, SEVERITY, SERVERITY (a documented label retained for the severity name), INCIDENT_STATUS_ID, INCIDENT_SEVERITY_ID and INCIDENT_TYPE_ID, with ESCALATED and URGENCY indicating priority state. Ownership columns include OWNER_ID, OWNER (group name), OWNER_NAME, RESOURCE_TYPE and RESOURCE_ID. Contact and party data appear as PERSON_ORG, CONTACT_NAME, EMAIL_ADDRESS, CONTACT_ADDRESS, CONTACT_COUNTRY, CONTACT_TYPE and CONTACT_NUMBER. Coverage attributes are represented by COVERAGE_NAME, COVERAGE_LEVEL, COVERAGE_TYPE and PROBLEM_CODE/RESOLUTION_CODE. Date and audit columns include CREATION_DATE, MODIFIED_DATE, MODIFIED_BY, EXPECTED_RESOLUTION_DATE and OBLIGATION_DATE. The IEU_OBJECT_FUNCTION, IEU_OBJECT_PARAMETERS and IEU_PARAM_PK_VALUE columns support interaction and telephony integration, while a RANK() window function partitions by INCIDENT_ID to de-duplicate task-driven rows.

Common Use Cases and Queries

Typical usage includes UWQ queue population, agent dashboards, escalation monitoring and extraction of SR data into external reporting or integration layers. A representative query retrieves open, high-severity SRs for a group owner:

• SELECT incident_number, summary, status, severity, owner_name, expected_resolution_date FROM cs_sr_uwq_group_v WHERE status = 'Open' AND severity = 'High' ORDER BY creation_date DESC;
• SELECT incident_id, contact_name, coverage_name, coverage_type FROM cs_sr_uwq_group_v WHERE incident_country = 'US' AND coverage_level IS NOT NULL;
• SELECT owner, COUNT(*) FROM cs_sr_uwq_group_v WHERE escalated = 'Y' GROUP BY owner;

Note that the view applies RANK() partitioning to avoid returning multiple rows per incident when multiple tasks reference the same SR, so consumers should treat it as a current-state snapshot rather than a historical record. Because the base objects include the OKS_COV_TYPES_B and OKS_COV_TYPES_TL coverage tables, queries that surface COVERAGE_NAME and COVERAGE_TYPE effectively reflect the service contract coverage attached to the incident. All queries should be run with an appropriate APPS responsibility context so that FND_GLOBAL session variables resolve the logged-in user correctly.