Search Results get_alladdress_lines

Overview

APPS.PO_HR_LOCATION is a PL/SQL package within the Oracle E-Business Suite Purchasing (PO) module that abstracts address retrieval logic for purchasing documents. Its principal purpose is to resolve a location identifier into a fully formatted, printable address suitable for inclusion on purchase orders, request-for-quotation documents, and supplier communication output. The package header carries the version marker $Header: POXPRPOS.pls 120.3 2007/02/15, indicating it was extended as part of the R12 PO/OTM integration and the FPJ (Fulfillment Processing) PO Communication enhancement initiative. Because purchasing documents must render addresses in jurisdiction-specific formats, the package encapsulates the joins across HR and Trading Community (HZ) location models, territory lookups, and descriptive flexfield attributes rather than requiring each calling program to reconstruct that logic. It is classified under ETRM as an OTHER API, meaning it is not a public, fully supported interface but is nonetheless widely referenced by other Purchasing packages and by custom extensions.

Key Procedures and Functions

The ETRM metadata documents four named program units, several of which exist as overloaded variants of GET_ADDRESS introduced specifically to support the PO Communication enhancement.

• GET_ADDRESS — The core address resolution routine. Multiple overloaded signatures exist so that callers may request either a structured, component-by-component address (address lines, town or city, state or province, postal code, territory short name, and ISO territory code) or a simpler set of address lines plus a single pre-formatted address string. Change history preserved in the header records the incremental addition of out parameters for city, postal code, state or province, and a fourth address line.
• GET_ALLADDRESS_LINES — Returns the complete set of address lines for a given location, allowing callers to iterate or render an arbitrary number of lines without imposing a fixed, hard-coded column count.
• POPULATE_GT — Populates the global temporary table PO_ADDRESS_DETAILS_GT, providing a set-based staging mechanism so that address data for many locations can be materialized and joined in a single SQL statement rather than fetched row by row.
• GET_FORMATTED_ADDRESS — Produces a single, display-ready address string assembled according to the formatting conventions of the location's territory, which is the form most commonly required for printing on purchasing output.

Tables Accessed

The package reads across the HR and Trading Community location models and the standard reference tables that qualify them.

• HR_LOCATIONS_ALL — The primary source of the location record, supplying address lines, city, and postal attributes for a given location identifier.
• HZ_LOCATIONS — The Trading Community location entity, consulted to reconcile the HR location model with the party/party-site model used by suppliers and customers.
• FND_TERRITORIES and FND_TERRITORIES_TL — Provide the territory short name and ISO territory code, with the translated table supplying the language-specific territory description.
• FND_LOOKUP_VALUES — Resolves lookup-coded values, such as territory or address-style indicators, into their displayable meanings.
• PO_ADDRESS_DETAILS_GT — A global temporary table populated by POPULATE_GT and consumed by callers performing set-based address processing.
• PLITBLM — An internal PL/SQL table used for in-memory collection handling within the package.

Usage Notes

PO_HR_LOCATION is invoked indirectly by Purchasing forms and concurrent programs whenever a document must display or print a ship-to, bill-to, or supplier address; the ETRM metadata records three other packages referencing it, confirming its role as a shared internal utility rather than an entry point. Custom code should call the overload that matches the required output shape, preferring GET_FORMATTED_ADDRESS when a single printable string suffices and the structured overload when individual components are needed for validation, comparison, or interface staging. Because the package is classified as OTHER and is not a published API, direct invocation from customizations carries upgrade risk; developers should favor the documented overloads, avoid depending on internal helpers such as PLITBLM, and verify signature stability after applying patches or upgrading between 12.1.1 and 12.2.2.