Search Results ams_act_qa_checks_u2

Overview

The AMS.AMS_ACT_QA_CHECKS table is a core configuration and metadata repository within the Oracle Marketing (AMS) module of Oracle E-Business Suite. It stores the definitions of Quality Assurance (QA) checks that govern the validation and approval workflow for marketing activities and campaigns. Each row represents a discrete QA check rule, binding the business intent of a check to the specific PL/SQL package and function that implements it at runtime. Administrators use these records to enable or disable validation rules, control whether a failed check produces a warning or a hard error, and determine the order in which checks execute. The table therefore acts as a bridge between declarative marketing setup and the procedural code that enforces business logic during activity creation, approval, and lifecycle transitions.

From a Data Vault modeling perspective, the mined relationship structure classifies this object as satellite-leaning. It carries descriptive attributes, status flags, and versioning columns (OBJECT_VERSION_NUMBER) that describe the mutable state of a QA check over time, rather than functioning as a pure hub of business keys. This heuristic is a modeling suggestion only; in native EBS terms the table behaves as a transactional configuration entity with audit-tracked WHO columns.

Key Information Stored

The table is keyed on the surrogate primary key ACTIVITY_QA_CHECK_ID (index AMS_ACT_QA_CHECKS_U1). A second unique index, AMS_ACT_QA_CHECKS_U2, defines the business-key candidate as the combination of ACTIVITY_QA_CHECK_FOR_ID, ARC_ACTIVITY_QA_CHECK_FOR, and FUNCTION_NAME — that is, a QA check is uniquely identified by the purpose it serves, the for-code, and the function that performs it.

• ACTIVITY_QA_CHECK_ID — Surrogate primary key, uniquely identifying each QA check record.
• ACTIVITY_QA_CHECK_FOR_ID — Unique QA check code used across systems; foreign key to AMS_STATUS_ORDER_RULES.
• ARC_ACTIVITY_QA_CHECK_FOR — Purpose the QA check is conducted for; part of the business-key unique index.
• PACKAGE_NAME — The PL/SQL package implementing the check logic.
• FUNCTION_NAME — The specific function invoked within that package; part of the business key.
• WARNING_ONLY_FLAG — Determines whether a failing check raises only a warning versus blocking the action.
• ENABLED_FLAG — Indicates whether the check is active or suppressed.
• STATUS_CODE — Current lifecycle status of the QA check.
• DESCRIPTION — Free-text description (up to 4000 characters) of the check.
• OBJECT_VERSION_NUMBER — Optimistic locking version column.
• SECURITY_GROUP_ID — Supports hosted/multi-tenant environments; foreign key to FND_SECURITY_GROUPS.
• WHO columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN for standard audit tracking.

Common Use Cases and Queries

Typical use cases include diagnosing why a marketing activity cannot be approved, auditing which checks are enabled versus disabled, and reviewing the package/function wiring when customizing QA behavior. A common query lists all enabled checks that can block an activity:

SELECT ACTIVITY_QA_CHECK_ID, ARC_ACTIVITY_QA_CHECK_FOR, PACKAGE_NAME, FUNCTION_NAME, WARNING_ONLY_FLAG
FROM AMS.AMS_ACT_QA_CHECKS
WHERE ENABLED_FLAG = 'Y';

To locate a specific check by its business key, developers query on the U2 index columns. To trace a check back to its status-order rule binding, join through ACTIVITY_QA_CHECK_FOR_ID to AMS_STATUS_ORDER_RULES. Reporting often focuses on the WARNING_ONLY_FLAG to distinguish advisory warnings from hard validation failures during campaign submission.

Related Objects

• AMS.AMS_STATUS_ORDER_RULES — Referenced by ACTIVITY_QA_CHECK_FOR_ID; defines the status-ordering rule a check is bound to.
• FND_SECURITY_GROUPS — Referenced by SECURITY_GROUP_ID; governs hosted-environment data segregation.
• AMS.AMS_ACT_QA_CHECKS_U1 / _U2 / _N1 — Unique and nonunique indexes supporting primary key, business key, and lookup access paths.
• AMS activity and campaign tables — Consumer objects whose approval workflows invoke the QA check packages and functions registered here.
• PL/SQL packages named in PACKAGE_NAME — Runtime implementation objects executed when each QA check fires.