Search Results xnp_routing_numbers_s

Overview

XNP_CORE is the central PL/SQL package body within the Oracle EBS Telecommunications/Number Portability (XNP) module, delivered under the APPS schema and classified as an "OTHER" API in the ETRM registry. It implements the foundational business logic that governs telephone number portability operations: validating number ranges, resolving service providers and service areas, orchestrating Service Order Administration (SOA) workflows, and managing the SMS feature-map and event-history infrastructure that supports porting requests. The package is referenced by five other packages, making it a low-level dependency for higher-level XNP functionality. Its most recent header revision (120.2, dated February 2006) confirms the code line has been stable across the 12.1.1 and 12.2.2 releases, with the 12.2.2 documentation now enumerating sixty-six procedures and functions.

Key Procedures and Functions

The documented API surface spans number-range resolution, provider/area lookup, SOA order creation, and SMS mapping maintenance. The procedure the user searched for, GET_NUMBER_RANGE_ID, returns the identifier of the number range that owns a given telephone number, and is the sibling of GET_PHASE_FOR_STATUS, which derives the porting phase. Provider and service-area resolution are handled by GET_SOA_SV_ID, GET_SMS_SV_ID, and the sibling procedures GET_ASSIGNED_SP_ID and GET_SP_ID shown in the source excerpt.

SOA order processing is the largest functional cluster. It includes SOA_CREATE_REC_PORT_ORDER, SOA_CREATE_DON_PORT_ORDER, and SOA_CREATE_NRC_PORT_ORDER for the recipient, donor, and non-recipient/other porting scenarios respectively; SOA_UPDATE_CUTOFF_DATE, SOA_UPDATE_OLD_SP_DUE_DATE, SOA_UPDATE_SV_STATUS, SOA_UPDATE_CHARGING_INFO, and SOA_RESET_SV_STATUS for lifecycle maintenance; and SOA_CHECK_IF_INITIAL_DONOR and SOA_CHECK_NOTIFY_DIR_SVS for validation checks. CHECK_SOA_STATUS_EXISTS, CHECK_DONOR_PHASE, and CHECK_RECIPIENT_PHASE provide guard logic before state transitions.

SMS-related maintenance is exposed through SMS_INSERT_FE_MAP, SMS_DELETE_FE_MAP, and SMS_CREATE_PORTED_NUMBER, which populate and remove the FE map records used to route messaging for ported numbers. The presence of GET_ASSIGNED_SP_ID in the excerpt demonstrates the package's standard error-handling pattern: OPEN/FETCH against an explicit cursor, a NO_DATA_FOUND handler that builds a message via FND_MESSAGE using XNP message names, and a generic WHEN OTHERS handler that captures SQLCODE and SQLERRM into the out parameters.

Tables Accessed

All tables are referenced through APPS synonyms. The number-range domain is served by XNP_NUMBER_RANGES (queried directly by GET_ASSIGNED_SP_ID and, presumably, GET_NUMBER_RANGE_ID), together with XNP_SERVED_NUM_RANGES. Service provider and area data reside in XNP_SERVICE_PROVIDERS, XNP_SERVICE_AREAS, and XNP_GEO_HIERARCHY. Routing numbers are held in XNP_ROUTING_NUMBERS and its _S child. Porting order and status management read and write XNP_SV_ORDER_MAPPINGS (and _S), XNP_SV_EVENT_HISTORY (and _S), and XNP_SV_SMS. The SMS feature-map procedures operate on XNP_SV_SMS_FE_MAPS, XNP_SV_SMS_FE_MAPS_S, and XDP_FES.

Usage Notes

XNP_CORE is not typically called directly by end users. It is invoked by XNP concurrent programs, by the XNP porting request forms and OA Framework pages during number validation and submission, and by the five dependent packages that wrap its lower-level routines. Customizations should call the documented public procedures rather than the private helpers, passing x_error_code and x_error_message out parameters and checking x_error_code = 0 for success. Because the package is common to 12.1.1 and 12.2.2, extensions should be treated as supported customizations using the standard XNP message dictionary for error text.