Search Results xnp_sv_audits_uk2




Overview

The XNP_SV_AUDITS table is a core data object within the Oracle E-Business Suite (EBS) Number Portability (XNP) module. It functions as the central repository for all subscription audit requests issued by a service provider (SP). In the context of telecommunications number portability, a subscription audit is a formal request from one service provider to another to verify the accuracy of subscriber information and porting eligibility. This table tracks the lifecycle and details of these audit transactions, serving as a critical audit trail and a parent record for related discrepancy and failure data. Its role is essential for maintaining regulatory compliance and ensuring the integrity of the number porting process within the EBS system.

Key Information Stored

The table's structure is designed to uniquely identify and describe each audit request. Its primary key is the system-generated SV_AUDIT_ID. Crucially, the table enforces two unique constraints that highlight critical business keys. The XNP_SV_AUDITS_UK1 constraint is on the OBJECT_REFERENCE column, which typically stores a unique external identifier or reference number for the audit transaction, such as a porting request ID. The XNP_SV_AUDITS_UK2 constraint is a composite key on SP_ID and STARTING_NUMBER, linking the audit to the specific service provider and the telephone number range being audited. Other significant columns likely include FOR_SP_ID (the foreign service provider to whom the audit is directed), audit status, creation date, and timestamps for tracking the request's progress.

Common Use Cases and Queries

Primary use cases involve tracking audit status, investigating discrepancies, and generating compliance reports. A common query pattern retrieves all audits for a specific service provider and status. For example, to find pending audits for SP_ID 1001:

  • SELECT sv_audit_id, object_reference, starting_number FROM xnp_sv_audits WHERE sp_id = 1001 AND status = 'PENDING';

Given the user's search for "object_reference," a frequent reporting need is to locate a specific audit transaction using its external reference:

  • SELECT * FROM xnp_sv_audits WHERE object_reference = '<external_ref>';

Another critical use case is joining with child tables to analyze audit outcomes, such as identifying audits with associated discrepancies for further investigation.

Related Objects

The XNP_SV_AUDITS table has defined relationships with several other key Number Portability tables, as per the provided metadata. It is a parent table to XNP_AUDIT_DISCREPANCIES and XNP_AUDIT_SMS_FAILURES via the AUDIT_ID foreign key, storing detailed results and communication failures for each audit. It references the XNP_SERVICE_PROVIDERS table twice: once via SP_ID (the auditing provider) and once via FOR_SP_ID (the provider being audited). This network of relationships underscores its central role in the audit workflow, where it acts as the hub connecting service provider details with the granular results of the audit process.