Search Results csd_rule_results_tbl_type
Overview
CSD_RULES_ENGINE_PVT is a private PL/SQL package in the APPS schema that implements the rules engine underpinning Oracle E-Business Suite's Enterprise Asset Management (EAM) and Depot Repair functionality. Its central purpose is to evaluate user-defined rules — configured by administrators in the rules setup — against service, repair, and return-order transactions, and to return derived outcomes such as defaulted attribute values, computed dates, matched conditions, and dynamically generated SQL fragments. In EBS 12.1.1 and 12.2.2 the package is classified as a PVT (private) API, meaning it is not part of the supported public interface. It is intended only for internal consumption by the standard EBS products that depend upon it and by Oracle's own concurrent and form logic. The "rules engine" abstraction allows business policies (for example, defaulting a repair type, promising a ship date, or flagging a chronic repair) to be expressed declaratively as rule data rather than hard-coded logic, and CSD_RULES_ENGINE_PVT is the runtime component that interprets and applies that data at transaction time.
Key Procedures and Functions
The ETRM metadata documents 24 procedures and functions, grouped functionally as follows:
- Rule evaluation entry points: PROCESS_RULE_MATCHING evaluates the active rules against a transaction and returns matched results; PROCESS_SOO_RULE applies a rule in a service/order context; SOO_DEFAULTING performs attribute defaulting for a service order object.
- Condition matching: MATCH_CONDITION and CHECK_CONDITION_MATCH evaluate whether a specific rule condition is satisfied by the current transaction data, and GET_SQL_OPERATOR maps condition operators to their SQL equivalents.
- Value derivation: GET_DEFAULT_VALUE and GET_DEFAULT_VALUE_FROM_RULE retrieve the configured default value for a given rule, which is then applied to the transaction payload.
- Record preparation: POPULATE_RULE_INPUT_REC and COPY_RULE_INPUT_REC_VALUES assemble and copy the input record structure that the rules engine consumes.
- Domain-specific validators: CHECK_RO_ITEM_CATEGORY, CHECK_PROMISE_DATE, CHECK_RESOLVE_BY_DATE, CHECK_RETURN_BY_DATE, CHECK_REPEAT_REPAIR, CHECK_CHRONIC_REPAIR, and CHECK_CONTRACT_EXP_DATE evaluate individual business conditions against return-order and repair data.
- Support functions: GET_COUNTRY_CODE, GET_RO_INSTANCE_ID, GET_RULE_SQL_FOR_RO, and GET_SQL_OPERATOR provide lookup and SQL-generation utilities used by the checks above.
Tables Accessed
The package reads and writes configured rule definitions primarily through CSD_RULES_B and CSD_RULE_CONDITIONS_B, which store the rule headers and their associated conditions. Transactional repair data is read from CSD_REPAIRS and WIP_ENTITIES. Location and party context — used by the geographic and site-related conditions — is derived from HR_LOCATIONS_ALL, HZ_LOCATIONS, HZ_PARTY_SITES, and HZ_PARTY_SITE_USES. Item classification checks draw on MTL_ITEM_CATEGORIES, while contract expiry conditions reference OKC_K_LINES_B. The package also invokes DBMS_SQL to assemble and execute dynamic SQL generated by GET_RULE_SQL_FOR_RO, and uses PLITBLM for PL/SQL table manipulation.
Usage Notes
CSD_RULES_ENGINE_PVT is invoked indirectly by higher-level EAM and Depot Repair packages rather than called directly. The ETRM dependency data shows it is referenced by CSD_BULK_RECEIVE_UTIL, CSD_PROCESS_UTIL, CSD_REPAIRS_UTIL, and CSD_RO_BULLETINS_PVT, and it is referenced by nine packages in total, consistent with its role as a shared engine. Because it is a PVT API and its signature is not published, customers and integrators should not call it from custom code; doing so risks breakage on patching. Customizations that need rules-driven defaulting or validation should be layered on the supported public APIs of the calling products, letting the engine be invoked through them. When troubleshooting rule behavior in 12.1.1 or 12.2.2, inspecting this package is nonetheless valuable, since it reveals exactly how conditions are matched and how defaulted values propagate to the calling transaction.