Search Results xnc_cs_sr_task_map




Overview
Explore in AI Chat

Overview

The table XNC_CS_SR_TASK_MAP is a data object within the now-obsolete Oracle E-Business Suite module, Sales for Communications (XNC). Its primary function was to establish and maintain a mapping relationship between Service Request (SR) incident types and predefined task template groups. This mapping was a critical configuration element for automating service delivery processes. When a service request of a specific incident type was logged, the system could reference this table to automatically generate a standardized set of tasks from the associated template group, ensuring consistent process execution and reducing manual setup. The provided ETRM metadata explicitly notes that this table was "Not implemented in this database," indicating it may have been a planned component that was never fully deployed in standard instances of EBS 12.1.1 or 12.2.2.

Key Information Stored

The table's structure centers on linking two key identifiers and managing the validity of that linkage. The primary columns, as indicated by its foreign key relationships, are INCIDENT_TYPE_ID and TASK_TEMPLATE_GROUP_ID. These columns store the foreign keys to the CS_INCIDENT_TYPES_B and JTF_TASK_TEMP_GROUPS_B tables, respectively. The table includes a START_DATE_ACTIVE column, which was used to control the effective date of the mapping. The presence of this column suggests the design supported time-dependent mappings, allowing configurations to become active or inactive on specific dates. The table's primary identifier is the surrogate key SR_TASK_MAP_ID, while a unique key constraint on INCIDENT_TYPE_ID and START_DATE_ACTIVE was likely intended to prevent duplicate active mappings for a single incident type.

Common Use Cases and Queries

The central use case was the automated generation of task checklists for new service requests. A typical operational query would retrieve the active task template group for a given incident type to initiate task creation. For configuration and reporting purposes, administrators would query the map to audit or modify process linkages. Given the table's unimplemented status, these queries would not return data in a standard environment.

  • Retrieve Active Mapping: SELECT task_template_group_id FROM xnc_cs_sr_task_map WHERE incident_type_id = :p_inc_type AND start_date_active <= SYSDATE ORDER BY start_date_active DESC;
  • Audit All Configurations: SELECT m.incident_type_id, t.name incident_type, m.task_template_group_id, g.name template_group, m.start_date_active FROM xnc_cs_sr_task_map m, cs_incident_types_b t, jtf_task_temp_groups_b g WHERE m.incident_type_id = t.incident_type_id AND m.task_template_group_id = g.task_template_group_id;

Related Objects

This table sits at the intersection of Service Request management and Task management modules. Its defined foreign keys explicitly tie it to two fundamental base tables:

  • CS_INCIDENT_TYPES_B: This table stores the definition of service request incident types (categories). The foreign key ensures that mappings can only be created for valid, predefined incident types.
  • JTF_TASK_TEMP_GROUPS_B: This table stores the definitions of task template groups, which are collections of standard task templates. The foreign key ensures the mapped template group is valid.

Given its purpose, any custom or module-specific logic for auto-creating tasks from service requests would have been dependent on this mapping table, likely invoked from procedures within the Service Request or XNC application tiers.