SECTION 1 BUSINESS OPERATIONS...

Transcription

1 Contents SECTION 1 BUSINESS OPERATIONS SUNCOM CLIENTS Intrinsic Clients Required Clients Discretionary Clients Committed Discretionary Clients Uncommitted Discretionary Clients GENERAL DESCRIPTION OF THE SUNCOM BUSINESS MODEL USING OASIS RESPONSIBILITIES OF DIVTEL AND THE VENDOR IN THE SUNCOM BUSINESS MODEL Flowchart of Steady State Business Process Table of Functions in OaSIS and Vendor Systems OaSIS Comprehensiveness and Primacy OaSIS Function Types and Interfaces with Vendors Application Program Interfaces Batch Routines Manual Review and Data Entry by Vendor Staff Functions in SUNCOM OaSIS Catalog DivTel s Sole Discretion over the Catalog Taxes and Government Sanctioned Fees in the Catalog Account and User Management SUNCOM Client Users and Rights Vendor Users & Rights Orders Credential Request Orders Special Construction Orders Inventory Inventory Reconciliation Invoicing Electronic Substantiating Detail File DivTel Response to Vendor Invoices... 12

2 Section 1 Business Operations 1.1 SUNCOM Clients SUNCOM clients fall within two broad categories and several subcategories. Distinctions are made here to clarify DivTel s right to access and hold Client Proprietary Network Information (CPNI) per restrictions established by the Federal Communications Commission Intrinsic Clients DivTel has the right to access all ordering, inventory, usage and billing information i.e., CPNI data related to Intrinsic clients. Intrinsic clients consist of two subcategories: required and committed discretionary clients Required Clients Required clients consist of all agencies of the Executive Branch of Florida government. In accordance with Sections F.S., these entities must use SUNCOM for telecommunications services or obtain an exemption from DivTel from this requirement. These clients by law are subcomponents of a single telecommunications customer known as SUNCOM. Therefore, their inventory, usage and billing data is a subset of the State s CPNI Discretionary Clients Discretionary clients are all entities authorized to buy through SUNCOM under Part III of Section 282 F.S., but are not required to do so. As of this writing, these consist of; the Legislative and Judicial Branches, cities, counties, public and private colleges and universities, public and private libraries, special districts and private non-profits that get the majority of their income from Florida public entities Committed Discretionary Clients Committed discretionary clients are entities that use SUNCOM services today. CPNI data related to Committed clients is already held by DivTel, regardless of the type of the organization. By purchasing SUNCOM services in the past, they have agreed to participate in a business model whereby CPNI must be shared with DivTel. Eligible SUNCOM Clients Uncommitted Discretionary Clients Discretionary clients are classified here as uncommitted if they are not currently SUNCOM clients (i.e. not committed clients). Intrinsic SUNCOM Clients Discretionary SUNCOM Clients Prior to requesting that vendors share, with DivTel, associated CPNI data related to uncommitted discretionary clients, DivTel will obtain necessary client authorizations. Commitment to SUNCOM will be evident when orders come from OaSIS on behalf of such clients. However, DivTel will share copies of their authorizations with vendors upon request. Required Committed Discretionary CPNI authorization established Uncommitted Discretionary CPNI authorization required Figure 1: Venn diagram of client types ITN NO. # Page 2 of 13

