Download as xls, pdf, or txt
Download as xls, pdf, or txt
You are on page 1of 16

Business Requirements for <Project Name>

Revision History Description

Revision

Date

Changed By

Intended audience Business Partners, Stakeholders and Sponsors Functional Resources Technical Resources

BUSINESS PROCESS
Billing Requirements Ref# Requestor Priority Importance (Weight) Requirements Status Deliverables Acceptance Criteria

Business Process Requirements Process 1 Short Term Medium Term Long Term Customer Trial: FTP the BDRs to the customer, but billing (invoicing) is not enabled yet. Minimum Invoice Amount (able to defer when this minimum begins). Ability to customize daily FTP files for each customer Ability to have daily FTPs (from provisioned system to billing system) have different fields sent for each activity (i.e. the way that it is today) Will need to be part of contract definition page that is custom. Will need to be part of contract definition page that is custom. Done in combination with pricing rules.

108.0 Dranginis, Dianne 109.0 Dranginis, Dianne 113.0 Dranginis, Dianne

5 4 1

114.0 Dranginis, Dianne Process 2

Incorporated into the design.

110.0 Dranginis, Dianne

Example: Customer in production, but doing Bill Integration testing. Need a way to 'mark' a BDR to not invoice - although would be included in the FTP. Define if this should appear as part of the Bill and also credited or don't appear at all or show at $0. BDR's marked to not invoice should include recording a reason as part of 'marking' the BDR to not invoice.

Will need to be part of contract definition page that is custom. Also a custom page to go into a BDR and mark it specifically to not bill.

111.0 Dranginis, Dianne Process N

