Search Results csi_system_type




Overview
Explore in AI Chat

Overview

APPS.CSI_SYSTEMS_RG_V is a reporting view in the Oracle E-Business Suite Customer Intelligence (CSI) module, specifically associated with the Telecommunications/Service industry and the Enterprise Telecommunications Resource Management (ETRM) product family. The view presents installed customer systems — that is, system instances tracked by the CSI schema and linked to a customer — enriched with descriptive attributes such as the system name, serial (system) number, parent system, owning customer, and the translated meaning of the system type lookup code. It is described in the ETRM documentation set for releases 12.1.1 and 12.2.2.

The object is a pure query view (no DML capability is implied), intended for reporting and integration consumers who need a flat, human-readable projection of systems without navigating the normalized CSI_SYSTEMS_B / CSI_SYSTEMS_TL pair directly. Because it joins HZ customer and party tables as well as FND_LOOKUP_VALUES, it is particularly useful when the consumer needs both the customer identity and the decoded system type. The "_RG" suffix reflects its registration as a report-generation style view within the CSI/ETRM object namespace, and it is the object a user lands on when searching for the term csi_system_type, since the view exposes the decoded CSI_SYSTEM_TYPE lookup as a column named SYSTEM_TYPE.

Underlying Base Objects

The documented base objects referenced by the view are: CSI_SYSTEMS_B, CSI_SYSTEMS_TL, HZ_CUST_ACCOUNTS, HZ_PARTIES, FND_LOOKUP_VALUES, and CSI_INSTALL_PARAMETERS (all exposed to APPS through synonyms).

  • CSI_SYSTEMS_B / CSI_SYSTEMS_TL — the base and translated (MLS) tables that hold the system record; joined on SYSTEM_ID, with CST.LANGUAGE restricted to the session language via USERENV('LANG').
  • HZ_CUST_ACCOUNTS — joined on CSB.CUSTOMER_ID = HCA.CUST_ACCOUNT_ID to resolve the owning customer account (ACCOUNT_NUMBER, CUST_ACCOUNT_ID, PARTY_ID).
  • HZ_PARTIES — joined on HCA.PARTY_ID = HP.PARTY_ID to supply the party name.
  • FND_LOOKUP_VALUES — outer-joined (note the (+) operators) on LOOKUP_TYPE = 'CSI_SYSTEM_TYPE' with VIEW_APPLICATION_ID = 542 and LANGUAGE = USERENV('LANG'), decoding CSB.SYSTEM_TYPE_CODE into CLK.MEANING.
  • CSI_INSTALL_PARAMETERS — used in a NOT IN subquery to exclude the internal (own) party, so only customer-owned systems are returned.

Key Columns

  • SYSTEM_ID — primary identifier of the system record.
  • SYSTEM — the translated name of the system (from CSI_SYSTEMS_TL.NAME).
  • SERIAL_NUMBER — the system number from CSI_SYSTEMS_B.SYSTEM_NUMBER.
  • PARENT_SYSTEM_ID — self-referencing link to the parent system, enabling hierarchy reporting.
  • PARTY_NAME — the owning party/customer name.
  • ACCOUNT_NUMBER — the customer account number.
  • SYSTEM_DESCRIPTION — translated system description.
  • SYSTEM_TYPE — the decoded lookup meaning for the CSI_SYSTEM_TYPE lookup (this is the column matching the search term csi_system_type).
  • CUSTOMER_ID, CUST_ACCOUNT_ID, PARTY_ID — foreign keys into the customer/party model, useful for downstream joins.

Common Use Cases and Queries

Typical uses include customer-facing system inventories, installed-base reporting, and integration extracts that require both the customer account and a decoded system type. Because the view filters out the internal party, it is safe to use for external-facing reports.

Listing systems for a known customer account:

  • SELECT system_id, system, serial_number, system_type, party_name FROM apps.csi_systems_rg_v WHERE account_number = :account_number;

Grouping the installed base by system type:

  • SELECT system_type, COUNT(*) FROM apps.csi_systems_rg_v GROUP BY system_type ORDER BY 2 DESC;

Traversing the system hierarchy using PARENT_SYSTEM_ID, or joining back to CSI_SYSTEMS_B on SYSTEM_ID for additional attributes, are also common patterns. Note that all queries must run with the APPS schema (or a synonym/synced environment) and that SYSTEM_TYPE returns NULL where no matching lookup value exists, because the FND_LOOKUP_VALUES join is an outer join.