Search Results soa_create_don_port_order

Overview

XNP_CORE is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It sits within the XNP module, which supports telecommunications service provider operations, including number portability, service provider routing, number ranges, and service-area provisioning. The package carries a status of VALID and an API classification of OTHER, indicating that it is an internal implementation package rather than a formally published public API. Its role is to centralize shared business logic and data access routines that other XNP packages depend upon. The dependency metadata shows that XNP_CORE references only SYS.STANDARD, while it is referenced by XNP_CVU_PKG, XNP_FA_CB, XNP_STANDARD, XNP_UTILS, and XNP_WF_STANDARD. This dependency pattern confirms its position as a foundational utility layer consumed across the XNP subsystem.

Key Procedures and Functions

The ETRM 12.2.2 metadata documents 66 procedures and functions. The named entry points fall into distinct functional groups:

• Service provider and SOA resolution: GET_SOA_SV_ID and GET_SMS_SV_ID resolve the service provider or service value identifiers used by SOA (service order administration) and SMS (short message service) processing, while GET_NUMBER_RANGE_ID and GET_PHASE_FOR_STATUS retrieve supporting reference identifiers and lifecycle phase values.
• Order creation for portability: SOA_CREATE_REC_PORT_ORDER, SOA_CREATE_DON_PORT_ORDER, and SOA_CREATE_NRC_PORT_ORDER create recipient, donor, and number-range-change port orders respectively, driving the number portability workflow.
• Order and status maintenance: SOA_UPDATE_CUTOFF_DATE, SOA_UPDATE_OLD_SP_DUE_DATE, SOA_UPDATE_SV_STATUS, and SOA_RESET_SV_STATUS manage order dates and service status transitions, including status rollback.
• Validation and phase checking: SOA_CHECK_NOTIFY_DIR_SVS, SOA_CHECK_IF_INITIAL_DONOR, CHECK_SOA_STATUS_EXISTS, CHECK_DONOR_PHASE, and CHECK_RECIPIENT_PHASE validate that donor and recipient phases and notification conditions are satisfied before processing continues.
• SMS feature mapping: SMS_INSERT_FE_MAP and SMS_DELETE_FE_MAP maintain the mapping between SMS service values and front-end identifiers, while SMS_CREATE_PORTED_NUMBER registers ported numbers in the SMS domain.
• Charging: SOA_UPDATE_CHARGING_INFO updates charging attributes associated with service orders.

Tables Accessed

XNP_CORE reads and writes the core XNP configuration and transactional tables through APPS synonyms. XNP_SERVICE_PROVIDERS, XNP_SERVED_NUM_RANGES, XNP_NUMBER_RANGES, and XNP_GEO_HIERARCHY provide service provider, number range, and geographic hierarchy reference data. XNP_ROUTING_NUMBERS and XNP_ROUTING_NUMBERS_S store routing number definitions and their translation rows. XNP_SERVICE_AREAS and XDP_FES support service-area and feature-element mapping. Transactional state is held in XNP_SV_EVENT_HISTORY and XNP_SV_EVENT_HISTORY_S, XNP_SV_ORDER_MAPPINGS and XNP_SV_ORDER_MAPPINGS_S, and XNP_SV_SMS with XNP_SV_SMS_FE_MAPS and XNP_SV_SMS_FE_MAPS_S. The "_S" tables are date-tracked translations of their base tables, consistent with EBS MLS conventions.

Usage Notes

XNP_CORE is not designed for direct invocation by end users or external integrations. It is called programmatically by the XNP packages that reference it, including XNP_STANDARD, XNP_UTILS, XNP_CVU_PKG, XNP_FA_CB, and XNP_WF_STANDARD, and is typically reached through SOA and SMS service-order flows, including workflow-driven processing via XNP_WF_STANDARD. Customizations should treat the package as internal: rather than calling XNP_CORE procedures directly, developers should invoke the higher-level XNP packages or supported APIs and allow XNP_CORE to be reached through them. Because the package writes to date-tracked and history tables, it participates in standard EBS concurrency and audit behavior, and any direct use requires careful attention to transaction boundaries and validation ordering.