# Open source billing system, feedback on a couple of items

**URL:** <https://www.ruby-forum.com/t/open-source-billing-system-feedback-on-a-couple-of-items/110508>\
**Category:** Rails\
**Created:** [July 27, 2007, 12:09am UTC](https://www.ruby-forum.com/t/open-source-billing-system-feedback-on-a-couple-of-items/110508 "2007-07-27T00:09:41Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![snacktime](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/7feea3/32.png) [@snacktime](https://www.ruby-forum.com/u/snacktime)\
**Post date:** [July 27, 2007, 12:09am UTC](https://www.ruby-forum.com/t/open-source-billing-system-feedback-on-a-couple-of-items/110508/1 "2007-07-27T00:09:41Z")

</div>

I’m just about finished with my business natural language system for  
defining recurring billing periods, but have one major question that I  
haven’t decided on. Since I’ll be releasing this as open source very  
soon, I’d like to get some feedback.

Right now the language is very open ended. To the point where you can  
define billing periods that wouldn’t ever get used in real life.  
However since I can’t predict what people might end up actually using  
I’m hesitant to limit it.

The basic concept is you can define multiple stages in a complete  
recurring billing definition, with each stage being a billing cycle.  
The first stage has it’s own unique syntax as it also defines what and  
when the first charge is.

In this example we have a biling cycle that is fairly common:

- charge $10 now then charge $10 every month until cancelled.

Another variation on the same theme:

- charge $10 now then charge $5 every 2 weeks until cancelled

But there is also the ability to bill on a set day of the month, which  
often involves prorating the first charge:

- charge $10 now prorated then charge $10 every month on the 1st until  
cancelled

Now here comes the part that can get a bit complicated and where  
certain assumptions have to be made.

- charge $10 now then charge $5 every 2 weeks for 3 times then charge  
$10 every month on the 15th until cancelled.

The ‘then’ keyword separates stages. The potentially confusing part  
comes when we transition from one stage to another. It’s not  
difficult to do the calculations or build in some assumptions about  
whether to prorate or not when moving from stage to stage, but there  
is probably a high potential for users to get confused. Right now the  
only time proration is done is on the first stage/charge.

I also built in the next two types of billing cycles which could also  
be confusing for people if they have multiple stages and transition  
to/from them:

- charge bimonthly on the num\_suff and num\_suff
- charge every week on day\_of\_week (sunday, monday, etc…)

In any case, my opinion right now is to expose common stage  
combinations via a web interface, and let advanced users define  
whatever they want using the bnl directly.

Chris