Search Results competitor_flag




Overview
Explore in AI Chat

Overview

The AS_ALL_CUSTOMERS_V view belongs to the AS - Sales Foundation product family in Oracle E-Business Suite. It is documented as the "All customers view," providing a consolidated, read-only projection of customer master records that can be consumed by reporting tools, concurrent programs, and integration interfaces. Because it flattens the core customer registry together with a decoded lookup value, it offers a convenient single-source snapshot of customer identity, classification, and descriptive attributes without requiring the caller to join supporting reference tables.

This object is a database view rather than a stored table. The ETRM metadata indicates it is not implemented in this database, meaning its presence depends on the specific installation and applied product patches. Where it exists, it plays the role of a reporting convenience layer over the sales foundation customer model, suitable for inbound/outbound interface staging and ad hoc analysis. Users searching on competitor_flag are typically attempting to isolate or classify customers that are also flagged as competitors, a governance concern in sales and credit processing.

Underlying Base Objects

According to the documented view definition, AS_ALL_CUSTOMERS_V is defined over two underlying objects:

  • RA_CUSTOMERS — the primary customer master table in Oracle Receivables/Sales Foundation, aliased as CUST. It supplies all identity, status, classification, and descriptive attribute columns.
  • AR_LOOKUPS — the Receivables lookup table, aliased as LOOK1. It is joined to resolve the customer prospect code into a user-facing meaning.

The join is an outer join: CUST.CUSTOMER_PROSPECT_CODE = LOOK1.LOOKUP_CODE(+) with the filter LOOK1.LOOKUP_TYPE(+) = 'CUSTOMER_PROSPECT_CODE'. The (+) notation preserves customers that have no matching lookup row, so customers lacking a configured prospect code still appear with a null decoded meaning. No other base objects are documented in the ETRM metadata.

Key Columns

  • CUSTOMER_ID / CUSTOMER_KEY — surrogate and business keys identifying the customer party.
  • CUSTOMER_NAME / CUSTOMER_NUMBER — the display name and the human-assigned customer account number.
  • CUSTOMER_STATUS_CODE — the current active/inactive state of the customer record.
  • TAX_REFERENCE — the customer's tax registration reference.
  • SIC_CODE — Standard Industrial Classification code describing the customer's industry.
  • CUSTOMER_PROSPECT_CODE — the raw code denoting prospect vs. existing customer.
  • MEANING — the decoded description of the prospect code, sourced from AR_LOOKUPS.
  • COMPETITOR_FLAG — the indicator central to the user's search; identifies whether the party is flagged as a competitor, enabling exclusion or special handling.
  • ATTRIBUTE_CATEGORY / ATTRIBUTE1–15 — the flexible descriptive flexfield segments for customer-defined extensions.

Note that the column list also references a CUSTOMER_PROSPECT alias alongside the prospect code, and CUSTOMER_STATUS_CODE appears in the column list though the projection text shows STATUS. These naming nuances reflect the view's exposure of the underlying customer status.

Common Use Cases and Queries

Typical scenarios include customer data extracts, competitor screening, prospect reporting, and validation feeds for downstream systems. Because the view pre-joins the lookup, it reduces query complexity for report developers.

To list all customers flagged as competitors:

SELECT customer_id, customer_name, customer_number, competitor_flag FROM as_all_customers_v WHERE competitor_flag = 'Y';

To report active customers by prospect classification, decoding the lookup via the view:

SELECT customer_prospect_code, meaning, COUNT(*) FROM as_all_customers_v WHERE customer_status_code = 'A' GROUP BY customer_prospect_code, meaning;

To export customers with their flexfield attributes:

SELECT customer_number, customer_name, attribute_category, attribute1, attribute2 FROM as_all_customers_v ORDER BY customer_name;

Consumers should verify the view's availability in their environment, since ETRM notes it may not be implemented, and should account for possible nulls in MEANING arising from the outer join to AR_LOOKUPS.