Search Results hz_format_phone_v2pub




Overview
Explore in AI Chat

Overview

HZ_FORMAT_PHONE_V2PUB is a public PL/SQL package body owned by the APPS schema within the Oracle E-Business Suite Trading Community Architecture (TCA) module. Its purpose is to centralize the logic required to parse, validate, format, and display telephone numbers for parties, contacts, and contact points stored in the TCA registry. Telephone data in EBS is subject to widely varying national conventions—country codes, area codes, mobile prefixes, and presentation masks—and this package applies the configuration held in the TCA phone reference tables so that a single number can be stored canonically while being rendered appropriately for each locale or channel. Because it is classified as a public (V2PUB) API, it is intended to be callable from outside the owning module, allowing forms, concurrent programs, and custom extensions to reuse consistent phone handling rather than reimplementing it. The package body is documented as VALID in both Oracle EBS 12.1.1 and 12.2.2 and depends on standard TCA and foundation utilities including FND_API, FND_GLOBAL, FND_MESSAGE, FND_MSG_PUB, FND_LOG, HZ_UTILITY_V2PUB, and HZ_PREFERENCE_PUB.

Key Procedures and Functions

The ETRM metadata documents six procedures and functions in the package body. Their names and purposes are as follows.

  • PHONE_PARSE — Decomposes a raw telephone number string into its constituent components, such as country code, area code, exchange, and local number, using the configured phone format definition for the applicable country. Parsing is the prerequisite step that allows a number to be validated and later reassembled in a normalized or display form.
  • PHONE_DISPLAY — Produces a formatted, human-readable representation of a stored phone number. This is the routine used when a number must be shown to a user in a particular country's or region's presentation style, drawing on the phone format masks maintained in the TCA reference data.
  • CHECK_MOBILE_PHONE — Determines whether a supplied telephone number qualifies as a mobile number, principally by evaluating it against the configured mobile prefix ranges. This supports downstream processes that need to distinguish mobile numbers from landlines, for example for messaging or contact-preference logic.
  • GET_FORMATTED_PHONE — Returns the formatted phone number for a given contact point or party, orchestrating the parse, validation, and display logic into a single callable entry point. This is the primary convenience function for consumers that need a ready-to-use formatted value rather than the individual primitives.

Two further documented routines complete the set of six; the metadata does not enumerate their individual names, but all four named routines above are the principal public entry points for phone processing.

Tables Accessed

The package body reads and writes the following tables through APPS synonyms.

  • HZ_CONTACT_POINTS — Stores the contact point records, including telephone contact points, that the package formats and returns.
  • HZ_PHONE_FORMATS — Defines the country-specific masks and formatting rules applied by PHONE_PARSE and PHONE_DISPLAY.
  • HZ_PHONE_COUNTRY_CODES — Supplies valid country dialing codes used during parsing and validation.
  • HZ_PHONE_AREA_CODES — Provides area code reference data used to validate and interpret parsed numbers.
  • HZ_MOBILE_PREFIXES — Holds the prefix ranges consulted by CHECK_MOBILE_PHONE to identify mobile numbers.
  • HZ_PARTY_PREFERENCES — Stores party-level preferences, including contact and formatting preferences, that influence how numbers are presented.
  • PLITBLM — A PL/SQL internal table type used for array-style processing within the package.

Usage Notes

HZ_FORMAT_PHONE_V2PUB is typically invoked from TCA-based forms and concurrent programs that create or display party and contact information, and from custom PL/SQL code that needs consistent phone parsing, validation, or display. It is referenced by six other database objects, indicating it is a shared utility within the APPS schema rather than an object called only by its own module. The presence of FND_API, FND_MESSAGE, and FND_MSG_PUB dependencies indicates the package follows the standard EBS API error-handling model, returning status and message information rather than raising unhandled exceptions. FND_GLOBAL is used to obtain session context, and FND_LOG supports debug logging. Because it relies on HZ_PARTY_PREFERENCES and HZ_PREFERENCE_PUB, callers should ensure the relevant party preferences are configured to obtain expected formatting behavior.