[freeside-devel] Contracts, Deferred Revenue, and partial con tract refunds

Bowen, Peter pbowen at aboutws.com
Wed Jan 21 14:40:05 PST 2004


	I think I'm beginning to understand how this works.  It looks like
this is what I need to do.

	part_pkg -> Add fields:
		o Cancellation (Cancelled the contract early) - Add a field
for calculation
		o Transfer Setup (Changed service within the system) - Add a
field for calculation
		o Transfer Cancel (Transferred to a less/more expensive
contract)- Add a field for calculation
		o Deferred Revenue  - Add a field for calculation
	cust_pkg -> Add methods to calculate:
		o Value (The same calculation as for creating the invoices)
		o Remaining - Based on calculation in part_pkg
		o Used - value - remaining;
	cust_main -> Modify 
		Bill
		o Iterate through cancelled accounts and... 
			Apply cancellation calculation resulting (maybe) in
a credit.
		o Iterate through down/upgraded accounts and...
			Apply the transfer cancel for old package (probably
a credit)
			Apply the transfer setup for the new package
(probably smaller than setup)
		o Iterate through billable accounts and do the same thing as
now (current case)
		Deferred
		o Add method to roll up the deferred from cust_pkg.
	
	UI - Add the fields as well as pre-populating based on common
entries


	It's never this easy - what am I missing?

-Peter



-----Original Message-----
From: Bowen, Peter 
Sent: Tuesday, January 20, 2004 6:13 PM
To: 'ivan-freeside-devel at sisd.com'
Subject: RE: [freeside-devel] Contracts, Deferred Revenue, and partial
con tract refunds


Ivan,
	That's fine.  I expect to be doing a good portion of this myself.
I'll dig into the code and let you know what I find :)

-Peter


-----Original Message-----
From: ivan [mailto:ivan at 420.am]
Sent: Tuesday, January 20, 2004 4:11 PM
To: ivan-freeside-devel at sisd.com
Subject: Re: [freeside-devel] Contracts, Deferred Revenue, and partial
contract refunds


This is different than what I need to do at the moment, which is just to
report on quarterly/semi-annual/annual revenue received in advance. 
There probably isn't much duplication with what you're looking to do.

I think the "beef up packages" route for your changes is preferable to
the "add a contract level that contains packages".

-- 
_ivan


On Tue, Jan 20, 2004 at 12:26:21PM -0500, Bowen, Peter wrote:
> I'm lumping these three items together, because I think that they're
> related.  If not - let's discuss...
> 
> 	Contracts: 
> 		- Contract revenue should be tracked with three values:
> 			o Total Value
> 			o Recognized/Used Value
> 			o Deferred/Unrecognized Value
> 		- Setup fees need to be able to be prorated across x months
> 		- Cancellation fees must be tracked and applied upon early
> cancellation
> 		- Remaining Balances should be credited and applied for
> upgrades.
> 		- We may need some concept of contract level
> 			--which downgrades incur a cancellation fee
> 		- We can add a contract level that contains packages, or
> 		- We can beef up packages to be contracts (Since they pretty
> much are)
> 
> 	Basic Functionality:
> 		- Contract Inception:
> 			o Contract total value calculated based on the
> length of the contract
> 				-- Prorating, free months, etc could affect
> this
> 			o Apply the first month's usage to recognized and
> against deferred.
> 		- Daily
> 			o Apply revenue based on billing cycle against
> deferred
> 
> 		- Contract Upgrade/Downgrade
> 			o Adjust recognized and deferred based on actual
> used
> 			o Apply Cancellation fee(s) (if applicable)
> 				-- Apply to revenue against deferred
> 			o Create new contract (Contract Inception)
> 
> 		- Contract Cancellation
> 			o Adjust recognized and deferred based on policy
> (actual vs. end of period)
> 			o Apply cancellation fee(s) to revenue against
> deferred
> 			o Refund remaining deferred as credit
> 				
> 	Note that some of these could apply to monthly contracts as well -
> if the user upgrades to an annual contract, mid cycle, s/he should get
> credit toward the new contract.
> 
> 
> 	I know that this is a big bite to chew, but let's discuss since this
> is what I have to implement.  I'm going to use either in a home grown
biller
> or by contributing to Freeside. :)
> 
> -Peter

-- 
_ivan



More information about the freeside-devel mailing list