So today I finally had the time to sit down with racc and work on a
natural language for defining recurring billing cycles. The racc part
was actually pretty easy once I got a handle on how yacc works, but
it’s the wording and syntax I’m struggling with a bit.
I’m trying to include most of the different billing scenario’s that
I’ve seen used out there. The basic flow is that you have different
stages of a billing cycle. The first stage is what to do when a
customer first signs up. You can charge them immediately, charge them
in a number of days, or give them a free trial. Subsequent stages
define a billing cycle over a period of time. You can create several
stages where you can for example bill someone every month for 3
months, then bill them every 6 months for 3 years, etc…
What I’m having problems with is finding a way to use a similar syntax
to describe two different scenarios.
First we have the first stage which is something like this:
charge X amount now|charge X amount in 5 days|charge nothing now
Then we have subsequent stages:
THEN charge X amount every X day[s] for X times|until cancelled
So far so good. But here is another scenario that uses a different
syntax and could span the first two stages depending on how you look
at it.
charge $40 on the 1st of every month 12 times|until cancelled
In this scenario the first payment is usually prorated to whatever day
the billing cycle starts on. This example actually assumes a prorated
amount. I could also write it something like this, which would fit in
a bit better with the rest of the language syntax:
charge prorated amount now then charge $40 on the 1st of every month 12
times
I don’t really like this last one, but it fits in better as far as how
stages are defined, where the first stage is always present and
defines how the first payment is handled.
Chris
On Jul 19, 2007, at 10:44 PM, snacktime wrote:
define a billing cycle over a period of time. You can create several
stages where you can for example bill someone every month for 3
months, then bill them every 6 months for 3 years, etc…
What I’m having problems with is finding a way to use a similar syntax
to describe two different scenarios.
First we have the first stage which is something like this:
charge X amount now|charge X amount in 5 days|charge nothing now
seen this
http://runt.rubyforge.org/
??
a @ http://drawohara.com/
On 7/20/07, snacktime [email protected] wrote:
define a billing cycle over a period of time. You can create several
stages where you can for example bill someone every month for 3
months, then bill them every 6 months for 3 years, etc…
What I’m having problems with is finding a way to use a similar syntax
to describe two different scenarios.
8<
Hi Chris,
Sorry not to be helpful at all with the “racc” issue.
Your current challenge has a business rule / process taste. You could
have different rulesets or processes for each business case.
There are some of those tools written in Ruby.
Or you could take inspiration in Rake which defines compilation rules,
and taking a similar approach, define an engine for interpreting
billing rules defined in Ruby (directly).
Let the Ruby interpreter do the grunt work and focus on providing an
abstraction level, in Ruby, for your billing issues.
—8<—
Snacktime::BillingTask.new do |t|
t.charge = {
:now => “$40”,
:after_one_month => :the_rest
}
end
—>8—
Best regards,
Thanks guys. I had seen runt but not the recurring library on
rubyforge, which looks closer to what I’m looking for to do the actual
date calculations. Right now the main challenge is just making the
language easy to use for a laymen.
The best way I’ve found so far to handle billing is at every interval
you calculate the next interval and just store that in the database.
This is for credit card billing so the exact dates can and do change a
lot even though the interval stays the same. Cards get declined and
then reactivated again a few days later, people cancel, change billing
cycles, etc…
Chris
On 7/20/07, John M. [email protected] wrote:
On 7/20/07, snacktime [email protected] wrote:
So today I finally had the time to sit down with racc and work on a
natural language for defining recurring billing cycles.
and taking a similar approach, define an engine for interpreting
billing rules defined in Ruby (directly).
Let the Ruby interpreter do the grunt work and focus on providing an
abstraction level, in Ruby, for your billing issues.
has some good stuff on doing just this.
–
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/