Results for “cs_systems_vl”

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

Overview

CS_SYSTEMS_VL is a single-organization, single-language view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It belongs to the Service (CS) product family and exposes customer system records — the installed-base entities that Service uses to track products placed at a customer site. The _VL suffix denotes a "view, language" construct: the view joins the transactional base table to its translation table and filters translations to the session language, returning one row per system with language-dependent descriptive columns already resolved.

The view also enforces organization-level security through the standard Multi-Org mechanism. Its WHERE clause compares B.ORG_ID against the operating unit derived from USERENV('CLIENT_INFO'), using the NVL(..., -99) defaulting pattern typical of EBS secured views. Consequently, rows are only visible for the operating unit established in the user's session, and the view reflects whatever the current responsibility has set as its Org context. Because it always reads the current session language, it is the natural reporting surface for queries that must return translated system names and descriptions.

Underlying Base Objects

Per the ETRM metadata the view is defined over two synonym-referenced base objects:

• CS_SYSTEMS_ALL_B — the multi-org base table holding the system's transactional attributes, aliased as B.
• CS_SYSTEMS_ALL_TL — the translation table holding language-specific NAME and DESCRIPTION values, aliased as T.

The join predicate is B.SYSTEM_ID = T.SYSTEM_ID, combined with T.LANGUAGE = USERENV('LANG') to restrict translations to the session language, and the Org security predicate on B.ORG_ID. All columns are taken from the base table B except NAME and DESCRIPTION, which come from the translation table T. A synthetic ROW_ID is exposed from B.ROWID.

Key Columns

• SYSTEM_ID — primary identifier of the system record; the join key between base and translation tables.
• CONFIG_SYSTEM_TYPE — the configuration system type associated with the record; this is the column most directly relevant to searches on "config_system_type" and is stored on the base table.
• SYSTEM_TYPE_CODE — the system type classification, complementing CONFIG_SYSTEM_TYPE.
• CUSTOMER_ID — the customer or party that owns the installed system.
• SERIAL_NUMBER — the serialized identifier of the tracked item.
• PARENT_SYSTEM_ID, AUTOCREATED_FROM_SYSTEM_ID — self-referencing hierarchy and creation lineage.
• TECHNICAL_CONTACT_ID, SERVICE_ADMIN_CONTACT_ID, BILL_TO_CONTACT_ID, SHIP_TO_CONTACT_ID — contact roles associated with the system.
• INSTALL_SITE_USE_ID, BILL_TO_SITE_USE_ID, SHIP_TO_SITE_USE_ID — site use references for installation, billing, and shipping.
• START_DATE_ACTIVE, END_DATE_ACTIVE, COTERMINATE_DAY_MONTH — date effectivity and cotermination settings.
• ORG_ID — operating unit, driving the view's Org security filter.
• NAME, DESCRIPTION — language-translated descriptive values from CS_SYSTEMS_ALL_TL.
• ATTRIBUTE1–ATTRIBUTE15, CONTEXT — the standard DFF (descriptive flexfield) columns.

Common Use Cases and Queries

The view is typically used for reporting and integration where translated names are required and Org security is acceptable. A representative query retrieving systems of a given configuration type follows:

• SELECT system_id, name, system_type_code, config_system_type, serial_number, customer_id FROM cs_systems_vl WHERE config_system_type = :p_type;
• SELECT system_id, name, start_date_active, end_date_active FROM cs_systems_vl WHERE customer_id = :p_customer AND TRUNC(SYSDATE) BETWEEN start_date_active AND NVL(end_date_active, SYSDATE);
• SELECT system_id, name, parent_system_id FROM cs_systems_vl WHERE parent_system_id IS NOT NULL ORDER BY parent_system_id;

Note that because CS_SYSTEMS_VL applies Org and language filtering automatically, callers must set the correct operating unit and language context before querying; otherwise rows will appear to be missing. Where an Org-agnostic or all-language result set is genuinely required, the underlying base tables must be queried directly rather than through this view.