Search Results ame_attributes_pk




Overview

HR.AME_ATTRIBUTES is a core configuration table within the Oracle E-Business Suite Approvals Management Engine (AME). It stores the basic definitions of every attribute recognized by AME, including the mandatory system attributes shipped by Oracle, the attributes required by seeded approval rules, and any custom attributes defined by an implementation to support transaction-specific approval logic. Each row represents a single attribute that can be referenced in AME rule conditions, thereby acting as the vocabulary from which approval rules are constructed.

The table resides in the HR schema, is registered under the FND Design Data object PER.AME_ATTRIBUTES, and is stored in the APPS_TS_TX_DATA tablespace. Its unique index AME_ATTRIBUTES_PK resides in APPS_TS_TX_IDX. Because AME attributes describe reusable business concepts (for example, an approver type, an item class, or a transaction amount band) rather than transactional events themselves, the heuristic Data Vault classification for this object is a hub. It anchors the identity of each attribute; date-effective and descriptive detail is carried on the same row and would more naturally be modelled as a satellite in a strict Data Vault design.

Key Information Stored

The surrogate primary key is ATTRIBUTE_ID, a system-generated NUMBER that uniquely identifies each attribute. The documented unique index AME_ATTRIBUTES_PK is a composite spanning ATTRIBUTE_ID, START_DATE, END_DATE, and ZD_EDITION_NAME, reflecting the date-effective, edition-aware nature of the row. The business-key candidate for human consumption is NAME, the VARCHAR2(50) attribute name referenced by AME rule definitions.

  • ATTRIBUTE_ID — surrogate identifier and leading column of the primary key.
  • NAME — the attribute name used when building or reporting on approval rules.
  • ATTRIBUTE_TYPE — VARCHAR2(20) classifying the attribute (for example, transaction or item attribute).
  • DESCRIPTION — VARCHAR2(100) description of the attribute's purpose.
  • APPROVER_TYPE_ID — identifies the approver type attached to the attribute, when applicable.
  • ITEM_CLASS_ID — identifies the item class to which the attribute belongs.
  • START_DATE / END_DATE — date-effective boundaries that activate and inactivate the row.
  • SECURITY_GROUP_ID — legacy security grouping, documented as not used and carrying a foreign key to FND_SECURITY_GROUPS.
  • OBJECT_VERSION_NUMBER — optimistic locking counter incremented on each update.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard Who columns for auditability.

Common Use Cases and Queries

Typical investigative and reporting scenarios include identifying which attributes exist for a given item class, confirming whether a custom attribute has been registered, or tracing an approval rule back to the attribute that drives it. Because AME upgrades can introduce new attributes, querying this table is a common validation step. A representative pattern retrieves active rows only:

SELECT ATTRIBUTE_ID, NAME, ATTRIBUTE_TYPE, DESCRIPTION
FROM HR.AME_ATTRIBUTES
WHERE TRUNC(SYSDATE) BETWEEN START_DATE AND NVL(END_DATE, TRUNC(SYSDATE));

A second pattern isolates custom attributes by joining on ITEM_CLASS_ID or filtering on APPROVER_TYPE_ID. Because of the composite unique index, joins to dependent AME rule tables should include ATTRIBUTE_ID together with the effective date range to return the correct dated row.

Related Objects

Documented dependencies identify the following significant relationships:

  • HR.AME_ATTRIBUTES (APPS synonym APPS.AME_ATTRIBUTES) — the APPS-layer synonym used by application code and reports, joined on ATTRIBUTE_ID.
  • FND_SECURITY_GROUPS — referenced through AME_ATTRIBUTES.SECURITY_GROUP_ID; the column is legacy and documented as not used.
  • HR.AME_ATTRIBUTES_VL and related AME attribute views — presentation-layer access used by the AME setup user interface.
  • AME rule and rule-condition tables (for example, the AME attribute-usage and condition definition tables) — reference ATTRIBUTE_ID to bind attributes into approval rules.
  • AME item class and approver type configuration tables — linked via ITEM_CLASS_ID and APPROVER_TYPE_ID respectively.

The ETRM dependency section confirms that HR.AME_ATTRIBUTES does not reference any other database object beyond the security group foreign key, and that it is referenced by the APPS synonym layer and dependent AME rule components.