Search Results ams_account

Overview

APPS.AMS_TAR_ACCOUNT_V is a reporting view within the Oracle E-Business Suite Marketing (AMS) module, historically associated with the TeleSales / telesales Account-Referral (TAR) functionality. The view presents a consolidated, denormalized picture of account and contact information sourced from Oracle Marketing list entries. Rather than requiring report authors and integrators to join multiple marketing and party tables manually, the view flattens customer identity, party relationships, address data across multiple address purposes, and list-management attributes into a single relational shape.

The view's role is primarily read-only. It is intended for reporting, extract, and integration scenarios where account profiles linked to marketing list entries must be surfaced. Because it exposes generic column names such as COL1 through COL53 mapped to meaningful aliases, it was typically produced by a marketing campaign or telesales setup that mapped imported list data into Oracle Marketing list entries. Its presence in the APPS schema means it is available across the standard EBS 12.1.1 and 12.2.2 environments and can be queried through any tool that connects as an APPS-privileged user, including Oracle Reports, BI Publisher, OBIEE, and custom SQL.

Underlying Base Objects

Per the documented ETRM metadata for 12.2.2, the view's owner is APPS and its only referenced base object is the synonym AMS_LIST_ENTRIES. The underlying table AMS_LIST_ENTRIES stores the individual records belonging to a marketing list, including the mapped import columns (COL1 through COL53) that carry the source system's account and contact attributes. The view therefore functions as a presentation layer over that single table.

Each row returned by the view corresponds to one list entry, uniquely identified by LIST_ENTRY_ID, within a parent LIST_HEADER_ID. Additional control columns—OBJECT_VERSION_NUMBER, LIST_SELECT_ACTION_ID, SOURCE_CODE, ENABLED_FLAG, and the various flag columns (MANUALLY_ENTERED_FLAG, MARKED_AS_DUPLICATE_FLAG, MARKED_AS_RANDOM_FLAG, PART_OF_CONTROL_GROUP_FLAG)—are passed through from the base list entry record and reflect the provenance and status of the record within its marketing list.

Key Columns

• Account identity: ACCOUNT_NAME, ACCOUNT_NUMBER, MAJOR_ACCOUNT_NUMBER, STATUS, CUSTOMER_TYPE, CUSTOMER_CLASS_CODE, and the activation, establishment, and termination dates describing the account lifecycle.
• Party linkage: PARTY_ID ties the list entry back to the Oracle Trading Community Architecture (TCA) party, enabling joins to HZ_PARTIES and related party tables for authoritative customer data.
• Bill-to, ship-to, contact, and guarantor blocks: Each block supplies name, title, suffix, name type, and a full address (address lines 1–4, city, state, postal code, country). The duplicate structures allow the view to report a single record against multiple address roles.
• List-management columns: LIST_ENTRY_ID, LIST_HEADER_ID, LIST_ENTRY_SOURCE_SYSTEM_ID, LIST_ENTRY_SOURCE_SYSTEM_TYPE, SOURCE_CODE, VIEW_APPLICATION_ID, LIST_SELECT_ACTION_ID, ARC_LIST_SELECT_ACTION_FROM, and ARC_LIST_USED_BY_SOURCE are used to trace the entry to its source marketing list and selection action.
• Quality and control flags: MANUALLY_ENTERED_FLAG, MARKED_AS_DUPLICATE_FLAG, MARKED_AS_RANDOM_FLAG, PART_OF_CONTROL_GROUP_FLAG, and ENABLED_FLAG support data-quality screening and control-group analysis within campaigns.
• Other identifiers: PIN_CODE and CELL_CO are available for territory/telephony context and cellular contact attributes where populated by the import process.

Common Use Cases and Queries

The view is used to export account and contact profiles attached to a marketing list, to reconcile imported list entries against TCA parties, and to build deduplication or control-group reports.

Example: list all accounts belonging to a given marketing list with their bill-to name and address:

• SELECT list_header_id, list_entry_id, account_number, account_name, bill_to_name, bill_to_city, bill_to_state, bill_to_country FROM apps.ams_tar_account_v WHERE list_header_id = :p_list_header_id AND enabled_flag = 'Y';

Example: identify duplicate records for review:

• SELECT list_entry_id, account_number, party_id FROM apps.ams_tar_account_v WHERE marked_as_duplicate_flag = 'Y';

Example: join to TCA to validate party existence:

• SELECT v.account_number, v.account_name, p.party_name FROM apps.ams_tar_account_v v, hz_parties p WHERE v.party_id = p.party_id;

Because the view exposes only pass-through columns from AMS_LIST_ENTRIES and no base-table joins, queries against it are generally inexpensive, though filtering on list_header_id or list_entry_id is recommended to limit scan volume.