3 1.2 General Description of the SUNCOM Business Model using OaSIS SUNCOM s standard business model, as governed by Part III of Section 282, Florida Statutes, and Chapter 60FF-2, Florida Administrative Code, establishes DivTel as an aggregator of Florida s public sector telecommunications purchases. From the vendor s perspective, this means that DivTel is a single customer for all SUNCOM services. This is achieved not only through enterprise bulk contracts, but DivTel also centralizes, consolidates and standardizes all SUNCOM ordering and billing through a system known as the SUNCOM Open and Shared Information System (OaSIS). When SUNCOM clients log-in to OaSIS they can perform the following functions related to all telecommunications service types and providers: 1. manage billing accounts, 2. review a comprehensive list of contracted services, 3. place service orders, 4. have access to their entire telecommunications inventory with associated event histories and charges, 5. review invoices with detail charges, 6. and establish OaSIS users and their rights. Using a single invoice with supporting detail in electronic files, vendors bill DivTel monthly for services rendered to all SUNCOM clients. The supporting detail includes auditable charges at the activity level under unique identifiers for each transaction (for metered services) and service account. In addition to empowering SUNCOM clients with self-service and establishing substantial cost controls, this model minimizes vendor risks associated with collecting payment on thousands of billing accounts, then settling billing disputes with some of them. This model also achieves significant economies of scale for all parties through substantial automation from a series of Business-to-Business (B2B) electronic transactions between DivTel and its vendors. However, all but two B2B electronic transactions have manual equivalents in OaSIS screens whereby vendors can manually input the data that would otherwise come from the B2B transaction. All of the same business rules apply (regarding timeliness for example). Vendor use of these manual processes is less desirable as they require data entry twice (once in the vendor s system then again in OaSIS) and are more likely to produce errors. And DivTel will assume no responsibility for inputting the data on the vendor s behalf. ITN NO. # Page 3 of 13

4 1.4 Responsibilities of DivTel and the Vendor in the SUNCOM Business Model Flowchart of Steady State Business Process Figure 2 below is a flow chart of functions to be implemented by DivTel, its clients and the vendor. Note there are seven named B2B transactions that are described in more detail in the narrative below. DivTel Vendor Invoicing Orders Service Catalog Review product/service/feature in OaSIS Approve product/service/feature & set price in OaSIS Establish SUNCOM client Establish users & rights Establish OaSIS billing accounts Establish catalog restrictions Place an order through OaSIS Send B2B order from OaSIS to install or disconnect service Inventory Update OaSIS inventory OaSIS & staff audit substantiating detail against inventory, product catalog & hand bill OaSIS invoices SUNCOM clients Inventory reconciliation Update OaSIS product/service catalog B2B-6 DivTel pays vendor less applicable exceptions B2B-1 B2B-2 B2B-3 B2B-4 B2B-5 Design product/service offering Seek product/service/feature posting to OaSIS catalog Update vendor s catalog to show active SUNCOM service Account Management Propose draft order for SUNCOM client Install or disconnect service Service use require login to vendor system? Return B2B installation/disconnct acknowledgement Inventory reconciliation no Update vendor inventory Submit hand bill including all charges Submit B2B invoicing detail substantiating the hand bill Accept payment Inventory yes Service Catalog Orders Invoicing Provide billing exception report B2B-7 Reconcile exceptions Reconcile exceptions B2B means a Business to Business electronic messages, batch files and/or Application Program Interfaces (APIs) exchanging all of the electronic data necessary to the transaction. OaSIS will provide alternative manual input options to the vendor for low volume transactions, but will not manually input any data on behalf of the vendor. SUNCOM Client action required SUNCOM clients pay DivTel SUNCOM Client notified Figure 2 Flow chart of SUNCOM s steady state business process ITN NO. # Page 4 of 13

