Search Results comp_name_range

Overview

CS_SR_TERRITORY_V is a reporting view owned by the APPS schema in the Oracle E-Business Suite Service (CS) module. Its documentation states that it "shows information about Service Request, and this is being used by Territory Management." In practical terms, the view flattens a Service Request (SR) together with the customer, party, location, contact, and organization attributes that Territory Management requires in order to evaluate territory assignment rules. Territory Management in Oracle Service relies on attributes such as country, state, city, postal code, phone area code, employee head count, and party name to determine which territory an SR belongs to, and CS_SR_TERRITORY_V exposes exactly those attributes in a single, denormalized row per SR.

Because the view joins the transactional SR header data with the TCA (Trading Community Architecture) model, it is used in both internal territory resolution logic and in custom reporting. A user searching for service_request_id will find that this key is exposed at the top of the column list as SERVICE_REQUEST_ID, which is the alias for CS_INCIDENTS_ALL_B.INCIDENT_ID. This makes the view a convenient entry point for queries that need to correlate an SR with the geography and organization profile of the reporting party.

Underlying Base Objects

ETRM documentation lists the following referenced base objects, all accessed through APPS synonyms:

• CS_INCIDENTS_ALL_B — the base Service Request (incident) table, source of INCIDENT_ID and most SR attributes.
• CS_INCIDENTS_ALL_TL — the translation table for SR text/description, joined on INCIDENT_ID and LANGUAGE.
• HZ_PARTIES — the party master, providing PARTY_ID, PARTY_NAME, and PARTY_TYPE.
• HZ_PARTY_SITES — the party site, linked to the customer site and to the party.
• HZ_LOCATIONS — the address, supplying COUNTRY, CITY, STATE, PROVINCE, POSTAL_CODE, and COUNTY.
• HZ_CONTACT_POINTS — contact point data, supplying PHONE_AREA_CODE (aliased AREA_CODE).
• HZ_ORGANIZATION_PROFILES — the organization profile, supplying EMPLOYEES_TOTAL (aliased NUM_OF_EMPLOYEES).

The view text shows an outer join on HZ_CONTACT_POINTS (OWNER_TABLE_NAME(+) = 'HZ_PARTIES'), which means contact point data is optional and rows are not dropped when no contact point exists. The join to CS_INCIDENTS_ALL_TL restricts results to the session language via USERENV('LANG').

Key Columns

The view exposes 38 columns, largely a mix of SR identifiers and territory-relevant attributes:

• SERVICE_REQUEST_ID — the primary SR identifier (INCIDENT_ID).
• PARTY_ID, PARTY_SITE_ID, COMP_NAME_RANGE — the customer party and site keys, and the party name (aliased COMP_NAME_RANGE).
• COUNTRY, STATE, CITY, PROVINCE, POSTAL_CODE, COUNTY, AREA_CODE — the geographic attributes used by territory rules.
• NUM_OF_EMPLOYEES — from the organization profile, used for size-based territory qualification.
• INCIDENT_TYPE_ID, INCIDENT_SEVERITY_ID, INCIDENT_URGENCY_ID, INCIDENT_STATUS_ID, PROBLEM_CODE, PLATFORM_ID — SR classification attributes.
• SUPPORT_SITE_ID, CUSTOMER_SITE_ID, INVENTORY_ITEM_ID — site and product identifiers.
• SR_CREATION_CHANNEL — the channel through which the SR was created.
• ATTRIBUTE1 through ATTRIBUTE15 — descriptive flexfield (DFF) segments, shown as NULL in the documented view definition, reserved for future attribute mapping.

Common Use Cases and Queries

Typical scenarios include auditing which SRs were assigned to which territory, validating that customer geography is populated for territory resolution, and building custom territory analysis reports. A representative query returning SR, party, and location attributes is:

SELECT service_request_id, party_id, comp_name_range, country, state, city, postal_code, area_code, num_of_employees FROM apps.cs_sr_territory_v WHERE service_request_id = :p_sr_id;

To count SRs by country for a given period, join back to CS_INCIDENTS_ALL_B on SERVICE_REQUEST_ID = INCIDENT_ID and filter on CREATION_DATE. Because the view is defined entirely over the TCA and SR base tables, no DML should be performed against it; it is intended strictly for read-only reporting and territory assignment lookups.