Search Results ame_condition_usages




Overview
Explore in AI Chat

Overview

The AME_CONDITION_USAGES table is an Oracle E-Business Suite data object owned by the HR schema and associated with the PER (Human Resources) product family. It is a component of the Oracle Approvals Management Engine (AME), the rules-based framework that EBS applications use to determine approval routing, approval chain construction, and the evaluation of approval-related conditions. Within this framework, AME_CONDITION_USAGES records the association between approval rules and the conditions defined against them, effectively capturing where and how a given condition is applied.

From a data modeling perspective, the ETRM metadata classifies this object heuristically as standalone, based on its mined foreign key structure. In Data Vault terms, a standalone classification suggests the table functions as an independent structure rather than a strict hub, link, or satellite. Practically, however, AME_CONDITION_USAGES behaves as a transactional association (junction) record that binds conditions to rules, with history preserved through date-effective columns. The metadata lists a single documented foreign key to FND_SECURITY_GROUPS via SECURITY_GROUP_ID, indicating that records are secured and partitioned by security group in a multi-tenant or multi-organization deployment.

Key Information Stored

The table contains 12 documented columns. The most significant are:

  • RULE_ID — Identifier of the approval rule to which the condition usage belongs; a core component of the business key.
  • CONDITION_ID — Identifier of the condition being applied within that rule; also a core business key component.
  • START_DATE — Effective start date of the condition usage record; part of the business key.
  • END_DATE — Effective end date of the condition usage record; part of the business key and the primary mechanism for date-effective history.
  • ZD_EDITION_NAME — Editioning identifier used by EBS 12.2 online patching to isolate edition-specific data; a business key component.
  • SECURITY_GROUP_ID — Foreign key to FND_SECURITY_GROUPS, controlling data access by security grouping.
  • OBJECT_VERSION_NUMBER — Optimistic locking control for concurrent updates through the AME APIs.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard EBS audit columns recording who created and last modified each row and when.

The documented unique index AME_CONDITION_USAGES_UK1 spans RULE_ID, CONDITION_ID, START_DATE, END_DATE, and ZD_EDITION_NAME, establishing the business key. Note that the metadata does not document a separate surrogate primary key column beyond these business key candidates; the uniqueness of a condition usage is consequently enforced through the combination above rather than through a single generated identifier.

Common Use Cases and Queries

The principal use case is tracing which conditions apply to a given approval rule, which supports approval configuration review, rule troubleshooting, and impact analysis before rule changes. A typical query joins the table to rule and condition definitions:

  • List all condition usages for a specific rule: SELECT RULE_ID, CONDITION_ID, START_DATE, END_DATE FROM AME_CONDITION_USAGES WHERE RULE_ID = :rule_id ORDER BY START_DATE;
  • Retrieve currently effective usage: ... WHERE SYSDATE BETWEEN START_DATE AND END_DATE;
  • Audit recent changes: SELECT RULE_ID, CONDITION_ID, LAST_UPDATED_BY, LAST_UPDATE_DATE FROM AME_CONDITION_USAGES ORDER BY LAST_UPDATE_DATE DESC;
  • Restrict by security group: add WHERE SECURITY_GROUP_ID = :sg_id when reporting across secured partitions.

Date-effective reporting should always include a SYSDATE predicate, since multiple historical versions of the same rule/condition pairing may coexist.

Related Objects

The most significant related objects are:

  • FND_SECURITY_GROUPS — Joined on SECURITY_GROUP_ID to resolve the security grouping that governs access to each usage record.
  • AME_RULES — The approval rule definitions referenced by RULE_ID; the parent object of the rule side of the relationship.
  • AME_CONDITIONS — The condition definitions referenced by CONDITION_ID; the parent object of the condition side.
  • AME_CONDITION_USAGES dependent AME rule evaluation and approval configuration APIs, which read this table at runtime to determine applicable conditions.
  • Other AME configuration tables (rule and condition action associations) that complete the approval rules model.

Because AME is embedded across EBS modules, dependent objects frequently reside in application schemas that query these HR-owned tables through AME APIs rather than direct SQL.