5 1.4.2 Table of Functions in OaSIS and Vendor Systems Table 1 below briefly describes the respective roles of the supporting systems in the processes. Table 1 Table of functions in OaSIS and vendor systems Function DivTel s OaSIS Vendor s System Service Catalog Account Management System Users Orders Invoicing Billing Disputes and SLAs All data necessary to describe and order all SUNCOM products, services, and features (hereafter referred to as services ) will be held in the OaSIS service catalog. DivTel will approve or disapprove activation in the catalog which will allow client purchases. DivTel will also establish the prices paid by clients. DivTel has sole discretion over whether or not these are activated in the catalog for availability for client purchase. All specific SUNCOM client account information will be held exclusively in OaSIS. All SUNCOM client users, and their rights to order and view account and inventory information, will be held exclusively in OaSIS. Vendor staff will also be able to perform functions in OaSIS. All orders sent to the vendor requesting SUNCOM services will exclusively come from OaSIS in B2B-3 transactions or through OaSIS screens where vendors can see and update the orders (OaSIS can send notifications of pending orders to vendors). OaSIS will accept and audit substantiating detail from the vendor for all SUNCOM charges. All payments to the vendor for all SUNCOM services will come from DivTel. All disputed charges (B2B-7) and SLA violations related to SUNCOM services will be identified by, and settled exclusively with DivTel and DivTel will distribute charges and credits to SUNCOM clients. The vendor will propose new products, services and features by providing data about them in OaSIS either through direct data input or B2B-1 electronic transactions. The vendor s system will hold corresponding catalog data of authorized SUNCOM services but should not allow direct purchases by any SUNCOM clients. Inventory and invoicing data for all SUNCOM services will be designated in the vendor s system under a single SUNCOM billing account. Using B2B transactions or OaSIS will be the only SUNCOM user of the vendor s system. Vendors may hold User ID/passwords/PINs for SUNCOM client access to vendor systems when actual use of a service requires logging-in to a vendor system. However, all such user accounts must be created through OaSIS Orders. The vendor will accept no orders for SUNCOM services through any means other than OaSIS. The vendor will update OaSIS with fulfillment data (through B2B-4 transactions or manually) when the order is satisfied. The vendor will also be able to draft orders for SUNCOM clients in OaSIS. The vendor will send a single monthly hand bill for all SUNCOM services to DivTel and send substantiating electronic detail to OaSIS using B2B- 6 transactions (there is no manual equivalent to B2B-6 transactions). The vendor will work directly with, and issue appropriate credits to DivTel to settle any billing disputes and SLA violations related to all SUNCOM services. ITN NO. # Page 5 of 13

6 1.4.3 OaSIS Comprehensiveness and Primacy There are no conditions under this agreement where DivTel staff or SUNCOM clients will be required to manually use vendor systems to view, update or extract order, billing, inventory or account management data. These functions are exclusive to OaSIS. If the vendor proposes to grant DivTel or SUNCOM client access to its systems, DivTel will consider it to be a supplemental offering that does not displace any of the requirements described here for the vendor to exchange electronic data, or view and enter data into OaSIS. This policy combined with the centralization and standardization of of order processing and billing, means that OaSIS is able to encompass all substantive data related to service accounts. As such, no other source can be as complete and accurate in depicting SUNCOM services. Therefore, OaSIS will be presumed to be the official record of the inventory and costs of SUNCOM services by default e.g., the initial approach to reconciling billing disputes will consider the OaSIS data to be correct. Innacuracies might ocure within OaSIS data however, thus DivTel will negotiate discrepancies in good faith and compensate vendors for services rendered in accordance with SUNCOM client wishes that are expressed through OaSIS orders OaSIS Function Types and Interfaces with Vendors There are three primary ways to implement transactions between DivTel (OaSIS) and the vendor Application Program Interfaces The most desirable way to implement transactions with OaSIS in most cases is through Application Program Interfaces. APIs are defined here by five primary characteristics; 1) they are software routines initiated by a request from a business partner s system, 2) they accept data from that business partner and deliver data in return, 3) they perform these functions automatically upon demand at (near) real time, 4) interface procedures are defined and documented for business partners to use them and 5) they are followed by acknowledgements from the partner. OaSIS contains several APIs to facilitate the transactions described here. API acknowledgements merely confirm that a transaction has been received. However, acknowledgements can be included in associated B2B response transactions (e.g. B2B-4 fulfillments as the associated response to a B2B-3 order) when they can be provided within a few minutes of the requesting transaction Batch Routines A second way to implement transactions with OaSIS is through batch routines which is periodic exchanges of data files containing a large number of records. Monthly delivery of invoicing substantiation files (B2B-6) is the best example because of the large volume of data they contain. There may be other instances (like inventory reconciliation) where batch file exchanges are permitted, but APIs are more desirable. All batch transactions have acknowledgements which confirm that a transaction has been received Manual Review and Data Entry by Vendor Staff The third, least desirable means of implementing transactions with OaSIS is manual review and data entry by vendor staff in OaSIS. Vendors can use OaSIS screens for example, to view a submitted ITN NO. # Page 6 of 13

