Professional Documents
Culture Documents
Business Requirements For : Revision History
Business Requirements For : Revision History
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.
5 4 1
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.
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.
63991417.xls
CONFIDENTIAL 07/27/2011
2 of 16
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
INT
4.0
5.0 6.0
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
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
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
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
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.
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.
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
Functional
CONFIDENTIAL 07/27/2011
4 of 16
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.
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.
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.
Functional
5 of 16
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
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
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.
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
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
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
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
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
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
70.0
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
Requirements
Status
Deliverables
Acceptance Criteria
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
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
1 1 1 1 1 1
Accounting
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
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
101.0 Acounting
Through Statements
102.0
103.0 Delivery Method 104.0 105.0 106.0 107.0 Additional Requirements Content
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.
Functional
CONFIDENTIAL 07/27/2011
10 of 16
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.
Functional
CONFIDENTIAL 07/27/2011
11 of 16
INTEGRATION
Billing Requirements Ref# Requestor Integration Requirements Content Requirements Status Deliverables Acceptance Criteria
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.
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.
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.
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
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.
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.
63991417.xls
CONFIDENTIAL 07/27/2011
13 of 16
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.
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.
63991417.xls
CONFIDENTIAL 07/27/2011
14 of 16
EXCLUSIONS
Requestor
Exclusions
Status
Open Issue
PeopleSoft Capability
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.
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.
63991417.xls
CONFIDENTIAL 07/27/2011
15 of 16
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