For each customer, Voyant has an account - used for testing, etc. We will need to identify the Subscriber ID that is tied to Voyant for each customer ('Provider ID'). These transactions should be filtered from the FTP and the invoicing. (Record the Voyant subscriber ID on the contract definition page. We round up BDRs to the nearest minute when we bill. Thus, if a recording lasted 10 seconds it would state that in the BDR, but the customer and service provider should be billed for 1 minute.

Will need to be part of contract definition page that is custom.

112.0 Dranginis, Dianne

63991417.xls

CONFIDENTIAL 07/27/2011

2 of 16

FUNCTIONAL BUSINESS REQUIREMENTS


Billing Requirements Ref# Requestor Functional Requirements Integration INT 1.0 INT 2.0

Requirements

Status

Deliverables

Acceptance Criteria

Configure new billable evenys from production system Billing usage data is sent to Avante without cost information already attached, and is not ready to post.

Need to define a process for getting new billing event messages into PS PeopleSoft custom table would accept the BDR records. In generating the sales order or invoice, we would leverage the standard PS Price Rules to calculate prices. Yes, but the billing run would be only for those BDR records received to date and pricing would be based on the group of BDR records processed at the same time. Define number of activities I think it won't be a problem. The solution is based on accumulating the BDR records and summarizing them to the invoicing and accounting processes. So the BDR records would consume about 3000 records per day (90000 records per month), but would summarize to approximately 20 invoice lines per customer per month. The actual printing of the invoice (statement) would provide the approximately 20 line summary followed by printing the BDR details on subsequent pages.

INT

3.0

Ability to run the billing application on demand

INT

4.0

Scalable to large quantities of data

General GEN GEN

5.0 6.0

Enhanced Services Enhanced Services

Identify and bill for recordings requiring multiple CDs Provide shipping and tax charges at an item level

Function of BDR Susan Sowl to coordinate this issue with Sandra Hahn Future Release: This is a function of how the data is grouped. We anticipate consolidating BDR records of the same time and the same location, so that tax would not be at the BDR record, only at the accumulated record. Yes

GEN

7.0

Accounting

Identify records in the database that have been processed for customer billing, and for accrued billing. Produce one file at the service provider level to input all billing usage information into Avante for use in billing the service provider. Summarize for journal entry post. Identify Service Provider internal usage of service and media orders, flag these records for sales and use taxing. Calculate Administration minutes Ability to address current product, contract billing and services billing functionality including Mobile Meeting requirements Link between Siebel and billing system

GEN

8.0

Accounting

Standard posting process

GEN

9.0

Accounting

Future Release: We will need a method for this indentification and then we can support separate sales/use tax per ship-to and by product classification. Admin: (offhook - toll free playback) where offhook are Custom process to develop. only those records with subscriber information. Mobile meeting requirements Need Mobile Meeting Requirements

GEN GEN

10.0 Enhanced Services 11.0

GEN 12.0 General Ledger G/L Reporting G/L 13.0

No, possibly Future Release.

Report G/L with gross, net, discount and tax amount line items

Yes. custom develop direct billing interface and standard invoice process will do these postings to GL.

Functional

CONFIDENTIAL 07/27/2011

3 of 16

FUNCTIONAL BUSINESS REQUIREMENTS


Billing Requirements Ref# Requestor Functional Requirements G/L 14.0 G/L 15.0

Requirements Automated load of G/L data (in a JE format) from Billing System to Avante Automated filed upload from Billing System to Avante G/L with unbilled reversal information. Ability to manually enter adjustments

Status

Deliverables

Acceptance Criteria Yes. Standard Functionality. Yes. Standard Functionality.

Manage Credits/Adjustments ADJ 16.0

Standard capability for adjustments to an Invoice. Custom for adjustments to a specific BDR record (billed vs not billed yet). Must be in $ amount. Text could define %. Yes Yes, but bill line items would be summarized BDR records. Adjustments would be made to the BDR record creating a new BDR record that is a credit and/or adjustment. These adjustments would have pricing fixed and would be included in the next invoicing cycle (but summarized with other BDR to an invoice line). Credits might need to not be summarized so that they show on the summary page as well as the detail page - functional design decision.

ADJ ADJ ADJ

17.0 18.0 19.0

Support for partial and full adjustment in percent or $ amounts Ability to calculate tax on adjustments Ability to tie an adjustment to a line item on a bill

ADJ

20.0

Ability to assign reason codes when applying credits, or freeform credits and not be forced to assign codes Ability to enforce an adjustment approval process (only certain user types can approve adjustments)

Yes.

ADJ

21.0

Automated adjustment approval not available. Will need to be procedural and Enhanced Services to work with Dave Nelson (Dir Credit & Collections)

Customer Management Account Creation Custom development to associate service provider ID with internal to system customer ID. Customer ID will be used to track within PS. Yes Yes Future Release: This is not clear. We can support a multi-level hierarchy of a customer definition. A customer record specifies it's parent. However, the consolidation key for billing is only a single level. So customers A, B, C, and D - B, C, and D can consolidate invoices to A. A can have B and C as children and B can havd D as a child to it.

1.0 2.0 3.0

Ability to assign a meaningful service provider ID and use that to track customers throughout the system. Ability to store different bill to: and send to: addresses Ability to store customer's credit limit Ability to support a multi-level billing hierarchy and report differently for different customers

4.0 5.0

Support customer specific rates (prices/contracts) Ability to maintain different payment terms for customers

Yes. Standard. Yes. Standard.

Functional

CONFIDENTIAL 07/27/2011

4 of 16

FUNCTIONAL BUSINESS REQUIREMENTS


Billing Requirements Ref# Requestor Functional Requirements 6.0

Requirements Ability to apply discounts throughout customer hierarchy

Status

Deliverables

Acceptance Criteria Future Release: Sort of. The discount defintion would have all of the customers tied to it. So a discounting rule could apply to only A or also to A, B, C, and D.

Order Management 7.0

Ability to store pending status CD/transcripts and dates for products for an account

Future Release: BDR to carry status that it is 'pending'. If created as an order and not fulfilled yet, then can be shown as backlog. Orders can also be entered in Pending status, but if these come from the BDR there is no support for this. Design of customization will determine how easily. Reqmt: Add new types of BDRs, Change pricing. Yes

8.0 9.0

Ability to easily modify service information Ability to store contract number, PO number for VRAP contracts and associated PO's for Professional Services Ability to view current charges on-line by service provider Reporting out of PS. If can be supplied, then would want to include non-billable events so that all reporting from one place.

10.0 Reports 10.5

Future Release: Web access by service provider to see current charges on-line. Reporting can be provided through: PS Query, Business Objects, and Crystal Reports

Accounts Receivable 11.0 12.0 13.0 14.0 15.0 16.0 17.0 18.0 General Ledger 19.0 20.0 21.0 22.0

Accounts Receivable Summary Accounts Receivable Detail Payments Summary Payments Detail Reversals Summary Reversals Detail Refunds Summary Refunds Detail

Payments Summary Payments Detail Reversals Summary Reversals Detail Refunds Summary Refunds Detail Lists all the G/L Shows the accounts in summary the Infranet impact on database. each G/L Breaks account revenue balance down a duringby product, specified showing time period total debit by resource Shows revenue for and then by credit each G/L ID. adjustments product. by Includes geographical productsof location whether or accounts. not they have a G/L CONFIDENTIAL 07/27/2011 ID.

Yes Only to summarized BDR Level. Yes Only to summarized BDR Level. Yes Only to summarized BDR Level. Yes Only to summarized BDR Level.

General Ledger - Chart of Accounts General Ledger Summary General Ledger Detail Product Revenue

Yes Yes Yes The level of detail that company is willing to track. Greater detail is tracked in our RevFlash reporting soln.

Miscellaneous Adjustments 23.0

Miscellaneous Adjustments Summary

Yes, as adjustments to BDR are created in the BDR records on PS Side.

Functional

5 of 16

FUNCTIONAL BUSINESS REQUIREMENTS


Billing Requirements Ref# Requestor Functional Requirements 24.0 Subscriber Accounts 25.0 26.0 27.0 28.0 Tax 29.0 30.0 31.0 32.0 Misc 33.0 34.0 35.0 36.0 Orders Report Forecast report - off current orders and long term forecast report Voyant Sales Report Pre-Billing Report - Ability to view unbilled usage, current charges throughout the month Define details Define details Define details Need details Need details Fulfill through RevFlash reporting. Possible to create such a report. Tax Jurisdiction Summary Tax Jurisdiction Detail Summary of all Taxes Tax Exempt Accounts

Requirements Miscellaneous Adjustments Detail

Status For each customer account, shows Shows the event-level number of debit and accounts credit Shows the created or adjustments. number of closed accounts during a Shows the created or specified length of closed time period, serviceafor during the Shows and new shows weeklyof the net or length accounts. monthlyfor service change in period, and closed accounts. shows the accounts. net change in accounts by period.

Deliverables

Acceptance Criteria Yes, as adjustments to BDR are created in the BDR records on PS Side. Need specific requirements of changes Need specific requirements of changes Part of setup of contract Part of maintenance of contract.

Account Changes - Single Period Account Changes - Multiple Periods New Account Lifetime Closed Account Lifetime

Std Std Std Std

Billing Billing Cycle 37.0 Enhanced Services Support minimum and maximum charge amounts verify that minimum charge has been met 1 Custom Development. Could force to replicate pricing functionality offline. If so, might as well pass directly to Billing Interface. Standard Can do both.

38.0 39.0

Support modifications to existing products / service 1 offerings/ prices and quote modifcations Produce single, consolidated invoice per billing cycle for customers, separate invoices for different services if desired Ability to run billing application on demand

40.0

Future: Yes, but would only obtain invoices for BDR records delivered to date and pricing will be based on the BDR records accumulated for a single invoice (not across invoices). (Perhaps pricing as if through this date.) This can be setup. Examples: VRAP Private# Private# Provisioned, Recurring Charge for Private#, Private# Dropped. Mobile Meeting - Site Commissioned, Monthly fee per site, Site Decommissioned.

41.0

Ability to manage and bill for recurring charges for various cycles e.g. monthly, quarterly, annually. (Private numbers)

Functional

CONFIDENTIAL 07/27/2011

6 of 16

FUNCTIONAL BUSINESS REQUIREMENTS


Billing Requirements Ref# Requestor Functional Requirements 42.0 43.0 44.0 Enhanced Services

Requirements Ability to support a multi-level billing hierarchy Ability to pull all open credits/adjustments into an invoice Ability to set the default billing frequency, and change 1 if needed

Status

Deliverables

Acceptance Criteria Future: Explained under customer mgmt. Only through the consolidation key. We will build that into the contract definition page. Need to determine impact on volume discounts and prorating if change from a cycle of 16th through 15th to 1st through 31st. How to handle transition month of 16th through 31st? Don't expect to need this initially.

45.0 46.0 47.0

Enhanced Services Enhanced Services

Ability to have multiple billing cycles

Automatic bill back-out capabilities Ability to obtain usage from multiple collection points on a daily (configurable) basis System must store information that supports a service business: running total of charges, previous payments, outstanding balances, payment due date, etc..

Yes, but only one billing cycle per customer. Multiple means across multiple customer. Standard capability is a credit/rebill. No automatic back-out. Load BDR records can be configured for how frequently loaded. Need explanation on multiple collection points. This is information in the AR system, but at the invoice level - not details.

48.0

Taxes Calculation 49.0 50.0 51.0 1 Ability to automatically calculate tax based on jurisdiction and product or link to tax table product 1 Ability to automate tax calculations during bill generation or at time charge is assessed Ability to tax for sales/use taxes on products and recording/playback services on an individual item level. Future: Yes Future: Tax is calculated at time of invoicing. Future: No. We will accumulate by type of BDR into a single invoice line item (scalability) and report details from the BDR custom data storage. Future: Need info on this. Std is No. Reqmt is when and if service is sold directly to end users.

52.0

Ability to support FCC taxing ?

53.0 54.0 Interface 55.0 Manage Payments Payment Processing 56.0 57.0

Ability to support tax exemptions Support Sales & Use Tax Reports

1 1

Yes. Standard. Future: Yes. Standard through Taxware.

Ability to interface with Tax software

Future: Yes

Support Lockbox (electronic bank file) for checks payment processing Support for credit card processing for payment

1 nice to have

Yes Could

Functional

CONFIDENTIAL 07/27/2011

7 of 16

FUNCTIONAL BUSINESS REQUIREMENTS


Billing Requirements Ref# Requestor Functional Requirements 58.0 59.0 Late Payments 60.0 Under/Over Payments 61.0 Additional Payments 62.0 Interface 63.0 64.0 Price Plans

Requirements Ability to receive payment via Electronic Fund Transfer 1 Support manual payment posting Support to apply business rules to assess penalties, interest fees and cancellation fees Ability to determine if a customer underpaid or overpaid through statements Ability to post payment by bill number Ability to interface for EFT requests Ability to interface with lockbox 1 1

Status

Deliverables

Acceptance Criteria I don't think we are doing this yet, but system does support it. Yes Custom development

Assuming that we generate statements, yes.

1 1 1

Yes I don't think we are doing this yet, but system does support it. Yes

Rate Application/Rating Rules 65.0 Support customer-specific rates 66.0 Accounting/ Enhanced Services

Yes Need examples to understand requirement.

67.0

1 Capability for tiered, threshold, volume and headquarters discounting and view on the bill Support aggregation, calculation and allocation of 1 non-recurring and recurring charges based on customer's products/services Ability to assess shipping charges on an item 1 basis Ability to maintain and bill for services on a prorated basis - (specifically for private numbers) Support advanced customer account hierarchy processing for rate/discount aggregation, calculation, and allocation purposes Ability to associate usage/transaction charges with products/services Ability to associate time and expenses for professional services Ability to assign start and end dates to pricing of products/services by contract basis Ability to have flag for renewal that can be managed Ability to assign start and end dates to product/service rates 1 1

Aggregation can be supported. Calculation and allocation would need custom development - pre invoice creation. Need examples to understand requirements. Yes. This is on the BDR record. Yes

68.0 69.0 Accounting/ Enhanced Services

70.0

See customer information and above.

71.0 72.0 Effective Dates 73.0 Enhanced Services

1 1

Yes Yes

Part of definition of custom contracts page (it is std in contracts, but contracts won't suffice for these other requirements. Part of definition of custom contracts page (it is std in contracts, but contracts won't suffice for these other requirements. Standard in price rules.

74.0

75.0

Functional

CONFIDENTIAL 07/27/2011

8 of 16

FUNCTIONAL BUSINESS REQUIREMENTS


Billing Requirements Ref# Requestor Functional Requirements

Requirements

Status

Deliverables

Acceptance Criteria

Promotions and Discounts 76.0 77.0

Ability to manage product and service discounts Ability to support promotions

1 1

Standard in price rules Example: 90 day free trial - 100% discount. Don't Standard in price rules charge for a particular service withina period. Through price rules, not directly on order/invoice. Custom 'Statement' Development

78.0 79.0

Ability to discount by a percentage On invoice, suppress the record if the qty of the service is $0, but include the record if the qty != 0 but the price/amount is $0. Easily maintainable product and price list Modifications to price list do not change customers with pre-existing contracted prices

Manage/Administration 80.0 81.0

1 1

You be the judge of how easy it is. This will take some thinking on how to setup so that existing contracts are not changed with price list changes.

Invoices Content 82.0 83.0 Ability to produce different invoice formats for each customer, use of a GUI interface to accomplish this Ability to display previous amount due, previous payment, total current amount due Ability to display sub-totals and adjustments Ability to display discounts on the invoice Ability to display taxes on the invoice, aggregated per bill and displayed by line item Ability to display the invoice date on the bill Ability to display customer id on the bill Ability to display contract number Ability to display PO number with associated invoice line items for professional services Ability to display variable messages on invoices Ability to sort the bill sections (i.e.. Recurring Charges, Services, Products) by billable item Ability to display payment terms Ability to display the period-covered dates on the invoice Yes Not a GUI interface for invoice format creation. Different invoice formats can be supported, but recommend varying formats on an exception basis. Use Statements - not invoices. Yes Usually not, but we can do so. Qty breaks can be defined by a different discount. Yes. My definition of line item is the aggregated BDR by location, not each BDR. Yes Yes Yes Yes Through Notes Custom development, but Yes

84.0 85.0 86.0 87.0 88.0 89.0 90.0 91.0 92.0 93.0

Enhanced Services Accounting Accounting Accounting

1 1 1 1 1 1

Accounting

94.0 95.0 96.0

Yes Yes No. We can throw invoices away though.

Support line item product name/description on invoice 1 Ability to send/not sendpaper copy of invoices to all customers regardless of payment method Ability to display $0 balances on invoice for free periods/promotions 1

97.0

Yes

Functional

CONFIDENTIAL 07/27/2011

9 of 16

FUNCTIONAL BUSINESS REQUIREMENTS


Billing Requirements Ref# Requestor Functional Requirements 98.0 Enhanced Services

Requirements Ability to provide the Subscriber Report at top-line detail service provider, subscriber detail level, recording id level and activity level, depending on customer request Ability to provide the Subscriber Report at top-line detail service provider, subscriber detail level, recording id level and activity level, depending on customer request, with invoice dollars associated with it. Ability to provide invoice support pages 2 - 500. This will include the Subscriber Report with the operational billing information at various levels mentioned above, with the correct charges associated with it. Invoices must provide information to support a service business: show a running total of charges, previous payments, outstanding balances, payment due date, etc.. Ability to group services and products together, in whatever grouping desired.

Status

Deliverables

Acceptance Criteria Need specs on the Subscriber Report (detailed pages of Invoice/Statement).

99.0

Enhanced Services

Need specs on the Subscriber Report. (detailed pages of Invoice/Statement).

100.0 Enhanced Services

Need specs on the Subscriber Report. (detailed pages of Invoice/Statement).

101.0 Acounting

Through Statements

102.0

Not in whatever grouping is desired. In a specified grouping that gets defined.

103.0 Delivery Method 104.0 105.0 106.0 107.0 Additional Requirements Content

Support for perforated remittance slips

Future: No, until volume warrants this.\

Ability to produce paper invoices Ability to send electronic fund transfer with invoice amount Ability to web interface with query commands Ability to send e-mail of invoice

1 1

Yes Yes, but not using this yet. Yes, but not implemented yet. Yes.

Customer Trial: FTP the BDRs to the customer, but 108.0 Dranginis, Dianne billing (invoicing) is not enabled yet. Minimum Invoice Amount (able to defer when this 109.0 Dranginis, Dianne minimum begins). 113.0 Dranginis, Dianne Ability to customize daily FTP files for each customer Ability to have daily FTPs (from provisioned system to billing system) have different fields sent for each 114.0 Dranginis, Dianne activity (i.e. the way that it is today) Discount Periods

Will need to be part of contract definition page that is custom. Will need to be part of contract definition page that is custom. Done in combination with pricing rules.

Incorporated into the design.

Functional

CONFIDENTIAL 07/27/2011

10 of 16

FUNCTIONAL BUSINESS REQUIREMENTS


Billing Requirements Ref# Requestor Functional Requirements

Requirements

Status

Deliverables

Acceptance Criteria

Example: Customer in production, but doing Bill Integration testing. Need a way to 'mark' a BDR to not invoice - although would be included in the FTP. Define if this should appear as part of the Bill and also credited or don't appear at all or show at $0. BDR's marked to not invoice should include recording 110.0 Dranginis, Dianne reason as part of 'marking' the BDR to not invoice. a

Will need to be part of contract definition page that is custom. Also a custom page to go into a BDR and mark it specifically to not bill.

For each customer, Voyant has an account - used for testing, etc. We will need to identify the Subscriber ID that is tied to Voyant for each customer ('Provider ID'). These transactions should be filtered from the FTP and the invoicing. (Record the Voyant subscriber ID on the 111.0 Dranginis, Dianne contract definition page. Rounding We round up BDRs to the nearest minute when we bill. Thus, if a recording lasted 10 seconds it would state that in the BDR, but the customer and service provider 112.0 Dranginis, Dianne should be billed for 1 minute.

Will need to be part of contract definition page that is custom.

Functional

CONFIDENTIAL 07/27/2011

11 of 16

INTEGRATION
Billing Requirements Ref# Requestor Integration Requirements Content Requirements Status Deliverables Acceptance Criteria

108.0 Dranginis, Dianne 109.0 Dranginis, Dianne 113.0 Dranginis, Dianne

Customer Trial: FTP the BDRs to the customer, but billing (invoicing) is not enabled yet. Minimum Invoice Amount (able to defer when this minimum begins). Ability to customize daily FTP files for each customer Ability to have daily FTPs (from provisioned system to billing system) have different fields sent for each activity (i.e. the way that it is today)

Will need to be part of contract definition page that is custom. Will need to be part of contract definition page that is custom. Done in combination with pricing rules.

114.0 Dranginis, Dianne Discount Periods

Incorporated into the design.

110.0 Dranginis, Dianne

Example: Customer in production, but doing Bill Integration testing. Need a way to 'mark' a BDR to not invoice - although would be included in the FTP. Define if this should appear as part of the Bill and also credited or don't appear at all or show at $0. BDR's marked to not invoice should include recording a reason as part of 'marking' the BDR to not invoice.

Will need to be part of contract definition page that is custom. Also a custom page to go into a BDR and mark it specifically to not bill.

111.0 Dranginis, Dianne Rounding

For each customer, Voyant has an account - used for testing, etc. We will need to identify the Subscriber ID that is tied to Voyant for each customer ('Provider ID'). These transactions should be filtered from the FTP and the invoicing. (Record the Voyant subscriber ID on the contract definition page. We round up BDRs to the nearest minute when we bill. Thus, if a recording lasted 10 seconds it would state that in the BDR, but the customer and service provider should be billed for 1 minute.

Will need to be part of contract definition page that is custom.

112.0 Dranginis, Dianne

63991417.xls

CONFIDENTIAL 07/27/2011

12 of 16

SYSTEM PERFORMANCE
Billing Requirements Ref# Requestor System Performance Requirements On-Line Response Requirements Status Open Issue PeopleSoft Capability

108.0 Dranginis, Dianne

Customer Trial: FTP the BDRs to the customer, but billing (invoicing) is not enabled yet. Minimum Invoice Amount (able to defer when this minimum begins). Ability to customize daily FTP files for each customer Ability to have daily FTPs (from provisioned system to billing system) have different fields sent for each activity (i.e. the way that it is today)

Will need to be part of contract definition page that is custom. Will need to be part of contract definition page that is custom. Done in combination with pricing rules.

109.0 Dranginis, Dianne 113.0 Dranginis, Dianne

114.0 Dranginis, Dianne Schedule Frequency

Incorporated into the design.

110.0 Dranginis, Dianne

Example: Customer in production, but doing Bill Integration testing. Need a way to 'mark' a BDR to not invoice - although would be included in the FTP. Define if this should appear as part of the Bill and also credited or don't appear at all or show at $0. BDR's marked to not invoice should include recording a reason as part of 'marking' the BDR to not invoice. For each customer, Voyant has an account used for testing, etc. We will need to identify the Subscriber ID that is tied to Voyant for each customer ('Provider ID'). These transactions should be filtered from the FTP and the invoicing. (Record the Voyant subscriber ID on the contract definition page. We round up BDRs to the nearest minute when we bill. Thus, if a recording lasted 10 seconds it would state that in the BDR, but the customer and service provider should be billed for 1 minute.

Will need to be part of contract definition page that is custom. Also a custom page to go into a BDR and mark it specifically to not bill.

111.0 Dranginis, Dianne Etc.

Will need to be part of contract definition page that is custom.

112.0 Dranginis, Dianne

63991417.xls

CONFIDENTIAL 07/27/2011

13 of 16

AUDIT, SECURITY, CONTROL


Billing Requirements Ref# Requestor Audit, Security, & Control Requirements Audit Requirements Status Open Issue PeopleSoft Capability

108.0 Dranginis, Dianne

Customer Trial: FTP the BDRs to the customer, but billing (invoicing) is not enabled yet. Minimum Invoice Amount (able to defer when this minimum begins). Ability to customize daily FTP files for each customer Ability to have daily FTPs (from provisioned system to billing system) have different fields sent for each activity (i.e. the way that it is today)

Will need to be part of contract definition page that is custom. Will need to be part of contract definition page that is custom. Done in combination with pricing rules.

109.0 Dranginis, Dianne 113.0 Dranginis, Dianne

114.0 Dranginis, Dianne Security

Incorporated into the design.

110.0 Dranginis, Dianne

Example: Customer in production, but doing Bill Integration testing. Need a way to 'mark' a BDR to not invoice - although would be included in the FTP. Define if this should appear as part of the Bill and also credited or don't appear at all or show at $0. BDR's marked to not invoice should include recording a reason as part of 'marking' the BDR to not invoice. For each customer, Voyant has an account used for testing, etc. We will need to identify the Subscriber ID that is tied to Voyant for each customer ('Provider ID'). These transactions should be filtered from the FTP and the invoicing. (Record the Voyant subscriber ID on the contract definition page. We round up BDRs to the nearest minute when we bill. Thus, if a recording lasted 10 seconds it would state that in the BDR, but the customer and service provider should be billed for 1 minute.

Will need to be part of contract definition page that is custom. Also a custom page to go into a BDR and mark it specifically to not bill.

111.0 Dranginis, Dianne Control

Will need to be part of contract definition page that is custom.

112.0 Dranginis, Dianne

63991417.xls

CONFIDENTIAL 07/27/2011

14 of 16

EXCLUSIONS

Billing Requirements Ref# Exclusions Subject Area 1

Requestor

Exclusions

Status

Open Issue

PeopleSoft Capability

108.0 Dranginis, Dianne

Customer Trial: FTP the BDRs to the customer, but billing (invoicing) is not enabled yet. Minimum Invoice Amount (able to defer when this minimum begins). Ability to customize daily FTP files for each customer Ability to have daily FTPs (from provisioned system to billing system) have different fields sent for each activity (i.e. the way that it is today)

Will need to be part of contract definition page that is custom. Will need to be part of contract definition page that is custom. Done in combination with pricing rules.

109.0 Dranginis, Dianne 113.0 Dranginis, Dianne

114.0 Dranginis, Dianne Subsject Area 2

Incorporated into the design.

110.0 Dranginis, Dianne

Example: Customer in production, but doing Bill Integration testing. Need a way to 'mark' a BDR to not invoice - although would be included in the FTP. Define if this should appear as part of the Bill and also credited or don't appear at all or show at $0. BDR's marked to not invoice should include recording a reason as part of 'marking' the BDR to not invoice. For each customer, Voyant has an account used for testing, etc. We will need to identify the Subscriber ID that is tied to Voyant for each customer ('Provider ID'). These transactions should be filtered from the FTP and the invoicing. (Record the Voyant subscriber ID on the contract definition page.

Will need to be part of contract definition page that is custom. Also a custom page to go into a BDR and mark it specifically to not bill.

111.0 Dranginis, Dianne

Will need to be part of contract definition page that is custom.

63991417.xls

CONFIDENTIAL 07/27/2011

15 of 16

Acceptance & Signoff

Warren Baxley

[Print]

Sign

Date

John Duane

[Print]

Sign

Date

Robert Hagen

[Print]

Sign

Date

George Lantz

[Print]

Sign

Date

Randy Schultz

[Print]

Sign

Date

Paula Casey

[Print]

Sign

Date

Dave Nelson

[Print]

Sign

Date

Neil Dickson

[Print]

Sign

Date

Jeremy Anderson

[Print]

Sign

Date

63991417.xls

CONFIDENTIAL 07/27/2011

16 of 16

You might also like