Results for “parameter_type_meaning”

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

Overview

CS_CP_PARAMETERS_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, belonging to the Service (CS) product family. It exposes the parameter details of each product recorded in Oracle Installed Base, presenting one row per parameter attached to a customer product instance. The view is read-only and does not store data itself; instead, it flattens and decodes transactional parameter rows into a form suitable for inquiry screens, concurrent reporting, and integration extracts.

The view is particularly relevant to users searching for aso_lookups, because its definition resolves two coded columns — PARAMETER_TYPE and STATUS — against lookup types maintained in the ASO_LOOKUPS view. The result is that consumers of CS_CP_PARAMETERS_V receive not only the raw code values but the associated MEANING text, exposed as the derived columns PARAMETER_TYPE_MEANING and STATUS_MEANING. This makes the view self-describing and removes the need for downstream reports to perform their own lookup joins.

Underlying Base Objects

Per the documented metadata (ETRM 12.2.2), the view is defined over the following objects:

• CS_CP_PARAMETERS (SYNONYM) — the primary source object holding the parameter rows for each customer product in Installed Base.
• ASO_LOOKUPS (VIEW) — joined twice (aliased LK1 and LK2) to translate the PARAMETER_TYPE and STATUS codes into their user-facing meanings.

The join between CS_CP_PARAMETERS and ASO_LOOKUPS is an outer join ((+) operators on the lookup aliases), meaning parameter rows are retained even when a corresponding lookup definition is missing or inactive. LK1 is constrained to LOOKUP_TYPE = 'ASO_LINE_ATTRIBUTE_TYPE' and LK2 to LOOKUP_TYPE = 'ASO_LINE_ATTRIBUTE_STATUS'. This linkage explains why the object is surfaced by a search for aso_lookups: the view is a canonical consumer of the ASO lookup types that describe line attribute classification and status for Installed Base parameters.

Key Columns

• CP_PARAMETER_ID — primary identifier for the parameter row.
• CUSTOMER_PRODUCT_ID — foreign key to the customer product (Installed Base instance) that owns the parameter; the principal join key to Installed Base queries.
• PARAMETER_TYPE — code value classifying the parameter, resolved against lookup type ASO_LINE_ATTRIBUTE_TYPE.
• PARAMETER_TYPE_MEANING — decoded display text for PARAMETER_TYPE supplied by ASO_LOOKUPS.
• NAME and VALUE — the parameter name and its assigned value.
• STATUS — code value for the parameter status, resolved against lookup type ASO_LINE_ATTRIBUTE_STATUS.
• STATUS_MEANING — decoded display text for STATUS supplied by ASO_LOOKUPS.
• START_DATE_ACTIVE / END_DATE_ACTIVE — effective date range for the parameter.
• APPLICATION_ID — owning application of the parameter record.
• CONTEXT and ATTRIBUTE1–ATTRIBUTE15 — flexfield-style descriptive columns reserved for extending the parameter definition.
• Audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) — standard EBS who-columns for change tracking.

Common Use Cases and Queries

Typical scenarios include retrieving all active parameters for a given Installed Base instance, reporting parameter values using their decoded meanings, and extracting parameter data for interfaces or data warehouses.

• Listing decoded parameters for a specific customer product:

SELECT cp_parameter_id,
       name,
       value,
       parameter_type_meaning,
       status_meaning
FROM   apps.cs_cp_parameters_v
WHERE  customer_product_id = :p_customer_product_id
AND    TRUNC(SYSDATE) BETWEEN NVL(start_date_active, TRUNC(SYSDATE))
                          AND NVL(end_date_active, TRUNC(SYSDATE));

• Grouping parameters by type meaning for analysis:

SELECT parameter_type_meaning,
       COUNT(*)
FROM   apps.cs_cp_parameters_v
WHERE  status_meaning = 'Active'
GROUP  BY parameter_type_meaning;

Because the view is defined with outer joins to ASO_LOOKUPS, rows whose lookup codes are not yet seeded will still appear, with the _MEANING columns returning NULL; consumers should therefore treat the decoded columns as informational rather than as filtering keys. All queries must be run against the APPS schema or a synonym granted for the view.