7 order from a client and mark that order as fulfilled rather than use B2B-3 and B2B-4 transactions. However, in every case where manual entry is permitted, OaSIS has made a more desirable API available for the same purpose to accelerate the process, eliminate duplicate data entry (given that the same data must be input into the vendor s system) and minimize inaccuracies. And there are two instances where manual entry is not permitted at all; 1) inventory reconciliation (B2B-5) and 2) invoicing substantiation (B2B-6). Of note, neither DivTel nor SUNCOM clients will input data into OaSIS on behalf of vendors. In all instances where the vendor is the source of data, the vendor must directly provide the data in OaSIS. For example, the vendor is required to verify that an order (submitted by the client) has been fulfilled. If the vendor is unable to do so electronically with a B2B-4 transaction, it must input the fulfillment data directly into OaSIS (rather than merely sending an to DivTel or its clients for example, verifying that the order has been fulfilled) Functions in SUNCOM OaSIS Catalog Relevant data regarding SUNCOM products, services and features, and the relationships between them, sold through this agreement (hereafter referred to as services ) will be listed in the OaSIS service catalog prior to making them available for use or purchase by any SUNCOM client. Even services which incur metered charges must be included in the catalog because DivTel will require SUNCOM clients to establish their rights to use metered services through an order prior to using them, i.e. ordering a metered service is an authorization to incur future metered charges. The vendor will propose new SUNCOM services by submitting the data into OaSIS. DivTel s preferred mechanism for receiving this data is through electronic Business-to-Business transactions (B2B-1). However, OaSIS will provide a screen for manual input of the data by the vendor. Table 2: Charge types defined One-time charge: a single payment for a service or item, e.g. hardware installation. Subscription charge: monthly fixed and recurring charge for the right to use something without regard to how much it is used, e.g. local phone service. Metered charge: incremental charge based strictly on how much the service is used, e.g. long distance phone minutes. Among the data submitted by the vendor and held in the OaSIS catalog will be elements indicating the relationships (compatibility) between different products, services and features. For example, if a feature works with one service but not another (and it is not a part of a bundled package), the catalog must reflect this so that OaSIS will preclude orders containing incompatible components. OaSIS is highly dependent upon the vendor having this same capability and providing the necessary data to OaSIS DivTel s Sole Discretion over the Catalog DivTel will have sole discretion over whether or not vendor s proposed services will be available for purchase in the OaSIS catalog and the prices charged to SUNCOM clients for them (prices will include cost recovery fees to cover SUNCOM operations). After the vendor submits the proposed service into OaSIS, the SUNCOM service manager will review it for completeness and accuracy of the data, compliance with the contract and its scope, fit ITN NO. # Page 7 of 13

