Search Results as_changed_accounts




Overview
Explore in AI Chat

Overview

AS_CHANGED_ACCOUNTS is a reporting and integration view owned by the APPS schema in Oracle E-Business Suite, classified under the AS - Sales Foundation product family and reported as VALID in both release 12.1.1 and 12.2.2. Its documented description, "Changed accounts (multi-org)," identifies its purpose: it exposes rows from the multi-org change-tracking table in which customer, address, and sales lead account records have been flagged for downstream processing. The view is a central component of the Sales Foundation change-propagation mechanism, which detects modifications to account and party records and stages them so that dependent applications can act on them.

Because the view spans multiple operating units, users must operate within a multi-org–aware session (a valid ORG_ID context) for records to be returned. The view itself does not create change records; it presents rows previously written by triggers and concurrent programs against the underlying table, including the INSERT_FLAG, DELETE_FLAG, and PROCESSED_FLAG indicator columns that drive processing logic.

Underlying Base Objects

The ETRM metadata documents a single referenced base object for this view: the synonym AS_CHANGED_ACCOUNTS_ALL in the APPS schema. The view definition is a direct projection of that synonym:

SELECT CUSTOMER_ID, ADDRESS_ID, LEAD_ID, SALES_LEAD_ID,
       LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY,
       LAST_UPDATE_LOGIN, REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID,
       PROGRAM_UPDATE_DATE, CHANGE_TYPE, INSERT_FLAG, DELETE_FLAG,
       PROCESSED_FLAG, ORG_ID, SEQUENCE
FROM AS_CHANGED_ACCOUNTS_ALL

Since the base object is the "_ALL" (multi-org) table, AS_CHANGED_ACCOUNTS is the organization-stripped layer of the standard Oracle multi-org view pattern. In a typical EBS configuration, AS_CHANGED_ACCOUNTS_ALL holds all operating-unit rows for the entity, and a policy or view mechanism restricts visibility by ORG_ID. The synonym resolves to the underlying AS_CHANGED_ACCOUNTS_ALL table, which is populated as customer, address, lead, and sales-lead records are created, changed, or deleted and must be synchronized across organizations or propagated to external interfaces.

Key Columns

  • CUSTOMER_ID, ADDRESS_ID — Identify the account and its address affected by the change.
  • LEAD_ID, SALES_LEAD_ID — Identify related lead records subject to the same change cycle.
  • INSERT_FLAG — The indicator the user searched for; marks a row as an insertion event requiring a corresponding create in the target system.
  • DELETE_FLAG — Marks the row as a deletion event, driving removal logic in downstream processing.
  • PROCESSED_FLAG — Records whether the change has already been consumed by the processing program, preventing reprocessing.
  • CHANGE_TYPE — Classifies the nature of the change recorded against the account.
  • ORG_ID — The operating unit that owns the change, enforcing multi-org security and routing.
  • SEQUENCE — Orders change rows for deterministic, ordered consumption.
  • REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — Concurrent program context that generated or last updated the row.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — Standard EBS audit columns.

Common Use Cases and Queries

Typical uses include monitoring the change queue for a given operating unit, extracting pending insertions for interfaces, and reconciling change history for audit or troubleshooting. A representative query retrieves unprocessed insertion events for a session's organization:

SELECT customer_id, address_id, lead_id, sales_lead_id,
       change_type, org_id, sequence
FROM   apps.as_changed_accounts
WHERE  insert_flag = 'Y'
AND    processed_flag = 'N'
ORDER  BY sequence;

To review all outstanding work irrespective of change type, the flag columns may be combined:

SELECT *
FROM   apps.as_changed_accounts
WHERE  processed_flag = 'N'
AND   (insert_flag = 'Y' OR delete_flag = 'Y');

Because the view is organization-sensitive, queries executed without a valid multi-org context may return no rows even when the underlying table contains data; this is the most common cause of unexpected empty result sets when users first query AS_CHANGED_ACCOUNTS.