Results for “aso_apr_rule_steps_b”

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

Overview

The table ASO_APR_RULE_STEPS_B belongs to the ASO (Order Capture) product family in Oracle E-Business Suite. Within the Oracle ETRM reference documentation, its description is explicitly flagged as Obsolete, not used in 11i, and the implementation metadata states that it was Not implemented in this database. These two facts are the most important framing considerations for anyone researching this object. The table appears in the 12.1.1 and 12.2.2 technical repositories as a defined entity with a primary key and a full set of foreign key relationships, but it is not populated or actively used by the application at runtime in a standard 11i-derived installation. It represents a historical artifact from an earlier design of the ASO approval-rule engine.

From a modeling perspective, the heuristic Data Vault classification mined from the foreign key structure is satellite-leaning. This suggests that the base table behaves less like an independent hub or a standalone transactional entity and more like a dependent descriptor attached to a parent rule. Its rows carry the detailed step-level attributes of an approval rule and are keyed by a surrogate identifier inherited from the rule it qualifies. Analysts who encounter this table should treat it as a deprecated satellite of the ASO approval rule framework rather than as a source of current operational data.

Key Information Stored

Because the object is unimplemented, the column inventory is documented primarily through key constraints and foreign key definitions rather than through descriptive column comments. The columns that matter for navigation and structure are:

• ASO_APR_RULE_STEP_ID — the surrogate primary key, enforced by ASO_APR_RULE_STEPS_B_PK. This is the unique row identifier and the column inherited by the translation table.
• ASO_APR_RULE_ID — the foreign key pointing to ASO_APR_RULES_B, tying each step back to its parent approval rule. This is the principal business-key candidate for joining back to the rule header.
• LHS_AK_OBJECT, LHS_AK_ATTRIBUTE_CODE, LHS_AK_ATTR_APPLIC_ID — the left-hand-side attribute key triple, referencing AK_OBJECT_ATTRIBUTES, describing which object attribute participates in the comparison.
• RHS_AK_OBJECT, RHS_AK_ATTRIBUTE_CODE, RHS_AK_ATTR_APPLIC_ID — the corresponding right-hand-side attribute key triple, also referencing AK_OBJECT_ATTRIBUTES.
• LHS_FUNCTION_ID and RHS_FUNCTION_ID — foreign keys to ASO_APR_FUNCTION, identifying the functions applied to each side of the rule step.

Together these columns describe a single conditional step within an approval rule: an operator applied between two attribute expressions, optionally wrapped in functions. The absence of documented business-key unique indexes beyond the surrogate PK, combined with the deprecated status, reinforces that this structure is not a supported integration point.

Common Use Cases and Queries

Practical querying of this table is largely limited to lineage, impact analysis, and migration archaeology. Because the object is not implemented, any reporting built against it will return no rows in a standard installation. Typical exploratory patterns include:

• Confirming implementation status: SELECT COUNT(*) FROM aso_apr_rule_steps_b; — expected to return zero in a stock environment.
• Reconstructing rule definitions for historical comparison: SELECT s.ASO_APR_RULE_STEP_ID, s.ASO_APR_RULE_ID, s.LHS_FUNCTION_ID, s.RHS_FUNCTION_ID FROM aso_apr_rule_steps_b s JOIN aso_apr_rules_b r ON s.ASO_APR_RULE_ID = r.ASO_APR_RULE_ID;
• Resolving attribute meaning: joining the left- and right-hand AK triples to AK_OBJECT_ATTRIBUTES to translate internal attribute codes into human-readable names.
• Translation lookup: joining to ASO_APR_RULE_STEPS_TL on ASO_APR_RULE_STEP_ID to retrieve any language-specific descriptive text.

None of these queries are recommended as production reporting solutions; they serve documentation, audit, and upgrade-planning purposes only.

Related Objects

The object graph around ASO_APR_RULE_STEPS_B is compact and well defined by its foreign keys:

• ASO_APR_RULES_B — the parent approval-rule table, joined via ASO_APR_RULE_ID. Each step belongs to exactly one rule.
• ASO_APR_RULE_STEPS_TL — the translation (language) table, referencing this table through ASO_APR_RULE_STEP_ID. This is the only dependent object documented as pointing back into the base table.
• AK_OBJECT_ATTRIBUTES — referenced twice, once for the left-hand and once for the right-hand attribute key triples, providing the semantic definition of compared attributes.
• ASO_APR_FUNCTION — referenced twice through LHS_FUNCTION_ID and RHS_FUNCTION_ID, supplying the transformation functions applied to each side of the step.

Because the table is obsolete and unimplemented, no supported views, concurrent programs, or public APIs depend on it in 12.1.1 or 12.2.2. The relationships above exist to preserve referential integrity in the repository definition and to document the original approval-rule architecture for upgrade and support reference.