8 within the portfolio of SUNCOM services, cost value of the service and consistency with DivTel s statutory charge to offer services that are in the best public interest. If the service manager authorizes a service, he/she will establish a price and make it available for purchase to SUNCOM clients through OaSIS. If the service manager rejects a service, it will not be made available for purchase through OaSIS, will not be enabled by the vendor to accrue any SUNCOM usage charges and DivTel will not pay any charges associated with it. Note however, there are unique circumstances where items can be purchased that do not appear in the catalog. Special construction (see on page 11), for example, may require nonstandardized products. When orders or invoices contain such items however, those items must be accurately priced and will receive special scrutiny from SUNCOM engineers who must approve the transaction Taxes and Government Sanctioned Fees in the Catalog Taxes are defined here to include payments that the vendor is required to collect by law and pay to public entities. They do not include surcharges and fees collected by the vendor which are not remitted to the government even if a government entity authorized collection (such government sactioned fees are subject to pricing negotiations). In the price sheet response to this ITN, the vendor should identify and explain all known taxes, surcharges and fees currently applicable to SUNCOM clients. No such taxes or fees shall be sought by the vendor if Florida public entities are exempt from paying them. Taxes and government sanctioned fees will be established in the service catalog prior to charging DivTel. Therefore, the standard process whereby the vendor submits a request for inclusion of services in the catalog and DivTel approves them must be implemented for taxes and fees with a few additional requirements. 1. The catalog item must be tagged as a tax or government sanction fee. 2. The description field provided by the vendor must clearly identify it. 3. The vendor must provide a complete explanation describing the basis for the tax/fee. This explanation must be sufficient for DivTel to develop formulas that replicate the charges through calculations against invoicing substantiation data. When the tax/fee changes, the vendor must update it in the OaSIS service catalog with approval from the SUNCOM service manager (otherwise, invoicing exceptions will occur because the charges will be inconsistent with what is expected) Account and User Management SUNCOM Client Users and Rights Before buying SUNCOM services, new clients will register in OaSIS and agree to DivTel terms and conditions (including deference to DivTel s authority to manage CPNI data). DivTel staff will review these registrations to verify SUNCOM eligibility. ITN NO. # Page 8 of 13

9 Once authorized to buy SUNCOM services, clients will establish at least one, or any number of OaSIS billing account(s) that will correspond to distinct invoices where SUNCOM charges will accrue. Clients will also establish users with comprehensive or distinct authorities to draft and submit orders, view invoices and inventory, etc. These authorities can be specified at the billing account level or apply to the entire client. Clients can also grant users authority to order specific classes of services and establish catalog restrictions to prevent orders of certain services on a given account. None of these client account and user management functions require any actions from the vendor either in the vendor s system or OaSIS Vendor Users & Rights OaSIS provides robust authority discrimination that will likely align with distinct job duties of vendor staff. Vendor staff will be able to use OaSIS for the following functions. 1. Input proposed services for inclusion in the SUNCOM service catalog (as an alternative to the B2B-1 transaction). 2. Update order fulfillment data (as an alternative to the B2B-4 transaction). 3. Assist clients by drafting orders that become vendor proposals in OaSIS for clients to later (modify and) submit (or delete). This is possible because user authorities can be restricted to draft only (i.e. lacking the authority to submit orders). 4. Review past orders submitted to the vendor. 5. Review a robust set of inventory data for services provided by the vendor. 6. Create other vendor staff users and give them rights. Consistent with OaSIS user management structure, DivTel will authorize a master user(s) designated by the vendor who will have all of these vendor authorities and who may authorize others to have any authorities of the master user. 7. OaSIS may provide other screens for vendor use in the future as well. DivTel reserves the right to terminate the OaSIS authorities of any vendor staff without cause or notice Orders An authorized client user of OaSIS will be able to search and view services in the OaSIS catalog and place orders for them under specific OaSIS billing accounts. Clients can create orders in stages including drafts that can be routed to others for approval before officially placing an order. Upon completion, B2B-3 transactions will be sent to the vendor or the vendor can log-on to OaSIS, as prompted by an OaSIS , to see submitted orders. From the perspective of the SUNCOM client, a single order may contain several items (services). Thus the vendor will receive distinct work orders for each item. This allows for partial fulfillment of an order where appropriate (otherwise, multiple item orders with only a single order number cannot be fulfilled until every item is delivered). Therefore, vendors are required to respond with distinct B2B-4 fulfillment data for each work order (item). ITN NO. # Page 9 of 13

