Search Results ame_exceptions_log




Overview
Explore in AI Chat

Overview

The AME_EXCEPTIONS_LOG table is an HR-owned database object within the Oracle E-Business Suite, positioned under the PER (Human Resources) product family. It resides in the HR schema and holds a VALID status in both Oracle EBS 12.1.1 and 12.2.2 environments. The object forms part of the Oracle Approvals Management Engine (AME) infrastructure, a rules-based framework that determines approver lists and approval routing for transactions across multiple EBS modules. Despite its Human Resources ownership, AME is a cross-application service consumed by Purchasing, Payables, iProcurement, Human Resources, and other products that require dynamic approval hierarchies.

The table functions as an operational exception log. When AME processes a transaction and encounters a rule evaluation anomaly — such as a malformed approval rule, an unresolvable approver, a missing participant, or an unexpected runtime condition within an AME package routine — the event is captured as a row. This provides administrators and technical support staff with a persistent, queryable audit trail that explains why an approval process behaved unexpectedly.

The ETRM metadata classifies this table heuristically as standalone within a Data Vault modeling context. Because the log records discrete, immutable events tied to a transaction and a point-in-time package execution, it is most naturally modeled as a satellite-like or transaction-log structure rather than a hub or link. It does not carry traditional master-data relationships and its single foreign key is administrative rather than business-oriented.

Key Information Stored

The table contains eight documented columns. The surrogate primary key is LOG_ID, enforced by the unique index AME_EXCEPTIONS_LOG_PK. This is the only documented business-key candidate, and it serves purely as a technical identifier for each logged event.

  • LOG_ID — Surrogate primary key; uniquely identifies each exception record.
  • PACKAGE_NAME — The PL/SQL package in which the exception was raised, pinpointing the AME processing module.
  • ROUTINE_NAME — The specific procedure or function within that package, enabling precise fault localization.
  • TRANSACTION_ID — Identifies the business transaction (for example, a purchase order or requisition) whose approval processing triggered the exception.
  • APPLICATION_ID — The EBS application context, resolving to the originating product such as Purchasing or Payables.
  • EXCEPTION_NUMBER — The numeric error code associated with the raised condition.
  • EXCEPTION_STRING — The human-readable error message or diagnostic detail, the most valuable column for troubleshooting.
  • SECURITY_GROUP_ID — The foreign key referencing FND_SECURITY_GROUPS, governing data visibility and access control.

Common Use Cases and Queries

Support teams query this table to diagnose stalled or misrouted approvals. A typical investigation filters recent exceptions by transaction:

  • SELECT log_id, package_name, routine_name, exception_string FROM hr.ame_exceptions_log WHERE transaction_id = :txn_id ORDER BY log_id DESC;
  • SELECT application_id, exception_number, COUNT(*) FROM hr.ame_exceptions_log GROUP BY application_id, exception_number ORDER BY 3 DESC;

These patterns surface recurring defects, identify which AME subroutine fails most often, and support post-implementation validation after approval rule changes. Records are typically analyzed during period-close troubleshooting or following AME rule migrations.

Related Objects

  • FND_SECURITY_GROUPS — joined on SECURITY_GROUP_ID to resolve access-control context.
  • AME_APPLICATIONS — resolves APPLICATION_ID to the source product.
  • AME_TRANSACTIONS — correlates TRANSACTION_ID to AME transaction metadata.
  • AME_RULES — the rule definitions whose evaluation generated the exception.
  • FND_LOG_MESSAGES — complementary diagnostic logging for broader error context.