Search Results entity_attribute_code

Overview

CSD_RULES_VL is a validation view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It belongs to the CSD (Depot Repair) product family and follows the standard Oracle Applications multilingual ("_VL") pattern: the underlying base table stores language-independent data, while translated name and description attributes are resolved at query time from a translation table using the active session language. The view therefore presents rule definitions in the language of the connected user without duplicating transactional data.

In Depot Repair, rules drive automated decision logic — for example, how repair lines are validated, priced, routed, or approved. CSD_RULES_VL is the reporting and integration entry point for that rule configuration. Because it exposes the descriptive NAME and DESCRIPTION columns alongside the technical rule attributes, it is suitable for both end-user inquiries and programmatic lookups that must return readable text rather than coded values.

Underlying Base Objects

The view is defined over two documented base objects:

• CSD_RULES_B — the base (language-independent) table holding rule identifiers, rule type, precedence, the entity/attribute target, value type, WHO audit columns, the object version number, and the 15 DFF attribute columns (ATTRIBUTE_CATEGORY and ATTRIBUTE1–15).
• CSD_RULES_TL — the translation table holding NAME and DESCRIPTION per language.

The join is RULB.RULE_ID = RULTL.RULE_ID AND RULTL.LANGUAGE = USERENV('LANG'), which returns exactly one translated row per rule for the session language. This is the standard Oracle translation pattern and ensures consistency with Forms-based Depot Repair screens that resolve the same language context. Row identity is preserved through the exposed ROW_ID of the base table.

Key Columns

• RULE_ID — primary identifier of the rule; the join key across _B, _TL, and any dependent setup tables.
• NAME, DESCRIPTION — translated, user-facing text from CSD_RULES_TL.
• RULE_TYPE_CODE — classifies the rule (lookup-driven), determining how the rule is evaluated by Depot Repair.
• PRECEDENCE — evaluation order when multiple rules apply; lower values generally evaluate first.
• ENTITY_ATTRIBUTE_CODE — identifies the specific entity attribute the rule targets. This is the column most commonly searched for, and it links a rule to the field it governs.
• ENTITY_ATTRIBUTE_TYPE and VALUE_TYPE_CODE — describe the datatype/domain of the target attribute and the type of value being compared, so consumers can interpret the rule payload correctly.
• WHO and concurrency columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, OBJECT_VERSION_NUMBER) — audit and optimistic locking metadata.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — descriptive flexfield segments for customer-specific extensions.

Common Use Cases and Queries

Typical uses include rule inventory reporting, locating rules that target a particular attribute, and feeding rule data into integration or migration extracts.

List all rules with translated text, ordered by evaluation precedence:

SELECT rule_id, name, rule_type_code, precedence,
       entity_attribute_code, value_type_code
FROM   apps.csd_rules_vl
ORDER  BY rule_type_code, precedence;

Find rules bound to a specific entity attribute, which is the primary use case when the search term is entity_attribute_code:

SELECT rule_id, name, description, rule_type_code,
       entity_attribute_type, value_type_code, precedence
FROM   apps.csd_rules_vl
WHERE  entity_attribute_code = :p_attribute_code
ORDER  BY precedence;

Audit recently modified rules, using the WHO columns exposed by the view:

SELECT rule_id, name, last_updated_by, last_update_date
FROM   apps.csd_rules_vl
WHERE  last_update_date >= :p_since_date
ORDER  BY last_update_date DESC;

Because translation resolution depends on USERENV('LANG'), reports intended for multiple languages should either be run per-language session or joined directly to CSD_RULES_TL where explicit language selection is required. All queries should be qualified with the APPS schema or a synonym, and access should respect the standard EBS responsibility and security model.