Search Results ame_rule_usages




Overview
Explore in AI Chat

Overview

The HR.AME_RULE_USAGES table is a component of the Oracle Approvals Management (AME) engine, delivered within the PER — Human Resources product group in Oracle E-Business Suite 12.1.1 and 12.2.2. AME evaluates approval rules dynamically at transaction time; AME_RULE_USAGES records the association between an approval rule and the specific transaction attributes, or "items," that the rule consumes during evaluation. In effect, it defines which rule participates in which approval context and under what priority and approver category.

The table holds 15 columns and is classified as VALID in the ETRM repository. Its owner is the HR schema, which also owns the core AME metadata tables such as AME_RULES and AME_CONDITIONS. The heuristic Data Vault classification mined from the foreign-key structure is standalone. This suggests that, from a modeling perspective, AME_RULE_USAGES is best treated as an independent reference table rather than a hub, link, or satellite. It does not merely connect two hubs; instead it stores a self-contained set of usage definitions keyed by rule, item, and effective dating, making it functionally closer to a lookup configuration table than a pure relationship table.

Key Information Stored

AME_RULE_USAGES operates on a rule-to-item relationship model. The most significant columns are:

  • RULE_ID — Identifies the AME rule that is being placed into service. This is the primary business identifier for the rule side of the relationship.
  • ITEM_ID — Identifies the approval item (transaction attribute) against which the rule is used. Together with RULE_ID, this forms the core of the business key.
  • USAGE_TYPE — Describes how the item is consumed by the rule, distinguishing whether the item acts as a condition attribute, an approver source, or another usage class.
  • START_DATE and END_DATE — Date-enable the usage record so that a rule can be active in one context and inactive in another over time.
  • PRIORITY — Establishes the evaluation order among competing usages, allowing deterministic rule resolution.
  • APPROVER_CATEGORY — Associates the usage with an approver category, such as a job-level or position-level approver, when applicable.
  • SECURITY_GROUP_ID — The only documented foreign key in the metadata, referencing FND_SECURITY_GROUPS. It controls visibility of the usage record across operating units or business groups.
  • OBJECT_VERSION_NUMBER — Supports optimistic locking during concurrent updates.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN — Standard Oracle who-columns that provide audit lineage.
  • ZD_EDITION_NAME — The editioning column used in 12.2 Online Patching to isolate rows by edition, appearing in the unique index as well.

The documented unique index AME_RULE_USAGES_UK1 (RULE_ID, ITEM_ID, START_DATE, END_DATE, ZD_EDITION_NAME) is the business-key candidate rather than a surrogate primary key. The metadata does not document a separate surrogate identifier, so the composite unique index should be regarded as the de facto identity for a usage row.

Common Use Cases and Queries

The primary practical use of AME_RULE_USAGES is administrative and diagnostic work on the AME engine. Typical scenarios include verifying which rules apply to a given transaction type, troubleshooting why an approval rule did not fire, and auditing rule activation windows.

  • Rule lookup by item: join AME_RULE_USAGES to AME_RULES on RULE_ID and filter by ITEM_ID and the current date range to see active rules for an attribute.
  • Priority review: order results by PRIORITY to confirm the sequence in which rules are evaluated for a given item and usage type.
  • Security-group scoping: join to FND_SECURITY_GROUPS on SECURITY_GROUP_ID to confirm which business group or operating unit sees a usage record.
  • Audit trail: filter on LAST_UPDATE_DATE and LAST_UPDATED_BY to identify recent configuration changes by an administrator.

A representative pattern is: select RULE_ID, ITEM_ID, USAGE_TYPE, PRIORITY, START_DATE, END_DATE from AME_RULE_USAGES where ITEM_ID = :item and trunc(sysdate) between START_DATE and nvl(END_DATE, trunc(sysdate)+1). This returns the currently effective usages for an attribute in priority order. Reporting extracts frequently focus on stale or overlapping effective dates, uncovered items, and rules whose usage windows have expired.

Related Objects

The most significant related objects are those in the AME substrate and the referenced security table:

  • FND_SECURITY_GROUPS — Referenced directly by AME_RULE_USAGES.SECURITY_GROUP_ID; join on SECURITY_GROUP_ID.
  • AME_RULES — Parent rule definitions; join on RULE_ID.
  • AME_CONDITIONS — Condition metadata attached to rules; joins indirectly via RULE_ID.
  • AME_APPROVER_GROUPS — Approver configuration used with APPROVER_CATEGORY; joins via RULE_ID.
  • AME_ATTRIBUTES — Defines the items referenced by ITEM_ID.
  • AME_ACTION_TYPES — Classifies actions that rules perform; relevant to USAGE_TYPE semantics.
  • AME_API — The public AME interface through which usage and rule configuration is maintained; changes to AME_RULE_USAGES are typically made by the engine rather than directly.
  • AME_TRANSACTIONS / AME_TXN_APPR_RULES — Runtime tables that store which rules were considered for a specific transaction, useful when reconciling against configured usages.

Direct DML on HR.AME_RULE_USAGES should be avoided. Configuration changes are expected to flow through the AME setup UI or the supported AME API so that referential integrity with AME_RULES and AME_ATTRIBUTES remains intact.