Search Results search_customers




Overview

ARW_SEARCH_CUSTOMERS is an Oracle Applications (APPS) PL/SQL package that provides the customer search infrastructure used by the Oracle Receivables user interface. Its primary responsibility is to resolve user-supplied search criteria into a set of matching customer accounts, account sites, and site uses that a Receivables form or self-service page can then display. The package is central to the "find customer" experience: rather than issuing a single monolithic query, it materialises intermediate search results into a global temporary table, AR_CUST_SEARCH_GT, and then iteratively refines those rows into the account and site-level records the caller requires. In Oracle EBS 12.1.1 and 12.2.2 the object is documented in the ETRM repository as OWNER=APPS, STATUS=VALID, and is classified as a custom or non-standard "OTHER" API. It is referenced by ARW_SEARCH_CUSTOMERS_W (a wrapper package) and by itself, and it in turn depends on the ARI_CUSTOMER_SEARCH_V view as well as the TCA customer tables HZ_CUST_ACCOUNTS, HZ_CUST_ACCT_SITES, and HZ_CUST_SITE_USES. Because the transaction model of TCA separates parties, accounts, sites, and site uses, the package exists to join these layers efficiently and to cache the heavyweight results for reuse.

Key Procedures and Functions

The ETRM metadata documents six procedures or functions within the package. SEARCH_CUSTOMERS is the principal entry point exposed to callers; it accepts the user's search string and options and drives the overall search workflow. ARI_SEARCH is the internal search routine that populates and queries AR_CUST_SEARCH_GT with candidate matches. INITIALIZE_ACCOUNT_SITES prepares the account-site result set for a selected customer account, effectively resetting or seeding the working structures before site data is gathered. INIT_ACCT_SITES_ANON_LOGIN performs the equivalent initialisation for an anonymously logged-in (self-service) user, where the identity context differs from an authenticated internal user. UPDATE_ACCOUNT_SITES refreshes or recalculates the account-site rows associated with the current search. INSERT_ACCT_SITE_USES writes the individual site-use records (for example, bill-to, ship-to, statement, or dunning uses) that belong to each account site. Together these routines form a search-then-drill-down pipeline: search the customer, resolve the accounts, then resolve the sites and their uses.

Tables Accessed

The package reads customer master data from AR_CUST_SEARCH_GT, a global temporary table that holds the intermediate and final search results for the current session. HZ_CUST_ACCOUNTS supplies the customer account records; HZ_CUST_ACCT_SITES supplies the account-site associations; and HZ_CUST_SITE_USES supplies the site-use classifications. The ARI_CUSTOMER_SEARCH_V view provides the pre-joined searchable projection of these TCA entities. Additional documented references include AR_IREC_USER_ACCT_SITES_ALL, which restricts results for Internet Receivables (iReceivables) users to the sites they are authorised to access, FND_USER for the identity of the logged-in user, and the location and party entities HZ_LOCATIONS, HZ_PARTIES, and HZ_PARTY_SITES for address and party resolution. RA_CUSTOMER_TRX is referenced for transaction-related context. The PLITBLM and SCORE objects are infrastructure dependencies used for temporary table and scoring/ranking support.

Usage Notes

ARW_SEARCH_CUSTOMERS is not a public, supported API in the sense of an AR or HZ PL/SQL interface. It exists to serve the Receivables customer search UI, and its behaviour is tightly coupled to AR_CUST_SEARCH_GT and to the current session state. Because the metadata classifies it as OTHER and documents AR_CUST_SEARCH_GT as a global temporary table, the package must be invoked within the same database session that consumes the results; the temporary rows are not visible outside that session. Typical invocation is from the Receivables "Find Customer" forms, from iReceivables self-service search pages (hence the anonymous-login initialisation routine), and from the ARW_SEARCH_CUSTOMERS_W wrapper, which is the object most external code should reference if integration is unavoidable. Because the search results are staged in a temporary table and the internal routines are unnamed in stable public contracts, the package is best treated as an internal implementation detail. Customisations should not call it directly; a supported alternative is to query the TCA views and the public HZ customer APIs that back the same tables. Database upgrades and patches may change the package body without notice, so any direct dependency risks breakage.