Results for “csd_rules_v”

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

Overview

CSD_RULES_V is a reporting and integration view in the Oracle E-Business Suite Depot Repair (CSD) module, owned by the APPS schema and shipped with a VALID status in both 12.1.1 and 12.2.2. It exposes the complete set of configurable "defaulting rules" used by Depot Repair to derive values on repair order lines, service work orders, and related entities. Rather than presenting raw code columns, the view resolves the internal lookup codes into user-facing meanings, making it directly consumable by reports, concurrent programs, OAF pages, and external integrations that need to render rules in a readable form.

The view is defined over the base rule table and merges in translated text and seeded lookup values, so a single query returns rule identity, classification, precedence, target attribute, and the meaning of every code — including VALUE_TYPE_MEANING, the column most frequently referenced by developers, since it answers the question "what kind of value does this rule produce?"

Underlying Base Objects

• CSD_RULES_B — the base table holding rule definitions (ROLE_ID, RULE_TYPE_CODE, PRECEDENCE, ENTITY_ATTRIBUTE_CODE, VALUE_TYPE_CODE, and the DFF attribute columns).
• CSD_RULES_TL — the translation table supplying NAME and DESCRIPTION, joined on RULE_ID and restricted to USERENV('LANG').
• FND_LOOKUPS — joined four times to resolve meanings: CSD_RULE_TYPES (rule type), CSD_DEFAULTING_ENTITIES (entity attribute type), a keyed lookup matching ENTITY_ATTRIBUTE_TYPE/CODE for the attribute meaning, and CSD_DEFAULTING_VALUE_TYPES for VALUE_TYPE_MEANING.
• FND_GLOBAL — the package providing USERENV/context used in the language and lookup resolution paths.

The view is therefore a pure read-only projection: inserts and updates must target the underlying tables, and any extension of the rule model should be done in the base tables, not the view.

Key Columns

• RULE_ID — surrogate identifier of the rule.
• NAME / DESCRIPTION — translated, language-sensitive text.
• RULE_TYPE_CODE / RULE_TYPE_MEANING — the rule classification, decoded from CSD_RULE_TYPES.
• PRECEDENCE — execution order; lower values are applied first.
• ENTITY_ATTRIBUTE_CODE / ENTITY_ATTRIBUTE_MEANING — the target attribute being defaulted.
• ENTITY_ATTRIBUTE_TYPE / ENTITY_ATTRIBUTE_TYPE_MEANING — the entity on which the attribute lives.
• VALUE_TYPE_CODE / VALUE_TYPE_MEANING — the type of value the rule supplies (for example, constant, profile, or SQL-derived), decoded from CSD_DEFAULTING_VALUE_TYPES.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–15 — descriptive flexfield segments available for customer extensions.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, OBJECT_VERSION_NUMBER — standard WHO columns and optimistic locking support.

Because the lookup joins are outer joins, a rule whose value type has not been seeded will still be returned, with VALUE_TYPE_MEANING null; users searching on "value_type_meaning" should therefore treat blanks as unseeded or obsolete lookup configurations rather than missing rules.

Common Use Cases and Queries

Typical scenarios include auditing which rules produce which value types, diagnosing defaulting behaviour on a repair order, and listing rules for a target entity/attribute pair. A simple audit query is:

SELECT rule_id, name, rule_type_meaning, precedence,
       entity_attribute_type_meaning, entity_attribute_code,
       entity_attribute_meaning, value_type_meaning
FROM   csd_rules_v
WHERE  value_type_meaning IS NOT NULL
ORDER  BY entity_attribute_type_meaning, precedence;

To find the rules that drive a specific attribute:

SELECT r.name, r.rule_type_meaning, r.precedence, r.value_type_meaning
FROM   csd_rules_v r
WHERE  r.entity_attribute_code = :attribute_code
AND    r.entity_attribute_type = :attribute_type
ORDER  BY r.precedence;

Because the view already resolves meanings, it is the preferred source for integration extracts and for joining to repair order data, eliminating the need to re-implement the FND_LOOKUPS decodes in client code.