Results for “security_id”

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

Overview

APPS.ASF_PERSONS_QF_V is a reporting and integration view in the Oracle E-Business Suite ASF – Sales Online product family. Its documented purpose is to support a "Person Quick Find" — a lightweight, denormalized lookup of person records used by sales-facing forms and search utilities to retrieve party information without navigating the full Trading Community Architecture (TCA) model. The view is owned by the APPS schema and carries a status of VALID in both Oracle EBS 12.1.1 and 12.2.2, indicating that it is a supported, compiled object in the EBS data dictionary.

Because the view narrows its source data to party type PERSON and only the A (active) and I (inactive) statuses, it presents a curated slice of the HZ_PARTIES population rather than the full party registry. This makes it well suited to Quick Find style lookups, where users search by name fragments or identifiers and expect a concise, human-readable result set that includes address and contact information in a single row. The view is not a transactional object; it functions as a read-only projection for query, reporting, and integration consumption.

Underlying Base Objects

The view is defined over a single documented base object: HZ_PARTIES, exposed in the APPS schema via a synonym. All columns returned by ASF_PERSONS_QF_V originate from the HZ_PARTIES alias PRSN. There are no joins, unions, or subqueries in the documented view text — it is a straightforward filter-and-project operation. The relationship is therefore strictly one-to-many-to-one: each row in the view corresponds to exactly one qualifying row in HZ_PARTIES. This simplicity is deliberate; Quick Find views are optimized for fast retrieval rather than for completeness of the TCA relationship graph, which would require joins to HZ_CUST_ACCOUNTS, HZ_LOCATIONS, HZ_CONTACT_POINTS, and related entities.

The filtering predicates are PARTY_TYPE = 'PERSON' and STATUS IN ('A','I'). Organizations, groups, and other non-person party types are excluded by design, as are parties in any status other than active or inactive. Administrators integrating against this view should note that parties in other lifecycle states will not appear.

Key Columns

• PERSON_ID / PARTY_ID / SECURITY_ID — The view text selects PRSN.PARTY_ID three times in succession, which the documented column list maps to PERSON_ID, PARTY_ID, and SECURITY_ID. This reflects a common EBS convention of aliasing the same surrogate key under multiple semantic names so that legacy forms expecting a "person identifier" or "security identifier" continue to resolve. Users searching for security_id will find that it resolves to the underlying HZ_PARTIES.PARTY_ID value, not to a separate security or role attribute. All three columns carry identical values.
• PERSON_NAME, LAST_NAME, FIRST_NAME, MIDDLE_NAME, PREFERRED_NAME — Human-readable name components sourced from PARTY_NAME, PERSON_LAST_NAME, PERSON_FIRST_NAME, PERSON_MIDDLE_NAME, and KNOWN_AS respectively.
• STATUS_CODE — The party status (A or I), inherited from the view's WHERE clause.
• EMAIL_ADDRESS — The primary e-mail attribute from HZ_PARTIES.
• ADDRESS, ADDRESS1–ADDRESS4, CONCATENATED_ADDRESS — Address components and a single-line concatenation of address lines with city, state, postal code, and country for display purposes.
• STATE, CITY, PROVINCE, COUNTY, POSTAL_CODE, COUNTRY — Geographic attributes for filtering and display.
• LAST_ORDER_DATE, CREATION_DATE, LAST_UPDATE_DATE, CREATED_BY, LAST_UPDATED_BY — Operational and audit columns supporting recency checks and traceability.

Common Use Cases and Queries

The primary use case is quick lookup of persons by name or identifier from a sales order entry form or a customized search page. A typical query filtering on the surrogate key is:

SELECT person_id, party_id, person_name, email_address, concatenated_address
FROM   apps.asf_persons_qf_v
WHERE  security_id = :p_party_id;

Alternatively, callers may search by name fragments:

SELECT person_id, person_name, status_code
FROM   apps.asf_persons_qf_v
WHERE  UPPER(person_name) LIKE UPPER(:p_name) || '%'
ORDER  BY person_name;

Because only active and inactive persons are returned, no additional status predicate is required. Integrations should treat the three key columns as synonymous and rely on PERSON_ID as the authoritative identifier. The view is read-only and should not be used for DML; updates must target HZ_PARTIES through supported TCA APIs.