Search Results get_matching_party_sites_5

Overview

HZ_PARTY_SEARCH_W is a wrapper package body owned by the APPS schema in Oracle E-Business Suite. It belongs to the Oracle Trading Community Architecture (TCA) / Oracle Customers Online (OCO) family of objects and functions as a PL/SQL entry point for the party and person search infrastructure used by the Customer Relationship Management (CRM) and Master Data Management (MDM) layers. The "_W" suffix indicates that the package is a wrapper that marshals complex, PL/SQL-array-based search parameters between the Oracle Forms user interface layer and the core search engine implemented in HZ_PARTY_SEARCH. It shields callers from the low-level table types (JTF_VARCHAR2_TABLE_*, JTF_NUMBER_TABLE, JTF_DATE_TABLE) that the underlying search API requires, and it depends directly on HZ_PARTY_SEARCH, FND_API, and the JTF collection types. The documented status is VALID, with an API classification of OTHER, and the package is not referenced by any other database object, confirming its role as a top-level entry point rather than a shared internal library.

Key Procedures and Functions

The ETRM metadata documents 28 procedures and functions within the package body. These fall into two functional groups.

• ROSETTA_TABLE_COPY_IN_P5 through ROSETTA_TABLE_COPY_OUT_P12 — a series of paired "copy-in" and "copy-out" routines numbered across parameter blocks. These implement the "Rosetta" translation mechanism that converts the flat, form-friendly search criteria and result arrays into the strongly typed JTF collection structures consumed by HZ_PARTY_SEARCH, and converts the returned heterogeneous collections back into arrays the caller can render. The odd/even pairing shown in the metadata (IN_P5 with OUT_P5, IN_P6 with OUT_P6, and so on through P12) reflects mirrored marshalling for each Rosetta parameter block.
• FIND_PARTIES_1 and FIND_PARTIES_2 — named party-search entries, each representing a distinct search variant (for example, organization versus person or different match rule sets).
• FIND_PERSONS_3 — a person-specific search entry that applies person-level matching criteria.
• GET_MATCHING_PARTY_SITES_4 and GET_MATCHING_PARTY_SITES_5 — retrieve party site records (addresses and location assignments) that match the search criteria established by the preceding find operations.
• GET_MATCHING_CONTACTS_6 — retrieves contact records associated with matched parties, supporting the contact-centric search flows of Oracle Customers Online.

Tables Accessed

The only table documented as referenced by this package (through an APPS synonym) is PLITBLM. PLITBLM is the standard Oracle Forms/PL/SQL table used for persistent storage and passing of PL/SQL table values between forms and stored program units. Its presence confirms that HZ_PARTY_SEARCH_W is designed for interactive, form-driven invocation where search criteria and result sets must be persisted across form interactions. The actual party, person, party site, and contact data resides in the HZ_ tables and is accessed indirectly through the dependent HZ_PARTY_SEARCH package.

Usage Notes

HZ_PARTY_SEARCH_W is not invoked by any other database object, so it is called directly by the presentation layer. Typical callers include Oracle Forms-based user interfaces for TCA party search (such as the Customers and Contacts search screens in Oracle Customers Online), custom Forms or OAF pages that embed party search, and bespoke PL/SQL that needs the same marshalling behaviour for JTF-collection parameters. Because the Rosetta copy-in/copy-out routines are tightly bound to the parameter numbering expected by HZ_PARTY_SEARCH, the package should be treated as an internal implementation construct: new development should call HZ_PARTY_SEARCH directly where possible, and any extension of HZ_PARTY_SEARCH_W should preserve the existing parameter-block contract. The package is valid and supported in both EBS 12.1.1 and 12.2.2.