10 Vendors must provide all of the required fulfillment data in OaSIS. While they are strongly encouraged to provide automated fulfillment transactions to OaSIS to prevent inaccuracies, delays and duplication of effort, OaSIS provides a screen for vendors to manually update orders with fulfillment data as an alternative to electronic B2B-4 messages. DivTel cannot invoice its client without associating key fields from orders to SUNCOM client invoicing accounts in OaSIS and therefore, will not pay for any services where such data is missing or incorrect. Installation and disconnect dates are also critical to the inventory as they are used during audits to verify that a service was active, or should not have been, during an invoicing period. Some orders will include configuration data including IP addresses to enable establishing closed user groups on the State network. Table 3: Some key data elements Order ID identifies a request for one or more items. This ID is associated with everything in a shopping cart when a client checks-out. Work Order ID is associated with each item request within an Order that can be fulfilled separately from the rest of the Order. Installed Option ID identifies the service, feature or hardware from the Service Catalog that was requested in the Work Order. Service Installation ID identifies the service account resulting from Order fulfillment. It is the unique inventory entry in OaSIS and is equivalent to, but not the same as, distinct IDs used by vendors to track status, usage and charges (e.g. circuit ID, phone number, hardware serial number, etc.). Installed Option ID Service Catalog Table Vendor Price SUNCOM Price Order ID Order Work Orders (B2B-3) Work Order ID (installation) Work Order ID (disconnect) Installed Option ID Service Installation ID Fulfillments (B2B-4) Service Installation ID Installation Date Disconnect Date Service Installation ID Installed Option ID Vendor Price SUNCOM Price Inventory Table Work Order ID Order ID Installation Date Disconnect Date Service Installation ID Installed Option ID Invoice Detail (B2B-6) Vendor Price Quantity Cost Note that the above conceptual model of SUNCOM tables and B2B transactions is designed to convey how core data elements are shared between them, but is not a comprehensive depiction of all of the required data elements and tables. Figure 3: Conceptual sample of data files and B2B transactions Credential Request Orders Some of the orders submitted to the vendor will request granting SUNCOM client password/pin protected access to vendor services. These are services that require clients to log-in (or be electronically certified) to vender systems before using a service. While a subscription charge might ITN NO. # Page 10 of 13

11 be associated with such orders (i.e. a monthly charge might be incurred for the right to use the account), it enables metered consumption of the associated service for which the right to access must first be ordered through OaSIS. OaSIS will be the exclusive source for orders requesting the right to access regardless of the cost, or lack thereof, associated with the service. Like all other services, the right to access them will be ordered with B2B-3 transactions from OaSIS providing the vendor with necessary data to enable that access. The vendor is expected to respond Figure 4: Credential Request Order Example SUNCOM conferencing services are current examples of credential request orders. Users of the service must login to a vendor s system to reserve or initiate a conference. Thus, the vendor issues login credentials to those users that were obtained after an order for them (B2B-3) was placed in OaSIS. The order is fulfilled by the vendor supplying a user ID and Personal Identification Number (PIN) via to the user, then confirming fulfillment to OaSIS with a B2B-4 transaction. These transactions enable OaSIS to have a complete inventory of all of the users of the service which is periodically confirmed through B2B-5 transactions with the vendor. The vendor s system tracks usage that is attributable to each user, which is compiled in a B2B-6 monthly batch file of invoicing substantiation. by confirming to OaSIS that it has been provided. However, OaSIS will not hold user passwords and PINs for access to vendor systems thus the vendor is expected to provide them to users directly using addresses provided in the OaSIS order. PIN and password changes should be handled outside of OaSIS as well Special Construction Orders Fulfilling some service requests under this contract will require providing services not readily defined in the Service Catalog and/or require the vendor to determine the quantity of cataloged services and/or propose a unique configuration. Examples include wiring installation at the client s site; the amount of wiring and work to install it can only be determined after a site assessment by the vendor. These are known as special construction orders. As mentioned in Vendor Users & Rights, vendor staff can draft orders to become vendor proposals in OaSIS for SUNCOM engineers and clients to later (modify and) submit (or delete). This is the mechanism for vendors to make special construction proposals and for clients to place the order. When a client has submitted an order drafted by a vendor, they have effectively accepted the vendor s proposal and authorized the work. To the extent possible, special construction orders should name and quantify all of the services from the OaSIS service catalog that will be used. But with some special construction, all of the hardware or services required might not be in the catalog. Thus these orders may also contain items not listed in the service catalog. With service manager approval, these services/hardware might be subsequently added to the catalog. But in all cases, the total cost of the proposed order must be defined and approved prior to submittal. In addition to naming services to be provided, the order will contain other data necessary to specify and authorize the service like target installation dates, locations, configuration data and even documents containing diagrams where available Inventory Every order and many other actions related to SUNCOM services are permanently logged into OaSIS. This inventory is a basis for DivTel audits of vendor charges, i.e. if a billed service is not in ITN NO. # Page 11 of 13

