Results for “as_tap_accounts_v”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

AS_TAP_ACCOUNTS_V is an APPS-owned database view in the Oracle E-Business Suite Sales Foundation (AS) product family. Its documented description is "For TAP use," indicating that it exists to support the TAP (Territory Assignment/Account Planning) functionality within Sales Foundation rather than to serve as a general-purpose reporting object. The view consolidates party, party site, location, and contact point attributes into a single denormalized result set, presenting account-level information drawn from the Oracle Trading Community Architecture (TCA) model. In Oracle EBS 12.1.1 and 12.2.2, the view is listed with a status of VALID and is resolved through the APPS schema, meaning it depends on public synonyms that point to the underlying TCA tables.

Because AS_TAP_ACCOUNTS_V sits on top of TCA customer and prospect data, it is relevant to any query seeking organization-level attributes such as employee headcount, SIC classification, DUNS number, and geographic location. The employees_total column that led to this search is one of the party-level attributes propagated by the view.

Underlying Base Objects

The documented base objects referenced by the view are:

• HZ_PARTIES — the master entity table holding party name, party type, category code, SIC code, DUNS number, and employees_total.
• HZ_PARTY_SITES — the association between a party and a physical address, filtered to active (STATUS = 'A') sites.
• HZ_LOCATIONS — the address detail providing city, country, county, state, province, and postal code.
• HZ_ORGANIZATION_PROFILES — organization-level profile data, including preferred functional currency and current fiscal year potential revenue.
• HZ_CONTACT_POINTS — contact point data, from which the phone area code is exposed.

The view text joins these objects with hash-join and parallel hints, reflecting its design for set-based batch processing rather than interactive single-row lookups. It fans out a party/site/location subquery (UNION ALL) with organization profiles and contact points, so a party with multiple active sites or multiple contact points can generate multiple result rows.

Key Columns

• PARTY_ID / PARTY_SITE_ID — identifiers of the party and, where present, the specific party site.
• PARTY_NAME, PARTY_NAME_SUBSTRING — the party name and its leading character, both uppercased.
• EMPLOYEES_TOTAL — the total number of employees recorded on HZ_PARTIES for the organization.
• SIC_CODE_TYPE and SIC_CODE — concatenated into a single uppercase classification string.
• DUNS_NUMBER_C — the D-U-N-S number for the party.
• CATEGORY_CODE — the party category, uppercased.
• CITY, COUNTRY, COUNTY, STATE, PROVINCE, POSTAL_CODE — geographic attributes from HZ_LOCATIONS.
• PREF_FUNCTIONAL_CURRENCY — the organization's preferred functional currency from HZ_ORGANIZATION_PROFILES.
• CURR_FY_POTENTIAL_REVENUE — the potential revenue for the current fiscal year.
• PHONE_AREA_CODE — derived from HZ_CONTACT_POINTS.

Common Use Cases and Queries

A typical use is to list accounts together with their headcount for territory or account planning. Note that the alias exposed for the headcount column is EMPLOYEES_TOTAL.

SELECT party_id,
       party_name,
       employees_total,
       city,
       state,
       country,
       sic_code_type,
       pref_functional_currency
FROM   apps.as_tap_accounts_v
WHERE  employees_total > 500
ORDER  BY party_name;

A second common pattern is aggregation by geography or category:

SELECT country, state,
       COUNT(DISTINCT party_id) AS accounts,
       SUM(employees_total) AS total_emps
FROM   apps.as_tap_accounts_v
GROUP  BY country, state
ORDER  BY accounts DESC;

Because the view performs multi-table hash joins and may duplicate parties across sites, queries should apply DISTINCT where only unique parties are required, and should be filtered before aggregation to limit the parse and execution cost.