Search Results amw_audit_objectives_b_pk

Overview

The AMW_AUDIT_OBJECTIVES_B table resides in the AMW schema and is a core transactional object within the Oracle E-Business Suite Internal Controls Manager (AMW) module. It stores the audit objectives defined for a given audit engagement, capturing the specific goals and scope against which an engagement is executed and evaluated. In EBS 12.1.1 and 12.2.2, AMW supports the internal control and audit lifecycle — from engagement planning through testing and remediation — and this table anchors the objectives layer of that process.

From a heuristic Data Vault classification mined from the foreign key structure, this table is modeled as a standalone object rather than a hub, link, or satellite. The absence of strong shared-hub patterns to other dimensions suggests it functions as an independent transactional entity keyed on a single surrogate identifier. This classification is a modeling suggestion only and should be validated against actual usage.

Key Information Stored

The table is documented with 28 columns in ETRM 12.1.1. The most significant are:

• OBJECTIVE_ID — the surrogate primary key (constraint AMW_AUDIT_OBJECTIVES_B_PK), uniquely identifying each audit objective record.
• AUDIT_PROJECT_ID — foreign key to AMW_AUDIT_PROJECTS, linking the objective to its parent audit engagement.
• SECURITY_GROUP_ID — foreign key to FND_SECURITY_GROUPS, enforcing multi-org/security partitioning consistent with EBS data security.
• OBJECTIVE_TYPE — classifies the nature of the objective (e.g., control, compliance, operational).
• START_DATE and END_DATE — the effective period over which the objective applies.
• OBJECT_VERSION_NUMBER — optimistic locking column supporting concurrent update integrity.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — standard EBS WHO columns for audit trail and user accountability.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — the DFF (Descriptive Flexfield) block enabling client-specific extensions.

The surrogate primary key is OBJECTIVE_ID; the metadata documents no separate unique business index, so business-key candidates should be inferred from AUDIT_PROJECT_ID combined with OBJECTIVE_TYPE and date ranges rather than from a declared unique constraint.

Common Use Cases and Queries

Typical usage centers on reporting and validating the objective scope of active engagements. Analysts frequently join objectives to their parent project, and developers filter by security group when building custom reports.

SELECT o.OBJECTIVE_ID, o.OBJECTIVE_TYPE,
       o.START_DATE, o.END_DATE
FROM   AMW_AUDIT_OBJECTIVES_B o
WHERE  o.AUDIT_PROJECT_ID = :project_id
  AND  o.SECURITY_GROUP_ID = :sg_id;

Another common pattern retrieves objectives active during a reporting window by evaluating the START_DATE/END_DATE pair. DFF-driven extracts select ATTRIBUTE_CATEGORY and the relevant ATTRIBUTEn column for client-specific analytics. Reconciling objectives against engagements verifies completeness before engagement close.

Related Objects

The most significant related objects, based on documented FK/PK relationships, include:

• AMW_AUDIT_PROJECTS — joined via AUDIT_PROJECT_ID; the parent engagement owning each objective.
• FND_SECURITY_GROUPS — joined via SECURITY_GROUP_ID; governs row-level security.
• AMW_AUDIT_OBJECTIVES_TL — the translated (TL) companion table holding language-specific objective descriptions, keyed by OBJECTIVE_ID.
• AMW audit procedures and workpaper tables that reference objectives for testing and evidence collection.
• FND standard WHO/DFF infrastructure supporting the ATTRIBUTEn and audit-trail columns.

Together these objects form the objective-management layer of AMW, with AMW_AUDIT_OBJECTIVES_B acting as the anchored transactional detail for each audit engagement.