Apparatus and method for facilitating service management of communications services in a communications network6778651Abstract A service management system for a communications network which accepts requests for communications services from service order sources. The service management system includes an interface to the service order sources, a database, and an interface to network elements which provide the communications services. The service order sources may have differing order input formats which are converted by the system into a single internal format for processing and determining of provisioning information to be output to the network-elements. The service management system includes table-driven logic which is used to validate and process the requests to determine the provisioning information. Once the provisioning information is determined, it is queued to the appropriate network element, and an acknowledgment is sent to the originating service order source. The service management system also includes a interface to query the database and network elements to perform debugging and error correction. Claims What is claimed: Description 1. COPYRIGHT NOTICE
AIN Advanced Intelligent Network
AIN-IP Advanced Intelligent Network
Intelligent peripheral
API Application programming Interface
AR Activation Request
ASN.1 Abstract Syntax Notation One
B Build Service Order Type
BOC Bell Operating Company
BOSS Billing Order Support System
BTN Billing Telephone Number
C Change Service Order Type
C0 SMS to SOAC Route Control Header Section
C3 SOAC to SMS Route Control Header Section
CABS Customer Access Billing System
CAN Cancellation Service Order Pass
CAR Cancellation Activation Request
CCS Common Channel Signaling
CDW Corporate Data Warehouse
CID Caller IntelliData .RTM.
CIDB Customer Information Database
CISE SOAC Interface DNS Name
CLOPT Command Line Option
CMISE Common Message Information Services
Element
CNA Customer Network Administrator
CNOC Centralized Network Operations Center
CO Central Office
COM Communications
COMPLEX Refers to a Service that cannot be
Provisioned on a Standard SPACE
Template which is Provisioned
Manually
COR Correction Service Order Pass
CPC Correction Post Completion Service Order
Pass
CPR Call Processing Record
CRIS Customer Records Information System
CTC Control Code within Subscriber Section of
a Service Order
D Disconnect Service Order Type
DAEMON UNIX Background Process
DATAGATE .RTM. Client/Server Communication Software
DB Database
DBMS Database Management System
DCI Distributed Computing Integrator
DD Due Date
DG see DATAGATE .RTM.
DNS Domain Name Server
DRS Data and Reports System
DTMF Dual-Tone Multiple-Frequency
EASE Easy Access Sales Environment .RTM.
ECRS Enhanced Customer Reports System
EO End Office
F From Service Order Type
FCIF Flexible Computing Interface Format
FID Feature Identifier
FIM Feature Interaction Manager
FML Field Manipulation Language
FT AR Flow Through Activation Requests
GOM Generic Order Management
GP Group Section of a Service Order
GUI Graphical User Interface
HOL Historical Order Log
ICF Intelligent Call Forwarding
IMG Image Section of a Service Order
Inward Activity The Addition of AIN Services to an
Account
ISCP Integrated Service Control Point
LSP Local Service Provider
MA AR Manual Assistance Activation Requests
MARCH .TM. Memory Administration Recent Change
MSG Message Section of a SOAC Reply
MVS-WSF2 IBM Multiple Virtual System - Writer
Service Facility
N New Connect Service Order Type
NE Netword Element
NEGACK Negative Acknowledgment
NOC Network Operations Center
NPA Number Plan Area
NXX Central Office Code
OA&M Operations Administration & Maintenance
ODR Order Section of a Service Order
ORDNO Order Number Field
OS Operating System
OSS Operations Support Systems
TO Order Type Field
Outward Activity The Deletion of AIN Services from an
Account
PATROL Vendor Supplied Software Alert System
Used to Issue Messages to Pagers,
etc.
PCIF Personal Computer Interface Between
Customer Personal Computers and the
SMS System
PCN Post Completion Notice Service Order Pass
PCS Pieces Database
PID Positive Identifier
POSACK Positive Acknowledgment
PRE Pre-Completion Service Order Pass
PSTN Public Switched Telephone Netword
R Remove Service Order Type
RCMAC Recent Change Memory Administration
Center
RPC Remote Procedure Call
RSC Resource Section of a Service Order
SBR Subscriber Section of a Service Order
SCA Selective Call Acceptance .RTM.
SCC Service Switching Center
SCE Service Creation Environment
SCP Service Control Point
SDT Software Development Toolkit
SMDR Station Message Detail Recording
SMS Service Management System
SOAC Service Order Assignment Control
SOP Service Order Processor
SOPP Service Order Pre-Processing (also called
Reformat)
SORD Service Order Retrieval and Distribution
System
SPACE Bellcore Service Provisioning and
Creation Environment Network Element
SQL Structured Query Language
SQL Structure Query Language Which is Used to
Manipulate Relational Database
Records and Data
SRU Step Recovery Utility
SS7 Signaling System 7
SSP Service Switching Point
STP Signaling Transfer Point
T To Service Order Type
TAR Track Activation Request
TCAP Transaction Capabilities Applications
Part
TCP/IP Transmission Control Protocol/Internet
Protocol
TIL TOP Interface Library
TIP Transaction Interface Program Service
TN Telephone Number
TOP Transaction Oriented Protocol
TOPCOM TOP Communications
TRN Transaction Number
TSYS Transmitting System
TUXEDO Vendor Supplied Transaction Monitor and
Message Handler
USERLOG A Flat File Containing Various Messages
such as Events or Errors
USOC Uniform Service Order Code
VAD Voice Activated Dialing System
WC Wire Center
WTN Working Telephone Numbers
3. Background and Material Information Traditionally, telephone companies have relied on switch vendors to create new services on central office (CO) switches. Once a switch vendor designed a new service, the telephone companies would market the service to a target audience. A disadvantage of this approach is the length of time required to bring a new service to the market. Typically 3 to 5 years is required to bring a new service to market. In addition, new services need to be re-created for a variety of vendor-specific switches, which may limit the availability of a particular service. Another limitation in the switch-based approach is that the services cannot be customized to a specific customer's needs. In the traditional environment, provisioning of services was performed by Operations Support Systems (OSS). The OSS systems were responsible for mechanizing the flow from ordering to provisioning in switch-based telephony services. In recent years, a number of new telephone service features have been provided by an Advanced Intelligent Network (AIN). The AIN evolved out of a need to increase the capabilities of the telephone network architecture to meet the growing needs of telephone customers. The AIN provides a mechanism by which new services may be created outside of a particular vendor's switch. Each CO in the AIN system is equipped as a Service Switching Point (SSP) which is capable of suspending normal call processing when encountering a "trigger." The trigger invokes AIN service logic associated with a subscriber. Once a call is triggered, the SSP launches a query through a Signal Transfer Point (STP) in a Common Channel Signaling Network (CCS) to a Service Control Point (SCP). The SCP contains the AIN service logic for the particular subscriber and determines how to handle and route the call. Once the SCP processes the call, the SCP sends the appropriate routing instructions through the STP to the SSP, which then routes the call. Intelligent Peripherals (IP) may be provided to process multi-media services such as announcements, voice activated dialing, etc. An illustration of the basic components of an AIN architecture is shown in FIG. 1. As shown in FIG. 1, Service Switching Points. (SSPs) 36 are provided for sending and receiving data messages from a Service Control Point (SCP) or Integrated Service Control Point (ISCP) 30 via Signaling Transfer Points (STPs) 34. The data messages are communicated to and from the SSPs 36 and the SCP 30 along a Common Channel Signaling (CCS) network 44. Each SSP 36 routes telephone calls between telephone stations 50A, 50B, 50C, 50D, 50E, 50F, 50G, 50H, more specifically between a calling station (e.g., station 50A) and a called station (e.g., station 50G) through the trunked communications network 46 and telephone lines 48. Multi-media applications may be processed at the Intelligent Peripheral 28 attached to the SSP. For more information regarding AIN, see Berman, Roger K., and Brewster, John H., "Perspectives on the AIN Architecture," IEEE Communications Magazine, February 1992, pp. 27-32, the disclosure of which is expressly incorporated herein by reference in its entirety. In the AIN environment, service orders typically flow through a Service Order Assignment Control (SOAC) system which is produced by Bellcore. SOAC is the primary source of provisioning updates for mass market AIN services that are initiated through the normal service order process. SOAC sends AIN trigger information to the MARCH.TM. system for automatic switch updates. After the switch is updated, the service order flows to the appropriate billing systems for completion. However, SOAC is limited to provisioning AIN services only, and cannot provision services for non-AIN services. An example of a prior art service management system includes the PACE SMS, manufactured by Digital Switch Corporation. The PACE SMS is described in more detail in the document entitled "MegaHub.RTM. PACE.TM. SMS--Service Management System--Advanced Intelligent Network Systems," DSC Communications Corporation, Issue 0.4, Jul. 17, 1994. The DSC PACE system provided network tools to manage and provision intelligent network services. The PACE.TM. system provides a mechanism for managing service order updates, subscriber version management, provisioning across the AIN network, and service activation. The PACE.TM. system also includes database management capabilities such as update distribution, roll back and roll forward, audits, login security, and data partitioning. The PACE.TM. SMS is limited to the AIN environment only, and does not support an interface to SPACE, an interface to SOAC or existing OSS environments, enhanced security for protection of customer data, and tools for service creation. Also known is a generic service management system deployed by AT&T. The AT&T SMS provides a platform having a set of functions which are re-usable across multiple AIN services and AIN releases, and provides for mass market and complex service management. The AT&T SMS provides a set of configurable, general purpose engines driven by the per-service configurations either by a service package from a Service Creation Environment (SCE) or by customization of the database schema to match a service running in the network element. Like the PACE.TM. SMS, the AT&T SMS is limited to the AIN environment only, does not fully support existing OSS environments, an interface to SOAC, an interface to SPACE, enhanced security for protection of customer data, and tools for service creation. While prior service management systems have provided various service provisioning features to subscribers and users, such past attempts have not provided a flexible system which may utilize the advantages of AIN functionality and existing non-AIN systems. In particular, prior attempts have not provided a mechanism for synchronizing service orders originating on multiple, incompatible systems. Past attempts have also failed to match customer specific data with service orders arriving through the traditional service order flow. Further prior systems have not addressed provisioning of mass market, i.e., templated, services and complex services which are not templated. Prior systems also do not provide a single point of access for customer service and repair. Such features would be highly desirable to developers and provisioners of telephony services, such as regional telephone companies, that desire a flexible system of service creation, provisioning and support. OBJECTS OF THE PRESENT INVENTION In view of the above, the present invention, through one or more of its various aspects and/or embodiments is thus presented to accomplish one or more objects and advantages, such as those noted below. A general objective of the present invention is to provide a flexible service management system for use in an Advance Intelligent Network (AIN). Another objective of the present invention is to provide a method for synchronizing service orders originating in one system with orders originating in another system. Yet another objective of the present invention is to provide a mechanism for "holding" an order after partial provisioning so as to synchronize external provisioning requirements. A further objective of the present invention is to accept input from traditional service order flow to add/change/delete customers in the ISCP in sync with additions/changes/deletions at the network element. Another objective of the present invention is to accept customer-specific data and match the data with the service orders arriving through the traditional service order flow and sent to the ISCP. Yet another objective of the present invention is to provide a single point of access/update for customer-specific data for use in customer service and repair. A further objective of the present invention: is to provide a mechanism which may be quickly adapted to support automated service order flow-through processing for new AIN services. Another objective of the present invention is to provide a software development toolkit (SDT) to quickly build logic within the SMS to process new services. Yet Another objective of the present invention is to provided for greater access to customer data and security measures to protect customer data. A further objective of the present invention is to provide for greater flexibility in billing of services. Another objective of the present invention is to provide a greater ability to query downstream network elements including ISCP and IPs and provide a provisioning interface for these elements. SUMMARY OF THE PRESENT INVENTION According to an aspect of the present invention, there is provided a system for facilitating service order management within a communications network. The communications network comprises network elements which provide communications services. The system receives a request representative of a service order for at least one communications service associated with a subscriber number from at least one service order source. The system comprises an order management system adapted to input the request, the order management system comprising processes which determine service implementing information that is output to the network elements to implement at least one communications service. Also provided is an interface system adapted to interface the service order management system with the at least one service order source and the network elements, and a database system adapted to store and access data related to the requests in a hierarchical format. Each service order source has a dissimilar input/output format, and the managing system coverts each dissimilar input/output service order format into a single internal format. In addition, the processes communicate via messages containing the requests where the messages are monitored at predetermined times. According to another aspect, the processes of the order management system comprise an input process, a verification process, a messaging process, and an output process. According to a further aspect, the messaging process formats messages created by the order management system for distribution within the order management system, and for distribution to the database system, the at least one service order source and the network elements via the interface system. According to yet another aspect, the interface system comprises a transaction monitoring and system control system. According to yet a further aspect, the transaction monitoring and system control system provides a mechanism for concurrently processing a plurality of requests within the order management system. According to another aspect, the system further comprises a querying system which is adapted to query the database system and the network elements. According to a further aspect, the messages comprise queries, acknowledgments, transaction types, function types, broadcasts, informational messages, and error notices. According to yet another aspect, the input process accepts input data from the at least one service order source and verifies that the inputted data contains a predetermined minimum content requirement. According to a further aspect, the input process populates the database system with raw data associated with the request, and an internal sequence number is generated which is associated with the request. According to another aspect, the input process determines if the request contains errors, and if so, the input process corrects the errors and populates the database system with the raw data based on the request. According to a further aspect, the input process identifies duplicative requests, such that a first of the duplicative requests is processed and others of the duplicative requests are not processed by the order management system. According to yet another aspect, the input process is adapted to receive and update requests received in a raw format from operations support systems, where the input process further identify manual update requests. According to yet another aspect, the input process reformats the raw data into the hierarchical format of the database system, the hierarchical format comprising tables having fields. The tables are associated by the internal sequence number. According to another aspect, the verification process determines if the fields contain valid data in accordance with predetermined constraints. According to a further aspect, the verification process selectively updates a lock table to prevent concurrent processing of two requests associated with the subscriber number. According to yet another aspect, the verification process performs exception processing, order matching, correction order processing, order cancellation, local service provider order matching, and number change processing. The verification process also creates a first saved table in the database system which contains activity information and service order code information in accordance with the request. According to a further aspect, the exception processing comprises From (F) and To (T) processing. According to another aspect, the verification process processes FID and supplemental data. According to a further aspect, the verification process determines if the request contains an allowable combination of the communications services at a user selectable date in accordance with information contained in the first saved table, and the verification process determines which of the network elements support the communications services at the user selectable date. According to yet another aspect, the verification process creates a second saved table which contains information related to a difference of communications services between a subscriber's current services and the at least one communications service being added, removed or modified by the request such that the difference of services is implemented by the network elements. According to yet another aspect, the verification process verifies that the communications services represented by the request will be able to be provided by the network elements at a schedule date for implementation. According to another aspect, the output process determines the service implementing information to be implemented by the network elements for the subscriber number. The output process routes the service implementing information to queues associated with the network elements. According to a further aspect, the output process further comprises a network element implementing system, the network element implementing system interfacing with the network elements to output the service implementing information in a format appropriate for each of the network elements. The network element implementing system determines a proper sequence of the service implementing information to be outputted to the network elements and outputs the service implementing information to one or more queues associated with one or more network elements. According to yet another aspect, the one or more queues have different dequeue times. According to yet another aspect, the network element implementing system routes a portion of the service logic implementing information to a local update queue in accordance with a predetermined time, such that the portion of the service logic implementing information is not routed to the one or more queues associated with the network elements. According to another aspect, the network element implementing system implements the at least one communications service in accordance with at least the internal sequence number associated with the request. According to a further aspect, the network element implementing system updates the database system to indicate that the at least one communications service has been implemented by the network elements. According to yet another aspect, the network element implementing system requeues portions of the service implementing information to the network elements when an error is encountered. According to yet another aspect, the network implementing process requeues dependent portions of the portions of the service implementing information without manual intervention. According to another aspect, the network implementing process requeues the portion of the service implementing information after manual intervention. According to a further aspect, the network implementing process requeues the service implementing information in accordance with a copy of the service implementing information stored by the database system. According to yet another aspect, the verification process determines a schedule date and a schedule time to activate the at least one communications service at the network elements. According to another aspect, the order management system further comprises a composite view system to provide a list of all existing services for the subscriber number, and to provide a list of services for the subscriber number in accordance with a user selectable date and time. According to yet another aspect, the system further comprises a correction system, the correction system returns the network elements to a state prior to the network element implementing system implementing the service implementation information at the network elements. The correction system operates when the request has been corrected, canceled or encounters an error. According to yet another aspect, the correction system resubmits the request without intervention from the at least one service order source. According to another aspect, the correction system cancels the request without querying the network elements. According to a further aspect, the database system appends communications network specific information to the request. According to yet another aspect, the database system executes transactions related to the requests at the predetermined times, the transactions updating at least one predetermined table. According to yet another aspect, the database system comprises an historical order log which is updated by the transactions which are executed at the predetermined times. According to another aspect, the historical order log stores information related to the single internal format, error information related to the transactions indicative of a cause of an error, and portions of the service implementing information at the predetermined times. The order management system issues an acknowledgment to the at least one service order source when the historical order log stores a last portion of the service implementing information. According to a further aspect, the historical order log stores information related to the single internal format, error information related to the transactions indicative of a cause of an error, and portions of the service implementing information at the predetermined times. The order management system issues an acknowledgment to the at least one service order source prior to when the historical order log stores a last portion of the service implementing information when removing the at least one communications service. According to yet another aspect, the database system is adapted to skip storing one of the portions of the service implementing information, and the order management system continues to determine subsequent portions of the service implementing information. According to yet another aspect, the database system provides the order management system with a table-driven service logic to facilitate the addition of new services. According to another aspect, the database system provides the order management system with a table-driven service logic to facilitate the addition of new features to existing services, the new features conforming to existing feature constraints. According to a further aspect, the database system provides an estimated response time in accordance with a network element response time and a length of a queue associated with each of the network elements. According to yet another aspect, each of the network elements is provided with a plurality of queues having different prioritizations and the database system provides the estimated response time in accordance with the different prioritizations. According to yet another aspect, the plurality of queues having the different prioritization comprise an online queue and a batch queue. According to another aspect, the database system utilizes an internal sequence number associated with the request to store and access the service implementing information. According to a further aspect, the database system stores manual intervention information related to the service implementing information at the predetermined times when the order management system encounters an error. According to yet another aspect, the database system updates the at least one table such that the transactions are propagated through the order management system. According to yet another aspect, the database system is adapted to modify the request after the order management system has begun determining the service implementing information for the request. According to another aspect, the database system stores copies of the service implementing information and the messages. According to a further aspect, the database system stores the request until a future date, future time, or future event, after which the database system submits the request to the order management system. According to yet another aspect, the database system stores non-implementing information related to the request which is not used in the service implementing information, the non-implementing information being associated with the subscriber number upon the order management system outputting the service implementing information. According to yet another aspect, the system further comprises a user interface, the user interface interfacing with the managing system via the interface system. According to another aspect, the user interface is adapted to correct the service orders and generate the requests representative of the service orders. According to a further aspect, the user interface is adapted to query the network elements and the database system. The network elements receive and process the query via the order management system. According to yet another aspect, the interface system provides a communications link to the at least one service order source and the network elements. According to yet another aspect, the interface system routes communications to the appropriate one of the at least one service order source and the network elements. According to another aspect, the communications links comprise TOPCOM, DATAGATE, MQSeries, ASN.1, TCP/IP and TUXEDO/WS. According to a further aspect, the interface system further comprises a transaction monitoring and system control component which monitors the messages and updates the database system in accordance with the messages. The database system is updated in accordance with an internal reference number associated with the request. According to yet another aspect, the transaction monitoring and system control component comprises TUXEDO/Q or TUXEDO/T. According to yet another aspect, the order management system is provided with a system to implement services on template-based network elements and non-template based network elements. According to another aspect, the request submitted by the at least one service order source initiates the messaging process to send a message to another of the service order source. According to a further aspect, the system notifies an administrative personnel of an error in accordance with the severity of the error. According to yet another aspect, synchronous network element and asynchronous network element responses are processed by the order management system in a standardized manner. According to yet another aspect, the processes and the interface system is adapted to be interrupted to read a configurable parameter file in order to modify the processes and the interface system. According to another aspect, the communications network comprises an advanced intelligent network, and the at least one order source comprises EASE, ECRS, SOAC, and a PC server. According to a further aspect, the user interface is provided with a suite of services to access the database system. According to yet another aspect, the system is provided with a suite of services to access the database system. According to another aspect of the present invention, there is provided a system for facilitating service order management within an advanced intelligent network. The system receives a request representative of a service order for at least one telephony service associated with a subscriber telephone number from at least one operations support system. The advanced intelligent network comprises network elements which provide telephony services. The system comprises an order management system adapted to input the request, the order management system comprising processes which determine service provisioning information that is output to the network elements to implement the at least one telephony service. The system also includes an interface system adapted to interface the service order management system with the at least one operations support system and the network elements, and a database system adapted to store and access data related to the requests in a hierarchical format. Each operations support system has a dissimilar input/output format and the managing system coverts from each dissimilar input/output service order format into a single internal format. The processes of the order management system communicate via messages containing the requests, and the messages are monitored at predetermined times. According to another aspect, the processes of the order management system comprises an input process, a verification process, a messaging process, and an output process. According to a further aspect, the messaging process formats messages created by the order management system for distribution within the order management system, and for distribution to the database system, the at least one operations support system and the network elements via the interface system. According to yet another aspect, the interface system comprises a transaction monitoring and system control system. According to yet another aspect, the transaction monitoring and system control system provides a mechanism for concurrently processing a plurality of requests within the order management system. According to another aspect, the system further comprises a querying system which is adapted to query the database system and the network elements. According to a further aspect, the messages comprise queries, acknowledgments, transaction types, function types, broadcasts, informational messages, and error notices. According to yet another aspect, the input process accepts input data from the at least one operations support system and verifies that the inputted data contains a predetermined minimum content requirement. According to yet another aspect, the input process populates the database system with raw data associated with the request, and an internal sequence number which is associated with the request. According to another aspect, the input process determines if the request contains errors, and if so, the input process corrects the errors and populates the database system with the raw data based on the request. According to a further aspect, the input process identifies duplicative requests, such that a first of the duplicative requests is processed and others of the duplicative requests are not processed by the order management system. According to yet another aspect, the input process is adapted to receive and update requests received in a raw format from operations support systems, the input process further identifying manual update requests. According to yet another aspect, the input process reformats the raw data into the hierarchical format of the database system, the hierarchical format comprising tables having fields. The tables are associated by the internal sequence number. According to another aspect, the verification process determines if the fields contain valid data in accordance with predetermined constraints. According to a further aspect, the verification process selectively updates a lock table to prevent concurrent processing of two requests associated with the subscriber telephone number. According to yet another aspect, the verification process performs exception processing, order matching, correction order processing, order cancellation, local service provider order matching, and number change processing, creates a first saved table in the database system which contains activity information and service order code information in accordance with the request. According to yet another aspect, the exception processing comprises From (F) and To (T) processing. According to another aspect, the verification process processes FID and supplemental data. According to a further aspect, the verification process determines if the request contains an allowable combination of the telephony services at a user selectable date in accordance with information contained in the first saved table. The verification process determines which of the network elements support the telephony services at the user selectable date. According to yet another aspect, the verification process creates a second saved table which contains information related to a difference of telephony services between a subscriber's current telephony services and the at least one telephony service being added, removed or modified by the request such that the difference of telephony services is implemented by the network elements. According to yet another aspect, the verification process verifies that the telephony services represented by the request will be able to be provided by the network elements at a schedule date for implementation. According to another aspect, the output process determines the service provisioning information to be implemented by the network elements for the subscriber telephone number. The output process routes the service provisioning information to queues associated with the network elements. According to a further aspect, the output process further comprises a network element provisioning system, which interfaces with the network elements to output the service provisioning information in a format appropriate for each of the network elements. The network element provisioning system determines a proper sequence of the service implementing information to be outputted to the network elements. Additionally, the network element provisioning system outputs the service provisioning information to one or more queues associated with one or more network elements. According to yet another aspect, the one or more queues have different dequeue times. According to yet another aspect, the network element provisioning system routes a portion of the service logic implementing information to a local update queue in accordance with a predetermined time, such that the portion of the service logic implementing information is not routed to the one or more queues associated with the network elements. According to another aspect, the network element provisioning system implements the at least one telephony service in accordance with at least the internal sequence number associated with the request. According to a further aspect, the network element provisioning system updates the database system to indicate that the at least on telephony service has been implemented by the network elements. According to yet another aspect, the network element provisioning system requeues portions of the service provisioning information to the network elements when an error is encountered. According to yet another aspect, the network implementing process requeues dependent portions of the portions of the service provisioning information without manual intervention. According to another aspect, the network implementing process requeues the portion of the service provisioning information after manual intervention. According to a further aspect, the network implementing process requeues the service provisioning information in accordance with a copy of the service provisioning information stored by the database system. According to yet another aspect, the verification process determines a schedule date and a schedule time to activate the at least one telephony service at each of the network elements. According to yet another aspect, the order management system further comprises a composite view system to provide a list of all existing telephony services for the subscriber telephone number, and to provide a list of telephony services for the subscriber telephone number in accordance with a user selectable date and time. According to another aspect, the system further comprises a correction system which returns the network elements to a state prior to the network element provisioning system implementing the service implementation information at the network elements. The correction system operates when the request has been corrected, canceled or encounters an error. According to a further aspect, the correction system resubmits the request without intervention from the at least one operations support system. According to yet another aspect, the correction system cancels the request without querying the network elements. According to yet another aspect, the database system appends advance intelligent network specific information to the request. According to another aspect, the database system executes transactions related to the requests at the predetermined times, the transactions updating at least one predetermined table. According to a further aspect, the database system comprises an historical order log which is updated by the transactions which are executed at the predetermined times. According to yet another aspect, the historical order log stores information related to the single internal format, error information related to the transactions indicative of a cause of an error, and portions of the service provisioning information at the predetermined times. The order management system issues an acknowledgment to the at least one operations support system when the historical order log stores a last portion of the service provisioning information. According to yet another aspect, the historical order log stores information related to the single internal format, error information related to the transactions indicative of a cause of an error, and portions of the service provisioning information at the predetermined times. The order management system issues an acknowledgment to the at least one operations support system prior to when the historical order log stores a last portion of the service provisioning information when the at least one telephony service is removed. According to another aspect, the database system is adapted to skip storing one of the portions of the service provisioning information, and the order management system continues to determine subsequent portions of the service provisioning information. According to a further aspect, the database system provides the order management system with a table-driven service logic to facilitate the addition of new telephony services. According to yet another aspect, the database system provides the order management system with a table-driven service logic to facilitate the addition of new features to existing telephony services, the new features conforming to existing feature constraints. According to yet another aspect, the database system provides an estimated response time in accordance with a network element response time and a length of a queue associated with each of the network elements. According to another aspect, each of the network elements is provided with a plurality of queues having different prioritizations and the database system provides the estimated response time in accordance with the different prioritizations. According to a further aspect, the plurality of queues having the different prioritization comprise an online queue and a batch queue. According to yet another aspect, the database system utilizes an internal sequence number associated with the request to store and access the service provisioning information. According to yet another aspect, the database system stores manual intervention information related to the service provisioning information at the predetermined times when the order management system encounters an error. According to another aspect, the database system updates the at least one table such that the transactions are propagated through the order management system. According to a further aspect, the database system is adapted to modify the request after the order management system has begun determining the service provisioning information for the request. According to yet another aspect, the database system stores copies of the service provisioning information and the messages. According to yet another aspect, the database system stores the request until a future date, future time, or future event, after which the database system submits the request to the order management system. According to another aspect, the database system stores non-implementing information related to the request which is not used in the service provisioning information, the non-implementing information being associated with the subscriber telephone number upon the order management system outputting the service provisioning information. According to a further aspect, the system further comprises a user interface, the user interface interfacing with the managing system via the interface system. According to yet another aspect, the user interface is adapted to correct the service orders and generate the requests representative of the service orders. According to yet another aspect, the user interface is adapted to query the network elements and the database system, the network elements receiving and processing the query via the order management system. According to another aspect, the interface system provides a communications link to the at least one operations support system and the network elements. According to a further aspect, the interface system routes communications to the appropriate one of the at least one operations support system and the network elements. According to yet another aspect, the communications links comprise TOPCOM, DATAGATE, MQSeries, ASN.1, TCP/IP and TUXEDO/WS. According to yet another aspect, the interface system further comprises a transaction monitoring and system control component which monitors the messages and updates the database system in accordance with the messages. The database system is updated in accordance with an internal reference number associated with the request. According to another aspect, the transaction monitoring and system control component comprises TUXEDO/Q or TUXEDO/T. According to a further aspect, the order management system is provided with a system to implement telephony services on template-based network elements and non-template based network elements. According to yet another aspect, the request submitted by the at least one operations support system initiates the messaging process to send a message to another of the operations support system. According to yet another aspect, the system notifies an administrative personnel of an error in accordance with the severity of the error. According to another aspect, synchronous network element and asynchronous network element responses are processed by the order management system in a standardized manner. According to a further aspect, the processes and the interface system is adapted to be interrupted to read a configurable parameter file in order to modify the processes and the interface system. According to yet another aspect, the user interface is provided with a suite of services to access the database system. According to yet another aspect, the system is provided with a suite of services to access the database system. According to another aspect, the operations support systems comprises EASE, ECRS, SOAC, and a PC server. According to an yet another aspect of the present invention, there is provided a method for facilitating service order management within a communications network. The network receives a request representative of a service order for at least one communications service associated with a subscriber number. The request originates from at least one service order source having a dissimilar input/output format. The communications network comprises network elements which provide communications services to subscribers. the method comprises interfacing with the at least one service order source, inputting the request from the at least one service order source, converting the unique input/output order format into a single internal format, storing and accessing data related to the requests in a database in a hierarchical format, determining service implementing information to implement the at least one communications service, and outputting to the network elements the service implementing information. According to another aspect, the method further includes distributing messages within the communications network, and to the at least one service order source and the network elements. The messages comprise queries, acknowledgments, transaction types, function types, broadcasts, informational messages, and error notices. According to a further aspect, the method further includes monitoring transactions executed at predetermined times by the communications method, and controlling the communications network in accordance with the messages. According to yet another aspect, the step of controlling the method further includes concurrently processing a plurality of requests within the communications network. According to yet another aspect, the step of controlling the communications network further includes querying the database and the network elements. According to another aspect, the step of inputting further includes accepting input data from the at least one service order source, and verifying that the inputted data contains a predetermined minimum content requirement. According to a further aspect, the method further includes populating the database with raw data associated with the request, and generating an internal sequence number which is associated with the request. According to yet another aspect, the step of verifying further includes determining if the request contains errors, and if so, correcting the errors and populating the database method with the raw data based on the request. According to yet another aspect, the method further includes identifying duplicative requests and processing a first of the duplicative requests such that others of the duplicative requests are not processed, and identifying manual update requests. According to another aspect, the method further includes reformatting the raw data into the hierarchical format of the database, the hierarchical format comprising tables having fields, where the tables are associated by the internal sequence number. Also, the method includes determining if the fields contain valid data in accordance with predetermined constraints. According to a further aspect, the method further includes selectively updating a lock table to prevent concurrent processing of two requests associated with the subscriber number, and performing exception processing, order matching, correction order processing, order cancellation, local service provider order matching, and number change processing. Also, the method includes creating a first saved table in the database which contains activity information and service order code information in accordance with the request. According to yet another aspect, the above-mentioned step of performing includes processing From (F) and To (T) orders, an processing FID and supplemental data. According to yet another aspect, the method further includes determining if the request contains an allowable combination of the communications services at a user selectable date in accordance with information contained in the first saved table, and determining which of the network elements support the communications services at the user selectable date. According to another aspect, the method further includes creating a second saved table which contains information related to a difference of communications services between a subscriber's current services and the at least one communications service being added, removed or modified by the request such that the difference of services is implemented by the network elements. The method also includes verifying that the communications services represented by the request will be able to be provided by the network elements at a schedule date for implementation. According to a further aspect, the step of determining service implementing information further includes routing the service implementing information to queues associated with the network elements. According to yet another aspect, the method further includes outputting the service implementing information to the network elements in a format appropriate for each of the network elements. The service implementing information is output to one or more queues associated with one or more network elements. According to yet another aspect, the one or more queues have different dequeue times. According to another aspect, the step of routing the service implementing logic routes a portion of the service logic implementing information to a local update queue in accordance with a predetermined time, such that the portion of the service logic implementing information is not routed to the one or more queues associated with the network elements. According to a further aspect, the method further includes implementing the at least one communications service in accordance with at least the internal sequence number associated with the request, and updating the database to indicate that the at least one communications service has been implemented by the network elements. According to yet another aspect, the step of routing further includes requeuing portions of the service implementing information to the network elements when an error is encountered, and requeuing dependent portions of the portions of the service implementing information after manual intervention if the communications network is unable to resolve the error. According to yet another aspect, the step of routing requeues the service implementing information in accordance with a copy of the service implementing information stored by the database. According to another aspect, the method further includes determining a schedule date and a schedule time to activate the at least one communications service at the network elements. According to a further aspect, the method further includes generating a composite view to provide a list of all existing services for the subscriber number, and providing a list of services for the subscriber number in accordance with a user selectable date and time. According to yet another aspect, the method further includes correcting the service implementation information by returning the network elements to a state prior to the service implementation information being outputted to the network elements, where the step of correcting is performed when the request has been corrected, canceled or encounters an error. According to yet another aspect, the method further includes resubmitting the request without intervention from the at least one service order source. According to another aspect, the method further includes canceling the request without querying the network elements. According to a further aspect, the method further includes appending communications network specific information to the request. According to another aspect, the method further includes executing transactions related to the requests at the predetermined times, the transactions updating at least one predetermined table, and updating an historical order log when the transactions are executed which are executed at the predetermined times. The historical order log stores information related to the single internal format, error information related to the transactions indicative of a cause of an error, and portions of the service implementing information at the predetermined times. The method also includes issuing an acknowledgment to the at least one 'service order source prior to, or when, the historical order log stores a last portion of the service implementing information. According to a further aspect, the method further includes skipping the step of storing one of the portions of the service implementing information and continuing to determine subsequent portions of the service implementing information. According to another aspect, the step of determining includes providing an estimated response time in accordance with a network element response time, a queue prioritization and a length of the queue associated with each of the network elements. According to a further aspect, the method further includes storing, in the database, manual intervention information related to the service implementing information at the predetermined times when the communications network encounters an error. According to yet another aspect, the method further includes propagating, throughout the communications network, the transactions, and modifying the request after the communications network has begun determining the service implementing information for the request. According to yet another aspect, the method further includes storing copies of the service implementing information and the messages, and storing the request until a future date, future time, or future event, after which the database submits the request to the communications network. The database stores non-implementing information related to the request which is not used in the service implementing information, the non-implementing information being associated with the subscriber number upon the service implementing information being outputted to the network elements. According to another aspect, the communications network further includes a user interface, and the method further includes correcting the service orders, and generating the requests representative of the service orders. According to a further aspect, the method further includes querying the network elements and the database, and receiving and processing the query at the network elements. According to yet another aspect, the step of routing includes communicating with the network elements via one of TOPCOM, DATAGATE, MQSeries, ASN.1, TCP/IP and TUXEDO/WS. According to yet another aspect, the method further includes updating the database in accordance with the messages and an internal reference number associated with the request. And the monitoring and controlling is performed by TUXEDO/Q or TUXEDO/T. According to another aspect, the method further includes implementing services on template-based network elements and non-template based network elements. According to a further aspect, the step of distributing messages initiates a message to be send to another of the service order sources. According to yet another aspect, the method further includes notifying administrative personnel of an error in accordance with the severity of the error. According to another aspect, the method further includes processing synchronous network element and asynchronous network element responses in a standardized manner. According to a further aspect, the step of determining further includes interrupting the communications network to read a configurable parameter file, and modifying the communications network in accordance with information in the configurable parameter file. According to a further aspect, the communications network includes an advanced intelligent network, and the at least one order source includes EASE, ECRS, SOAC, and a PC server. According to yet another aspect, the user interface is provided with a suite of services to access the database. According to yet another aspect, the communications network is provided with a suite of services to access the database. The above-listed and other objects, features and advantages of the present invention will be more fully set forth hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS The present invention is further described in the detailed description that follows, by reference to the noted plurality of drawings by way of non-limiting examples of preferred embodiments of the present invention, in which like references numerals represent similar parts throughout the several views of the drawings, and wherein: FIG. 1 illustrates, in a general block diagram form, a simplified representation of an Advanced Intelligent Network according to the prior art; FIG. 2 illustrates, in a general block diagram form, a simplified representation of an aspect of the present invention; FIG. 3 illustrates, in a general block diagram form, a wide area network according an aspect of the present invention; FIG. 4 illustrates, in a general block diagram form, an overview of the elements which are connected to the Service Management System of the present invention; FIG. 5 illustrates, in a general block diagram form, a connection between the Service Management System and the alert system software; FIG. 6 illustrates, in a general block diagram form, the connections between the Service Management System and the elements external to the system; FIG. 7 illustrates, in a general block diagram form, a connection between the Service Management System and a graphical user interface; FIG. 8 illustrates, in a general block diagram form, a connection between the Service Management System and OSS systems such as EASE and ECRS; FIG. 9 illustrates, in a general block diagram form, a connection between the Service Management System and SOAC; FIG. 10 illustrates, in a general block diagram form, a connection between the Service Management System and SPACE; FIG. 11 illustrates, in a general block diagram form, a connection between the Service Management System and other telephone company elements; FIG. 12 illustrates, in a general block diagram form, a connection between the Service Management System and VAD; FIGS. 13 and 14 illustrate, in a general block diagram form, the Generic Order Management services and Database Services of the present invention; FIG. 15 is a flow chart of the logic flow of the processes and operations that may be performed by the TIP service of the present invention; FIG. 16 is a flow chart of the logic flow of the processes and operations that may be performed by the DISPATCH service of the present invention; FIG. 17 is a flow chart of the logic flow of the processes and operations that may be performed by the REFORMAT service of the present invention; FIG. 18 is a flow chart of the logic flow of the processes and operations that may be performed by the SOPP sub-routine of the present invention called by REFORMAT; FIG. 19 is a flow chart of the logic flow of the processes and operations that may be performed by the VERIFY service of the present invention; FIGS. 20 and 21 are a flow charts of the logic flow of the processes and operations that may be performed by the TRANSLATION service of the present invention; FIG. 22 is a flow chart illustrating the F&T processing of the present invention; FIG. 23 is a flow chart of the logic flow of the processes and operations that may be performed by the EDITS service of the present invention; FIG. 24 is a flow chart of the logic flow of the processes and operations that may be performed by COMPLEX CPRs by the EDITS service of the present invention; FIG. 25 is a flow chart of the logic flow of the processes and operations that may be performed by the EDITS service of the present invention where editing is performed with the USOC_REF table; FIG. 26 is a flow chart of the logic flow of the processes and operations that may be performed by the BREAKOUT service of the present invention; FIG. 27 is a flow chart of the logic flow of the processes and operations that may be performed by Order or Request-Level processing performed by the BREAKOUT service of the present invention; FIG. 28 is a flow chart of the logic flow of the processes and operations that may be performed by WTN-Level processing performed by the BREAKOUT service of the present invention; FIG. 29 is a flow chart of the logic flow of the processes and operations that may be performed by the ROUTER service of the present invention; FIGS. 30 and 31 are flow charts of the logic flow of the processes and operations that may be performed by the PROV service of the present invention; FIG. 32 is a flow chart of the logic flow of the processes and operations that may be performed by the MESSAGE_NOTIFICATION service of the present invention; FIG. 33 is a flow chart of the logic flow of the processes and operations that may be performed by the BACKOUT service of the present invention; FIG. 34 illustrates, in a general block diagram form, the Maintenance and Administrative Services utilized in conjunction with the Service Management System of the present invention; FIG. 35 is an exemplary graphical user interface screen illustrating an about window; FIG. 36 is an exemplary graphical user interface screen illustrating an available locations window; FIG. 37 is an exemplary graphical user interface screen illustrating a change password window; FIG. 38 is an exemplary graphical user interface screen illustrating a current location window; FIG. 39 is an exemplary graphical user interface screen illustrating a current wire center settings window; FIG. 40 is an exemplary graphical user interface screen illustrating an error message display window; FIG. 41 is an exemplary graphical user interface screen illustrating a group maintenance window; FIG. 42 is an exemplary graphical user interface screen illustrating a group maintenance--enter group window; FIG. 43 is an exemplary graphical user interface screen illustrating a group ID save window; FIG. 44 is an exemplary graphical user interface screen illustrating an interface status window; FIG. 45 is an exemplary graphical user interface screen illustrating a logon window; FIG. 46 is an exemplary graphical user interface screen illustrating a message box window; FIG. 47 is an exemplary graphical user interface screen illustrating a NPA/NXX window; FIG. 48 is an exemplary graphical user interface screen illustrating a printer options window; FIG. 49 is an exemplary graphical user interface screen illustrating a queue viewer window; FIG. 50 is an exemplary graphical user interface screen illustrating a reconnect session window; FIG. 51 is an exemplary graphical user interface screen illustrating a return to sender window; FIG. 52 is an exemplary graphical user interface screen illustrating a status descriptions window; FIG. 53 is an exemplary graphical user interface screen illustrating a system messages window; FIG. 54 is an exemplary graphical user interface screen illustrating a title screen window; FIG. 55 is an exemplary graphical user interface screen illustrating a user maintenance window; FIG. 56 is an exemplary graphical user interface screen illustrating a user maintenance--enter user Id window; FIG. 57 is an exemplary graphical user interface screen illustrating a user id save window; FIG. 58 is and exemplary graphical user interface screen illustrating a USOC descriptions window; FIGS. 59-61 are exemplary graphical user interface screens illustrating wire center default settings windows; FIG. 62 is an exemplary graphical user interface screen illustrating an order matrix window; FIG. 63 is an exemplary graphical user interface screen illustrating an enter TN window; FIG. 64 is an exemplary graphical user interface screen illustrating an FID update window; FIG. 65 is an exemplary graphical user interface-screen illustrating a USOC/FID update window; FIG. 66 is an exemplary graphical user interface screen illustrating a USOC/FID errors window; FIG. 67 is an exemplary graphical user interface screen illustrating a MI schedule window; FIG. 68 is an exemplary graphical user interface screen illustrating a Complex activity window; FIG. 69 is an exemplary graphical user interface screen illustrating a select orders window; FIGS. 70-72 are exemplary graphical user interface screens illustrating orders found windows; FIG. 73 is an exemplary graphical user interface screen illustrating a raw SOAC image window; FIGS. 74-78 are exemplary graphical user interface screens illustrating a NE query windows; FIGS. 79-81 are exemplary graphical user interface screens illustrating template query windows; and FIGS. 82-85 are exemplary graphical user interface screens illustrating TN composite view windows. BRIEF DESCRIPTION OF THE APPENDICES In order to further facilitate the detailed description of the present invention, reference is made to the noted plurality of appendices by way of non-limiting examples of preferred embodiments of the present invention, in which sample pseudo-code, database tables, database services, database field definitions, and comments are provided with respect to the various features, operations and functions of the invention, and wherein: Appendix A is an exemplary listing of the database tables of the present invention; Appendices B and C are exemplary database services of the present invention which are utilized to access and manipulate data within the database tables; Appendix D is an exemplary pseudo-code for executing the MESSAGE_NOTIFICATION service of the present invention; Appendix E is an exemplary list of error codes utilized to determine the cause of errors during the processing of the present invention; Appendix F is an exemplary pseudo-code for executing the TIP service of the present invention; Appendix G is an exemplary pseudo-code for executing the REFORMAT service of the present invention; Appendix H is an exemplary pseudo-code for executing the SOPP service of the present invention; Appendix I is an exemplary pseudo-code for executing the VERIFY service of the present invention; Appendix J is an exemplary pseudo-code for executing the TRANSLATION service of the present invention; Appendix K is an exemplary pseudo-code for executing the EDITS service of the present invention; Appendix L is an exemplary pseudo-code for executing the BREAKOUT service of the present invention; Appendix M is an exemplary pseudo-code for executing the ROUTER service of the present invention; Appendix N is an exemplary set of tables utilized in generating the customer view within the present invention; Appendix O is an exemplary pseudo-code for executing the PROV service of the present invention; Appendix P is an exemplary listing of services available to users of a graphical user interface according to the present invention; and Appendix Q is an exemplary listing of reference tables utilized to support the various operations of the service management system of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS I. Overview A. Introduction The Service Management System (SMS) of the present invention is a modular, table driven computer-based Service Management System (SMS) used to automate the provisioning flow for Advanced Intelligent Network (AIN) telephony services. As shown in FIGS. 2-11, the SMS 10 includes a graphical user interface (GUI) 42 (FIG. 3) to interact with the system to appropriately handle failed or special provisioning requests. The GUI 42 also acts as a mechanism for storing and displaying provisioned service information. The system is a generic system which provides for shorter design and development periods when deploying new telephony services. The SMS 10 consists of a series of software implemented services which reside on a platform. The services have responsibilities within the provisioning flow and interact with external computing systems via specialized interfaces. The SMS Services 100 share a common database system and access methodology to coordinate data flow and transition of service requests and queries to provisioning or query requests and to receive their associated responses. All of the above-noted features will be described in greater detail hereinafter. The SMS 10 supports subscriber services such as, for example, Intelligent Call Forwarding (U.S. Pat. No. 5,592,541, to Harold C. FLEISCHER, III et al., issued on Jan. 7, 1997), Selective Call Acceptance (U.S. application Ser. No. 08/455,699, in the names of Harold C. FLEISCHER III et al., entitled "Apparatus and Method for Selectively Accepting Incoming Calls", filed May 31, 1995), and Caller IntelliData (U.S. application Ser. No. 08/473,919, in the names of Harold C. FLEISCHER, III et al., entitled "Apparatus and Method for Recording Call Related Data", filed Jun. 7, 1995). The disclosures of the above-identified U.S. Patents and U.S. Patent applications are expressly incorporated herein by reference in their entireties. As is evident to those of skill in the art, additional services may be supported by the SMS 10 as new services are added to the AIN network and existing services are enhanced. As shown in FIG. 2, in order for the SMS 10 to perform service order provisioning, the SMS 10 may interface with, for example, Service Order Assignment Control (SOAC) 20. SOAC 20 is a Bellcore product and is a primary source of provisioning updates for mass market AIN services that are initiated through the normal service order process. Once SOAC 20 receives a response from the SMS 10, it will send AIN trigger information to the MARCH.TM. system for automatic switch updates. MARCH.TM. is a trademark of Bell Communications Research, Inc. After the switch is updated, the service order flows to the appropriate billing systems for completion. Upon completion, SOAC 20 notifies the SMS 10 for confirmation purposes. As illustrated in FIGS. 2-4 and 8, the SMS 10 may also interface with other OSSs 54 in order to support service negotiations and service assurance requests. The SMS 10 may use a generic OSS 54 data gateway as an alternative entry point for supplemental AIN subscription data. The supported OSSs 54 may include Easy Access Sales Environment (EASE) 16 which is used to generate sales orders by Residence and Business service representatives; Service Order and Retrieval and Distribution (SORD) 18 which is used to distribute service orders to affected departments and downstream OSs 54; Enhanced Customer Reports System (ECRS) 14 which allows customers to report trouble on their circuits/networks by calling a designated repair number; Customer Network Administration (CNA) 12 which provides selected large business customers with online access to their account information; Billing and Order Support System (BOSS) 40 which allows customers to inquire about their bill or to make changes to their account; and PC services used to allow customers to add customer specific service information to specified services that are already provisioned. The OSSs 54 may also query the SMS 10 for access to AIN subscription data. located in, for example, an AIN database 64 An interface is provided for this function which is outside the normal SOAC 20 provisioning flow and is accessible through industry standard protocols such as RPC, CMISE, etc. Further, the SMS 10 may service multiple OSS systems 54A in a simultaneous mode, and may service 20 to 30 simultaneous OSS systems 54A. As illustrated in FIG. 10, the SMS 10 interfaces with SPACE 24 for mechanical service order provisioning and SPACE 24 query of templated CPRs. COMPLEX service orders (i.e., those service orders which are not templated) will flow to the SMS 10 as well. The SMS 10 will recognize COMPLEX orders and sends a work notice to the appropriate user group so the order can be worked on a manual basis. When the COMPLEX order is marked complete, the SMS database 200 is updated, and a POSACK (positive acknowledgment) is returned to the SOAC 20 system where the order originated. SPACE query capabilities are controlled on a user group basis. The SMS 10 provides the capability to query a customer's CPR, and template mapping information. In addition, queries for stand-alone tables, and table specification information may be supported. The user is able to view active, pending, sending, suspended, disconnected, old, saved and failed views from SPACE 24. All types of SPACE Provisioning CPRs are supported by the SMS 10. The SMS 10 processes responses from SPACE 24 including duplicates and errors, queries entire CPRs and handles return of all varieties of data and errors. THE SMS handles abort (logical replacement for flow control), queries for provisioning mapping information and all queries and provisioning requests are timed and resent as needed. The SMS 10 stores the AIN subscription data for the mass market services identified above (e.g., Selective Call Acceptance, Caller IntelliData, Outgoing Call Restriction, Non-Pub Messaging, and Computer Access Restriction). The SMS 10 database supports multiple pending orders, a current view, and a historical view of all AIN services. The SMS 10 provides an interface for the Customer Records Information System (CRIS)/Customer Access Billing System (CABS) 26 (FIG. 2). The CRIS billing system is responsible for calculating and rendering bills to approximately 10.5 million residence and business customers on a monthly basis. The CABS billing system is responsible for calculating and rendering bills to approximately 20,000 inter-exchange carriers and 16,000 end users. An SMS 10 user interface terminal (shown as GUI 42 in FIG. 3) is provided for the RCMAC/GUIs, CNOC, NOCs and SCCs to administer the system. Input screens provide a capability to work system errors, and update and query the five mass market services identified above. A local-post option is provided to handle non-standard updates (in a manual mode) and to post COMPLEX orders which are provisioned on a manual basis. The SMS 10 provides a query mechanism to the SMS Customer Database 64 (FIG. 11). The user is able to view saved, erred, pending, COMPLEX and in-progress views. The SMS 10 graphical user interface provides a query interface into SPACE 24. An estimated response time calculation is supported for the SPACE 24 query. The SMS 10 supports up to, for example, 150 concurrent users. A GUI Client Interface 308 supports queries of the PCS database 204 and order submission via PCS database 204 entries and an appropriate interface. The SMS 10 also supports a generic OSS Client Interface 310 which will be used to provide SMS query capabilities. The SMS 10 may comprise a query server and an OSS server, to which the OSS Client Interface 310 is connected to process queries and requests originating from the OSS systems 54. A Batch audit process compares mass market subscription data that is stored in both SPACE 24 and the SMS 10. For auditing purposes, the SPACE 24 data is considered the master, and all audit discrepancies will automatically be updated within the SMS 10 to match the SPACE 24 data. In addition, an audit discrepancy report is written which lists all updated SMS 10 records. An initial load program will populate the SMS 10 with SPACE 24 subscription data that has been already provisioned. As shown in FIG. 11, the SMS 10 will support Operations, Administration and Maintenance (OA&M) 68 functions. This includes the support of: system configuration parameters, reference tables (e.g., switch tables, USOC tables, service tables, etc.), view queues, manage queues, halt processing to a Network Element, and Database back-up and recovery. B. SMS Component Areas The SMS 10 include several software component areas, each of which is described generally below for introductory purposes, and with greater detail hereinafter. As shown in FIGS. 4, 5 and 13, the SMS 10 generally includes a database component, a communications interface (COM), a generic order management system (GOM), and a graphic user interface (GUI), which will be collectively referred to as SMS Services 100. The Database Services component 200 (FIG. 13) includes the data repository associated with the present invention. The Database Services may be implemented using ORACLE database software and design tools to create the procedures and I/O routines to access the data. ORACLE database software and design tools are available from ORACLE, California. The Communication (COM) Services 300 (FIGS. 4 and 5) provide communications capabilities between the various OSS systems, NEs, and GUI users who interface with the SMS 10. The COM Services component 300 provides a communications path to dialogue with SOAC 20 through TOPCOM (available from Bellcore, Murray Hill, N.J.), with SPACE 24 using DSG (available from DSET, Inc., Bridgewater, N.J.) via a DATAGATE process set (DATAGATE is available from Southwestern Bell Telephone, St. Louis, Mo. and facilitates communication between dissimilar hardware platforms), with VAD 32 through TOPCOM, AIN through MQSeries (available from IBM, Corp., Armonk, N.Y.), and with EASE and ECRS users through DATAGATE. The COM services 300 also include encoding and decoding to and from ASN.1to SPACE via a ASN Compiler and Protocol Development Tools (available from DSET). The OSS 54 (e.g., EASE 16 and ECRS 14) interface component will allow users to perform queries of SMS 10 and NE data. The OSS 54 accessories interface with the SMS 10 via DATAGATE. Message handling and communications may be provided through the, TUXEDO/WS software package (available from the Information Management Company (IMC), Edison, N.J.), which processes SMS 10 queries, NE queries, activation requests, error processing and OA&M functions. The GOM Services 400 (FIGS. 6 and 13-14) component is the Generic Order Management subsystem for processing service orders. Throughout the subsystem, customer views are maintained to allow GOM to resolve errors, synchronize events, provide responses, allow data insertion via the GUI users, and to provide information to those handling errors and manual processes. The GOM services 400 component is divided into a front and a back end system. The front end of the subsystem provides parsing via Service Order pre-processing (SOPP) stringing data into a repository, data verification, order translation through DIFFERENCING and multiple pass activities, edits, breaking the order into activation request entities, and routing requests to correct queues for later activation processing. The Back End System is referred to as the NE Interface System which passes requests to network elements and handles network element response traffic, it is utilized to accomplish NE access. The GOM services 400 includes provisioning services which pace the delivery of requests to the NEs as required. The GUI client 42 and GUI Services 500 (FIG. 7) are provided to query the SMS data as well as query the attached network elements. The GUI client may provided updates to the SMS data and will trigger the GOM services 400 to act upon those updates. The GUI 42 software may be developed using PowerBuilder (available from Powersoft, Inc., Concord, Mass.), and will run on Intel-based workstations (e.g, 80486, Pentium.RTM. or larger) running Windows.RTM. 3.x or Windows95.RTM. (available from Microsoft Corp., Redmond, Wash.), or alternatively, X-terminals connected to Sun servers running the Solaris operating system. The GUI User Access and OA&M Interface system component use the PowerBuilder products to provide a consistent data presentation mechanism for RCMAC/GUI 42 and other GUI 42 Users and OA&M access. The service management system also includes a Transaction and System Control component. This component may be provided by the TUXEDO/T and /Q products (available from IMC), which are used to oversee the scheduling of processing services and to handle queuing and dequeuing of the messages used to provide interfacing between software components in the system. Further, the service management system may be provided with an alert system to issued messages to pagers to notify the appropriate personnel of system errors and failures. As shown in FIG. 5, such alert system software may comprise PATROL, which is available from BMC Software, Houston, Tex. In the description of the present invention below, reference is made to TUXEDO and PATROL calls and processes. Applicants note that other messaging, transaction control, and system alert software applications may be utilized to implement the present invention, and thus, the TUXEDO and PATROL calls noted below may be changed to accommodate such an implementation. C. Hardware and Platform Referring to FIG. 3, the SMS 10 server hardware preferably consists of two SMS servers 76 at a data center 80 comprising Sun SPARCcenter 2000 systems running the Solaris 2.4 operating system. There also may be several GUI servers 78 in remote locations which may comprise Sun SPARC 20 systems also running Solaris 2.4. The Sun SPARCcenter 2000, SPARC 20 and Solaris operating system are available from Sun Microsystems, Mountain View, Calif. In a preferred embodiment, the SMS 10 will comprise two Sun SPARCcenter 2000, each having 8 processors, 1 GB of main memory, 52.2 GB of disk storage, and 2 S/BUS quad Ethernet cards. In an alternative embodiment, each SPARCcenter 2000 may comprise 20 processors, 5.12 GB of main memory, 40 S/BUS slots, and 52.5 GB of disk storage. The SMS 10 hardware configuration may also include a 8 mm Tape Drive, CD-ROM drive, and mirrored disks (i.e., RAID). The external systems, such as OSSs 54, VAD 32, and AIN-IP 28 may be connected to the SMS 10 by a token ring network connected to an area wide network (through firewall 74 where applicable) supporting, for example, TCP/IP and X.25 protocols. C programming language developer products may be utilized for software development and generation, and version control. C programming language tools are available from Sun Microsystems, Mountain View, Calif. Other configurations of hardware and software than the exemplary configuration above may be used to implement the present invention. II. Database A collection of database routines are used by all SMS 10 processes to access database objects (e.g., tables) which belong to SMS 10. The routines are the exclusive method for accessing the SMS databases. Such a strategy ensures that data being stored in the database is processed in a consistent manner. In addition, it offers the advantage of isolating other portions of the application software from the physical characteristics of the database. This latter point greatly simplifies the process of migrating the database from one DBMS and/or hardware platform to another. All database routines incorporate the following design goals: Ease of use such that the service is easy to call and use, a consistent interface as a regular function pattern makes access easier to learn and use, transparency such that callers do not need to know where or how the data is stored, completeness such that the Database Services 200 interface allows access to all features of the DBMS, and extensibility as it should be easy to add new services as the application grows or requirements change. A. Database System Constraints Various system design constraints will now be discussed. The constraints are provided to insure uniformity across the database system. As noted above, the SMS 10 is table-driven and includes several tables (illustratively shown in FIG. 13) to perform management services. The tables and their associate fields will now be generally introduced. The tables, field names and associated values will be referenced throughout the instant specification to described the function of each of the services within the SMS 10. This section references Appendix A, which includes an exemplary group of SMS database tables. 1. Raw Request Tables (Built by TIP) RRAW_REQ--contains the `raw` SOAC order types. REQUEST_IMAGE--contains the base copy of the incoming sources orders. 2. Misc. Request/Order Data EXP_ORDER--contains `expected` SOAC order associated with a GUI 42 order. ORDER_LOCK--contains a `lock` for synchronizing multiple order passes. 3. PIECES TABLES (Built by REFORMAT or GUI Services PCS_C3--contains service order's C3 section. PCS_ODR--contains service order's ODR section. PCS_RSCFID--contains service order's Resource Record's FID data. GUI_RSCFID--contains service order's Resource Record's FID data. PCS_RSCREC--contains service order's Resource Record's section. GUI_RSCREC--contains service order's Resource Record's section. PCS_RSCUSOC--contains service order's Resource Record's USOC data. GUI_RSCUSOC--contains service order's Resource Record's USOC data. PCS_SBR--contains service order's SBR section. 4. SAVED VIEW (Built by TRANSLATION) SAV_ACTION--action (add, delete, or change) for given USOCs. SAV_FID--contains the FID and its data for a given USOC. SAV_ODR--contains service order's ODR section. SAV_USOC--contains the USOC for a given WTN. SAV_WTN--contains WTN related information. 5. SAVED VIEW2 (Built by EDITS) SAV2_ACTION--contains the NE and Template ID information. SAV2_CALL_VAR--contains SPACE CALL VARIABLE(s) and data. SAV2_FID--contains the FID and its data for a given USOC. SAV2_ODR--contains service order's ODR section. SAV2_USOC--contains the USOC for the given WTN. SAV2_WTN--contains WTN related information. 6. PROVISIONING STEP TABLES (Built by BREAKOUT) STEP_CALL_VAR--contains SPACE CALL VARIABLE(s) and data. STEP_FID--contains the FID and its data for a given USOC. STEP_USOC--contains the USOC for the given WTN. STEP_WTN--contains WTN related information per NE. 7. LOG TABLES (BY ISN) EDITS_ERROR--contains error code/text information for a given order. HOL_CTL--control section, one per order. HOL_FLOW--each program's audit per order. HOL_STEP--entry corresponding to each provisionable step on the order. HOL_WTN--entry for each WTN on order. INPUT_COUNT--contains count of all messages received by TIP. OUTPUT_COUNT--contains count of all messages processed by PROV. MI_LOG--contains error information per order. ACTVY_LOG--contains `ACK` messages (e.g., POSACK, NEGACK, etc.) QUERY_RESP--contains responses to queries. 8. SAFE STORE TUXEDO OUEUE TABLES CUSTPC_Q--PCIF queue Backup Table. DISPATCH_Q--DISPATCH queue Backup Table. FNTMON_Q--F and T queue Backup Table. PROV_Q--PROV queue Backup Table. SOAC_Q--SOAC Reply queue Backup Table. TIP_Q--TIP queue Backup Table. VERIFY_Q--VERIFY queue Backup Table. 9. CUSTOMER ACCOUNT TABLES WTN--contains WTN account information. WTN_LOCK--contains `LOCK` used to sequentially process a WTN. SVC_USOC--contains USOC (service) information. SVC_CV_DATA--contains the CALL VARIABLE information. SVC_FID--contains the FID. SVC_DETAIL--contains USOC and NE ID. 10. SMS REFERENCE TABLES NE_INTRFC--contains all valid NEs. TEMPLATE_NE_XREF--contains all valid Templates per NE. SWITCH_NE_XREF--contains all valid NE per switch. SWITCH_CONTROL--contains all valid switches. SWITCH_USOC_XREF--contains all valid USOCs per switch. USOC_REF--contains entry for each valid USOC. USOC_PROV_REF--contains NE types per USOC. USOC_TEMPLATE_XREF--contains all valid USOCs per Template. TEMPLATE--contains logical templates. CALL_VARIABLE_REF--contains entry for each CALL VARIABLE per USOC/FID. QUEUE_STATS--contains queue length and wait time statistics. TSYS_REF--contains TSYS/system cross reference information. CLASS_OF_SVC_REF--valid CS values, Business/Residence Categories. TEMPLATE_DETL--contains all valid templates. FID_REF--contains entry for each valid FID per USOC. INTERFACE--contains attached systems and their respective status. REQR_USOC_REF--contains list of required USOCs for a given USOC. STATUS_REF--contains all valid statuses and their definitions. ACTIVITY_TYPE_REF--contains types for message routing. ERROR_CODE--contains valid error codes and text. ERR_CLEANUP--contains list of tables to purge. 11. GUI TABLES USER_PREF--contains user information. USER_PASSWORD--contains encrypted user password information. USER_CMNTY_XREF--contains user community/responsibility information. USER_COMMUNITY--contains list of legal communities. PRMSN_GROUP--contains permission group information. PRMSN_ACCESS--identifies permissible function per user group. USER_OFC_XREF--identifies office location of user. OFFICE_LOCT--contains valid office locations. WC_ALIAS--contains wire center alias per user. USER_WC_ALIAS_XREF--contains wire center alias per user. PRMSN_ID--defines screen Ids. USER_PWD_CHG_LOG--contains last user password update data. 12. CONFIGURABLE PARAMETERS TABLE CONFIG_PARM_VALUE--contains parameters controlling program logic. 13. SPACE NE Tables SPACE_XREF--correlates SPACE transaction Id with INT_SEQ_NUM. SPACE_RESPONSE--correlates status information for each SPACE transaction. SPACE_QRY_RESP--contains detailed information returned from SPACE. SPACE_MAP--contains detailed information relative to a SPACE template. SPACE_CALLVAR--contains detailed information returned from SPACE. SPACE_COLUMNS--contains detailed information returned from SPACE. SPACE_EMB_TBL_DATA--contains detailed information returned from SPACE. 14. VAD NE Tables VAD_XREF--correlates VAD transaction Id with INT_SEQ_NUM. VAD_REQUEST--contains information on messages sent to VAD (e.g., status). VAD_RESPONSE--contains status information for each VAD message. VAD_TAG--contains detailed information from VAD query of customer data. 15. LOGS (not by ISN) JOB_LOG--contains results from "end-of-day processing". EVENT_SMRY--contains entry controlling optional SCRUB_EDITS execution. EVENT_LOG--contains detailed information of EVENT_SMRY entries. Within the above-noted tables, various reference tables include effective and expiration dates (e.g. template and FID_REF) to indicate the time frame during which the referenced item can be used in the provisioning process. These columns are not used to denote the date on which a characteristic of an item changes (e.g., FID_REQUIRED_IND changes from `N` to `Y`). In the event that an attribute of an item does change but the name of the item remains the same, it is necessary to update that characteristic in the table without populating the expiration date. Note that in such a situation, all future queries will pick up the new attribute whether processing a past, present, or future request. Subscription data (e.g. USOCs, FIDs, etc.) is retained on an ongoing basis based on WTN. However, since subscriber data (e.g., BTN, customer name, etc.) is stored for the life of a service order, it is not possible over time to differentiate between two customers who happen to have the same WTN. B. Database Service Description Applications access Database Services 200 through the suite of functions. The suite is provided for the purpose of maintaining consistency and transparency, and is extensible to access all features of the database without requiring the application developer to know or understand SQL or the physical database organization. An exemplary suite is included in Appendix B. Further, the present invention contemplates many Database Services 200 which operate to implement the SMS 10. The Database Services 200 relate and implement the elements (e.g., tables, views, etc.) that comprise the SMS 10. The database services 200 are provided to update/delete/add fields within a table, read/write information from each of the tables, return information to a calling program from the database, insert/delete rows/columns from tables, write records to tables, write table views, retrieve a list of users and permissions, sort data within specified tables, retrieve orders and order-related information, retrieve manual intervention information for manually-provisioned services (i.e., COMPLEX), and retrieve error messages, etc. The before-listed functions are merely exemplary and are not intended to be all inclusive. As is evident to those of skill in the art, additional services may be added to provide functionalities as needed. An exemplary list of the Database Services 200 is attached as Appendix C. C. GOM Tables As shown in FIG. 13, the Generic Order Management (GOM) system utilizes the following database tables to process SOAC 20, etc., service requests: RAW_REQUEST 202, PIECES (PCS 204), SAV 206, SAV2208, and PROV_STEPS 210. It should be noted that the above tables are actually just schemas or groups of tables within a single database, and they are not necessarily distinct databases. For simplicity they are referred to herein as "databases". The RAW_REQUEST database 202 consists of one table, the Raw Request table. Entries to the table are made by the TIP service 402 when the service order enters the SMS 10 system via a SOAC 20 application. Upon this event, a unique sequence number (INT_SEQ_NUM) is generated which is used to identify the service order as it migrates through the SMS 10. The PIECES database (PCS) tables 204 are created by SOPP (REFORMAT 406) and come directly from the service order or are created directly by a GUI 42 service. Each table has the unique INT_SEQ_NUM which is generated when the SOAC 20 image is received and stored in the RAW_REQUEST table 202. Each table may have additional indexes based on C3 header fields such as "ORDNO+TRN+OT+TSYS+INT_SEQ_NUM". Some tables require that ACT and WTN be added to the index. Note that the response to SOAC 20 is based on information in the PIECES database which originates in the C3 header. The SAV database 206 contains the activity which needs to be provisioned based on the incoming request at the NE. The Saved view (SAV 206) is created containing only the changes being provisioned as opposed to the entire New View which is stored in the PCS database 204. Nearly all fields in the SAV2 database 208 come directly from the SAV database 206. However, the content of the SAV2 table represents a delta (i.e., difference) between what a customer account currently has and the services that the customer wants to add, such that the delta can be provisioned in the Network Element(s). The reason for a second view (i.e., SAV2) is that EDITS 412 will determine the exact Network Elements (NE) requiring provisioning, whereas, TRANSLATION 410 used a default NE when generating SAV. EDITS 412 populates default fields and Triggers to SAV2. The PROV_STEP database contains pending updates. Each of the provisioning steps contains only the data needed for that particular step, and has a unique number called STEP_NO so that no step at a NE, nor WTN, nor the entire order will have the same step number. D. Historical Order Log The Historical Order Log (HOL) is comprised of the following set of tables: the HOL_CTL 126, the HOL_WTN table 220, the HOL_FLOW table 218, and the HOL_STEP table 222, shown in FIG. 13. The HOL_CTL table 216 is built when a service order is received and updated once the order has been parsed, thus allowing key fields such as ORDNO, TSYS, TRN, et al. to be filled in. The overall order status is contained in this table. The HOL_WTN table 220 contains the status: for a particular WTN relative to the order keyed on the "INT_SEQ_NUM" and the "WTN". The HOL_FLOW table 218 contains status information relative to the location of the service request within GOM, for example, the transaction names which have processed the request and the status associated with each. The HOL_STEP table 222 is used to audit each step created by the BREAKOUT service 416. Each "ROUTER Message" built by the BREAKOUT service 416 is "logged" here to allow for recovery should a catastrophic failure in the "ROUTER queue" occur. As noted above, each table contains a key called "INT_SEQ_NUM" which is generated when the SOAC 20 image is received and stored in the RAW_REQUEST table 202. This allows a user to track the processing of a specific request using the INT_SEQ_NUM. Also included are fields such as WTN, ORDNO, TRN, OT, TSYS, etc. which can be used to query the HOL tables. Status fields may be provided which include the following valid statuses: S(aved), P(ending), E(rror), C(omplete), I(nprogress), H(old), B(ackout), R(ecovery) and F(alse Step). E. Database Support for SMS Validation of USOC Combinations One of the features of the SMS application is the ability to determine which combinations of services are valid together based on the local service provider who developed the FIM that is being used to provide the customer's service. This capability is table-driven and is performed in accordance with data contained in the USOC_REF and USOC_COMBO_REF tables which are described below. 1. USOC_REF Table This table contains with information on every USOC that is processed within the SMS 10 application. The columns related to USOC_COMBO_REF processing are: USOC_ID_NUM--Defines a number which uniquely identifies a USOC_ID (used as the primary key). This number is used in accessing the USOC_COMBO_REF table. Exemplary valid values are integers in the range of 1 to 333. This higher value effectively establishes the maximum number of USOCs that are valid within SMS. VALID_ALL_COMBO_IND--An indicator which identifies USOCs that are valid with ALL combinations of USOCs in the USOC_COMBO_REF table. Exemplary valid values are "N" (No) which indicates that this USOC is not valid with all combinations of USOCs, and "Y" (Yes), which indicates that this USOC is valid with all combinations in the USOC_COMBO_REF table. A listing of the valid combinations which include this USOC can be found in USOC_COMBO_REF.DESCRIPTION_TEXT. Note, because "Y" is valid with all combinations, this USOC does not need to be listed in USOC_COMBO_REF.DESCRIPTION_TEXT. An exemplary USOC_REF table structure is provided in Appendix A. 2. USOC_COMBO REF Table This table documents all valid combinations of USOC_IDs for each Local Service Provider, identified by LSP_ID, that has developed a feature interaction manager (FIM). An exemplary USOC_COMBO_REF tables is defined in Appendix A. The definition of columns are as follows: CUSTOMER_TYPE_IND--An indicator which specifies the type of accounts for which this combination of USOCs is valid. Exemplary valid values are "A" (All accounts), "B" (Business accounts only), and "R" (Residence accounts only). DESCRIPTION_TEXT--A list of USOC_IDs which are valid together on a FIM developed by the Local Service Provider identified by LSP_ID. USOC_IDs can be listed in any sequence but must be delimited and terminated by semicolons. Imbedded spaces are not allowed. HANDOVER_CPR_VALUE--A value for the HANDOVER_CPR call variable which identifies the FIM that is used by this LSP to process this combination of services. LAST_UPDT_TSTAMP--The date and time at which a column in this row was last updated. LAST_UPDT_USER_ID--The user ID of the last person who updated any column in this row. LSP_ID--The ID of the Local Service Provider (LSP) who developed the FIM identified by the call variable value in HANDOVER_CPR_VALUE. USOC_COMBO_EFF_DATE--The date and time on which this combination of services will first be valid using the indicated handover CPR value. This is the first second in time when this combination of services can be provisioned using the indicated handover CPR value, i.e., one second earlier it was not valid. USOC_COMBO_EXPR_DATE--The date and time at which this combination of services will last be valid using the indicated handover CPR value. This is the last second in time when this combination of services can be provisioned using the indicated handover CPR value, i.e,. one second later it will not be valid. USOC_COMBO_ID--A derived key value which uniquely identifies the combination of USOC IDs that are present in DESCRIPTION_TEXT. This key is determined by calling the PROV_UTIL.GET_USOC_COMBO_ID function and is always the same on a given instance for a given combination of USOC IDs regardless of the sequence in which those USOCs appear in DESCRIPTION_TEXT. The primary key of USOC_COMBO_REF may be DESCRIPTION_TEXT and LSP_ID since each row is unique based on the combination of services being identified and the LSP. Note, having a VARCHAR2(2000) column in the primary key would been an inefficient means of providing access to this table and would be inefficient if foreign keys are needed in the future. In addition, USOCs within DESCRIPTION_TEXT will need to be sorted if the USOCs are used as part of the primary key and queries against the table would have to sort the USOC_IDs in their where clause in order to accurately match against the table. 3. Valid Combination Processing The USOC_COMBO_ID concept was developed to address the inefficiencies and inconveniences which would have resulted from having DESCRIPTION_TEXT in the primary key. The value in USOC_COMBO_ID uniquely identifies the combination of USOCs which are listed in DESCRIPTION_TEXT yet has a maximum length of just 56 bytes. The logic for deriving the USOC_COMBO_ID is encapsulated in a user-written Oracle stored function named PROV_UTIL.GET_USOC_COMBO_ID. This function is used by a "before insert or update" trigger on the USOC_COMBO_REF table to populate the USOC_COMBO_ID column whenever DESCRIPTION_TEXT is added or changed. In addition, the function should be used by queries which need to read from the table in order to avoid redundant logic and to ensure consistent interpretation of the data. A string of USOC_IDs up to 2000 bytes in length is the only argument passed to PROV_UTIL.GET_USOC_COMBO_ID and the value returned by the function is a USOC Combo ID. Note that the USOC_COMBO_ID returned by the function may or may not exist in the USOC_COMBO_REF table since the table only contains VALID combinations. a. Function PROV_UTIL.GET_USOC_COMBO_ID PROV_UTIL.GET_USOC_COMBO_ID works as follows to determine a USOC Combo ID from a list of USOCs. PL/SQL coding techniques are used to minimize actual processing outlined in the following high-level overview. An array of 336 switches is initialized to an "OFF" value. The number of switches corresponds to the maximum number of distinct USOC IDs raised to the next multiple of 6. The list of USOCs is parsed and each individual USOC is identified. For each USOC_ID found, the USOC_REF table is queried to obtain the USOC_ID_NUM and VALID_ALL_COMBO_IND. If VALID_ALL_COMBO_IND=`Y`, no further action is required for this USOC since it is valid with all possible combinations of USOCs. If VALID_ALL_COMBO_IND=`N`, the value in USOC_ID_NUM is used as a pointer into the array of switches noted above, and the corresponding switch is set to an "ON" value. Once all USOC IDs in the list have been processed, the switches are taken in groups of 6 (1-6, 7-12, 13-18, etc.) as the binary representation of a "Base64" number. The 336 switches form 56 groups with each group mapping to the corresponding position in the 56-byte USOC Combo ID. Trailing spaces are trimmed from the derived USOC Combo ID to minimize the length of the key but imbedded spaces must be retained. The Base64 conversion table (Table 1) is as follows:
TABLE 1
Binary Decimal number Base64 number
000 000 0 (space)
000 001 - 001 001 1 - 9 1 - 9 (numbers)
001 010 - 100 011 10 - 35 A - Z (upper case
letters)
100 100 36 [ (left square bracket)
100 101 37 ] (right square bracket)
100 110 - 111 111 38 - 63 a - z (lower case
letters)
The Base64 "number" must be a printable character in order to allow for storage of the USOC Combo ID in an Oracle VARCHAR2 column. Note, Base128 could not be used because the number of distinct printable characters which can be stored in a VARCHAR2 column is less than 128. If an error is encountered at any point because of invalid data within the list of USOCs, an ORA-06502 exception ("numeric or value error") is raised. III. COM The communication (COM) Services 300 shown in FIG. 4, provide communications capabilities between the various OSS systems, NEs and GUI users who interface with the SMS 10. The COM interfaces are described below with reference to several GOM Services 400, which will be described hereinafter in greater detail with reference to the GOM Services 400. A. SOAC Client Interface Referring to FIGS. 4, 6 and 9, the SOAC Client Interface 306 is responsible for establishing and maintaining the integrity of the SMS 10-SOAC 20 connection and managing the flow of messages between SMS 10 and SOAC 20. There is an instance of the SOAC Client Interface 306 for each SOAC 20 controller. Service orders for AIN and VAD 32 services are passed from EASE 16 and SORD 18 to SOAC 20 (shown in FIG. 2). SOAC 20 will recognize AIN/VAD 32 service orders and route them to SMS 10 for provisioning. SOAC 20 sends, and the SMS 10 will support, both flow-through, and manual service requests. All Service Order types (e.g., New (N), Disconnect (D), Change (C), Record (R), From (F), and To (T)) are supported. In addition, the SMS 10 is configurable to support any new service order types should new types be added to SOAC 20. A New connect is an order to establish a new customer account and request new services. A Disconnect is an order to remove an existing customer account and discontinue services. A Change is an order to change services for an existing customer account. A From order reflects old services for a customer who is relocating within a service area. This order is issued with a corresponding To order designating where the customer is relocating. Both the From and To orders have the same order number (ORDNO). The Record order is to update an existing customer account. The SMS 10 generic order management subsystem supports all SOAC 20 message function types (e.g., Pre-completion (PRE), Correction (COR), Cancellation (CAN), Post Completion Notice (PCN), and Correction Post Completion (CPC)), and it will support Multiple-Lines (Working Telephone Numbers), Template Changes, Trigger Changes within a CPR, Hard COR/CPC passes. The PRE function defines an activation request that is the first activation request to the SMS 10 for an order, or is immediately preceded by an activation request with a function type of CAN, i.e., the customer is requesting one or more AIN services subsequent to cancellation of all the AIN services the customer previously requested. The COR function defines an activation request that is a correction to the preceding activation request that has the function type of PRE or COR. The CAN function is an activation request that is a cancellation of the preceding activation request, i.e., the customer is canceling all the AIN service that had been requested in the preceding activation request. The immediately preceding activation request will have a function type of PRE or COR. Any immediately following function type is PRE. The PCN activation request is a post completion activation request to the preceding activation request to notify the SMS 10 that the order status is being changed from a pending state to a completed state in the SOAC 20 et al. system. The preceding activation request is either PRE or COR. The CPC function is a post completion notice with corrections to the preceding activation request. The associate activation request is an indication to the SMS 10 that the order has been completed with some modification to the preceding activation request. The nature of the modification to the preceding activation request will vary in accordance with the usage of CPC order passes. The preceding function type is either a PRE or COR. If multiple orders are detected involving the same working telephone number (WTN), the overlapping provisioning activity is flagged as an error for manual resolution. In addition, for AIN services, SOAC 20 will manage the timing and provisioning of most AIN triggers with MARCH 22. For example, there may be three physical SOAC 20 controllers communicating with the SMS 10. The communication between SOAC 20 and SMS 10 shown in FIG. 9 is TCP/IP using Transaction Oriented Protocol (TOP). The SOAC Client Interface 306 will encode/decode messages from/to TOP via the Bellcore TOPCOM product. There is single TOPCOM configuration file on SMS 10 which contains the information for each of the SOAC 20s used by TOPCOM 324 to establish a session with each SOAC 20 controller. The TOPCOM configuration file may include, for example, a SOAC 20 Identifier or name used by the SOAC Client Interface 306's application interface to specify the SOAC controller 20A and a remote SOAC controller which is the Domain Name Server (DNS) resolvable name or IP address of the SOAC controller 20A, and alternatively, the IP addresses of each SOAC controller 20A. Also included in the TOPCOM configuration file may be the remote SOAC 20 controller's IP port numbers of the SOAC 20 controller's TOPCOM software (e.g., port 102), the remote SOAC 20 controller service, the remote "T_SELECTOR" for each SOAC 20 (e.g., service identifier), and the CISE for test SOAC 20 T_SELECTOR (e.g., SMSe103 for the local SMS T_SELECTOR (VAD 32 access)). Other parameters defining the SOAC 20 interaction with TOPCOM 324 may be specified. For example, the following parameters may be configured: a TOP Window Size parameter (which is a protocol level parameter that should be set to one to force synchronous message communication between SMS 10 TOPCOM 324 and the remote SOAC 20), Handler Timing Parameters (e.g., SndDelay, RcvDelay, and DackDelay (where SndDelay greater than R | ||||||