Search Results cs_systems_cp_maint_v

Overview

The CS_SYSTEMS_CP_MAINT_V view belongs to the Service (CS) module of Oracle E-Business Suite and is documented as "Systems and their attributes." It exposes a denormalized, reporting-oriented projection of installed system records maintained in the Service foundation tables. Rather than presenting the raw foreign keys of the underlying system entity, the view joins in customer names, lookup meanings, site locations, and formatted postal addresses so that downstream reports, concurrent programs, and integration extracts can consume a single flattened row set.

The "_CP_MAINT_" naming convention indicates the view is intended for the Service "Counterparty / contact point maintenance" family of objects used to maintain and display contact and address information for systems. In EBS 12.1.1 and 12.2.2 the view is exposed for read access only; the view text performs all resolution logic so consumers do not need to re-implement joins to the customer, lookup, site-use, and address tables themselves.

Underlying Base Objects

The ETRM metadata excerpt for this object does not document an explicit owner, and no referenced base objects are listed in the "structure" section of the metadata. The view text, however, explicitly qualifies its source as CS (the Service schema) and joins additional aliased tables. The primary source is CS_SYSTEMS (aliased CS), which supplies the system identifiers, descriptive attributes, serial number, parent system, contacts, and the installed/bill-to/ship-to site-use references.

Secondary joins resolve descriptive values: a customer master table (aliased CUST, and CUST1/CUST2 for ship-to and install customers) supplies CUSTOMER_NAME; a lookup table (aliased L) resolves SYSTEM_TYPE_CODE to its MEANING; site-use tables (SU1, SU2) supply LOCATION; and address tables (ADDR1, ADDR2) supply the formatted ADDRESS1/ADDRESS2/ADDRESS3 columns. Because the ETRM metadata states the object is "Not implemented in this database," the exact physical dependency list must be confirmed against the customer's own instance using ALL_DEPENDENCIES before relying on it for custom development.

Key Columns

• SYSTEM_ID, NAME, DESCRIPTION, SERIAL_NUMBER — identifiers and descriptive attributes of the installed system.
• CUSTOMER_ID, CUSTOMER_NAME — owning customer for the system.
• SYSTEM_TYPE_CODE / SYSTEM_TYPE — the raw code and its decoded lookup MEANING.
• PARENT_SYSTEM_ID, AUTOCREATED_FROM_SYSTEM_ID — hierarchy and autocreation lineage between systems.
• TECHNICAL_CONTACT_ID, SERVICE_ADMIN_CONTACT_ID, BILL_TO_CONTACT_ID, SHIP_TO_CONTACT_ID — role-based contact references.
• INSTALL_SITE_USE_ID, BILL_TO_SITE_USE_ID, SHIP_TO_SITE_USE_ID — site-use foreign keys for the three address roles.
• SHIP_TO_ADDRESS1/2/3, INSTALL_ADDRESS1/2 — concatenated, comma-delimited address lines built with DECODE, with the city/state/postal/country line truncated via SUBSTR to 220 characters.
• START_DATE_ACTIVE, END_DATE_ACTIVE, COTERMINATE_DAY_MONTH — effective dating and cotermination scheduling attributes.
• ATTRIBUTE1–15, CONTEXT — descriptive flexfield segments carried through unchanged.

Common Use Cases and Queries

The view is typically used for installed-base reporting, service contract preparation, and customer-facing system inventories where resolved customer names and addresses are required alongside system details. A common pattern is to filter by active systems and owning customer, projecting the ship-to and install address columns directly:

• Installed base listing: SELECT system_id, name, serial_number, customer_name, install_location, install_address1 FROM cs_systems_cp_maint_v WHERE start_date_active <= SYSDATE AND (end_date_active IS NULL OR end_date_active >= SYSDATE);
• Shipping label extraction: SELECT ship_to_customer, ship_to_location, ship_to_address1, ship_to_address2, ship_to_address3 FROM cs_systems_cp_maint_v WHERE system_id = :p_system_id;
• System type roll-up: SELECT system_type, COUNT(*) FROM cs_systems_cp_maint_v GROUP BY system_type;
• Contact resolution: join back to CS_SYSTEMS or contact tables on the contact ID columns when contact names are also required.

Because the view is not implemented in every database, existence checks against ALL_VIEWS should precede any hard-coded reference. Where the view is absent, equivalent logic can be reproduced by joining CS_SYSTEMS to the customer, lookup, site-use, and address tables directly, replicating the DECODE and SUBSTR formatting used in the view text.