12 the inventory or the inventory shows it was not active during the invoicing period, DivTel will dispute the charge. The OaSIS inventory is also a useful tool for DivTel, SUNCOM clients and vendors to see what has been ordered, its status, where it located, its cost, any associated comments, etc. OaSIS inventory is structured around key data elements. No inventory record is valid without these key fields thus posing invoicing disputes when they are missing or inaccurate. And OaSIS by default, has primacy when there are discrepancies between the inventories of the vendor and OaSIS Inventory Reconciliation Vendors should maintain a corresponding inventory as a basis for invoicing DivTel. Clearly the two inventories should agree, yet there are many reasons they might not. Therefore, periodic reconciliation should be implemented between the two with B2B-5 transactions rather than wait until the vendor invoices DivTel to discover these inconsistencies and resolving them exclusively through billing disputes. DivTel will provide for an exchange of inventory data throughout the month using transaction B2B-4. There is no manual substitute for this process Invoicing The vendor will invoice DivTel monthly for all SUNCOM services and fulfilled orders. Invoices will consist of 1) a single request for payment on unchangeable format (e.g. paper) known as a hand bill which reflects the total charges for the month, and 2) electronic detail files that substantiates all billable services. The total of substantiated detail charges must match the single payment request on the hand bill Electronic Substantiating Detail File The invoice substantiation file consists of ASCII delimited electronic detail listing all billable services and activities with all unique IDs necessary to be auditable basses for all charges. A common, but not required format for these files is Electronic Data Interchange (EDI transaction number 810 Consolidated Invoicing ). The detail file must include all charge data on one-time purchases, active subscription periods and metered incremental activities. All charges must be attributable to distinct identifiers from the service catalog and each discrete metered charge must be distinguished by service account in OaSIS. Metered charges must also include date/time stamps for each billing event DivTel Response to Vendor Invoices OaSIS will pre-audit the invoice to match all charges against the current inventory of provided services and to the prices associated with the services in the catalog. Barring audit exceptions, DivTel will pay the vendor the total charges on behalf of all SUNCOM clients for all services rendered. If the electronic substantiating detail provided by the vendor contains some errors but is a) complete (i.e. contains all of the required data elements) b) substantially corresponds with the OaSIS inventory and service catalog, and c) matches the hand bill, DivTel will send an exception report (B2B-7) to the vendor detailing any disputed charges. DivTel staff will request credits for any exceptions on the current invoice and work with vendor staff to reconcile charges and system data to resolve the exceptions. The primary, but not exclusive criteria for rejecting an invoice is found in answer to this question; does the substantiation file contain enough accurate detail information to enable DivTel to clearly ITN NO. # Page 12 of 13

13 and accurately reinvoice its clients? If not, DivTel will reject the invoice, request the vendor rescind the charges and submit a new invoice. ITN NO. # Page 13 of 13