Fog Creek Software
Discussion Board

e-commerce : How to build a good billing system ?

I'm working on a coldfusion e-commerce website.
The site is growing each day... and we have troubles with the billing (invoice) system : we add many patches to make reductions, tickets, free shipping, ... depending on the total of the order, the delivery country...

Example : the marketing department wants to make a special offer : "5% reduction on the order, and free shipping for europeean people if the order reach $50, during 1 week".
Another offer could have been : "if you buy 2 cd's, the third is free, the offer works once per account"

After 2 years, the system is a sort of enormous patch AROUND a billing system... not a billing system !

So i'm planning to rewrite my application to allow the creation of "offers" via a back-office, which must be usable by the marketing people and which allow a complete automation of those offers :
order, summary, follow-up (when people are waiting for delivery), statistic (how many people use the offer, $ win),...

I have really no idea of how i can make this, it seems so complicated ! I really need help, articles about this, ideas, ways to look for, ...

thanks in advance and sorry for my bad english, i understand it quite well but have troubles to write it, it's not my native language at all :-)

Oliver B
Wednesday, May 07, 2003

Cold Fusion (or at least CFML) is not a good choice for such a complex system - Allaire/Macromedia even make this point. Any attempt you make to simplify the code, will be thwarted by the simplicity of CFML (e.g. lack of scoping, messy include system).

Depending on the version of the server you are running you could leverage JRun and express your system in Java - which would be a good choice (the approach recommended by Allaire/Macromedia) but you would be slowed down by having to learn Java (assuming you don't already know Java).

Of course, since CFML is not really a good choice here you are going to have to use something else which means you are probably going to have to learn something else anyway. Java is a good choice since CFML these days now, roughly speaking, an implementation of JSP custom tags and your Cold Fusion server is also a J2EE server.

Even then you are going to have a pretty trickey job to do as you'll have to write code to express the different rules and determine their applicability and priorities.

I recently worked on something that had a set of discounting rules which could be combined with boolean operators (AND and OR) so I used the composite design pattern to combine such rules. That worked pretty well, but your requirements might not be so simple.

Because that the business rules you are working with are complex the soultion you're going to have to develop will probably need to be fairly sophisticated. You probably need to explain this to your manager(s) and hope they understand the situation you are in.

Walter Rumsby
Wednesday, May 07, 2003


If you know a handful of current technologies and a couple of popular programming languages and you can build this new billing system in two weeks.

GenX -- I was created from the subconscious minds of Ged Byrne and T. Norman

Wednesday, May 07, 2003

What Walter said

Thursday, May 08, 2003

Start with requirements.
You have to sit down with all the people that create these deals. Ask them to define every deal they can think of.

Then create the abstraction. This is the painful part, since it's pretty much a case of pinning all the deals on the wall and staring at them for a few days, looking for patterns.

You have two choices on your solution - either
a) Build an abstraction that can handle anything (technically hard)
b) Get the marketing or sales director to sign off on the idea that whatever system you design, all future deals have to fit within that framework (politically hard)

Once you have a model for your discount system, *then* I would think about technologies, since then you have a concrete question to ask. :-)


Thursday, May 08, 2003

'a sort of enormous patch' -> data-driven

Thursday, May 08, 2003

Billing systems are much easier to write procedure code for... nice and straight forward.  Of course anything can be complicated to no end...

I've seen multiple oop attempts, and all I have to say is I see no value in the 80 percent or more overhead abstraction code.

Joe AA
Thursday, May 08, 2003

I disagree with the anti-OOP statement.

IF your billing rules can be expressed via a clean interface that is much more preferable than a massive CASE statement and/or deeply-nested IF-THEN-ELSE clauses. As long as your abstraction is correct then your code will be more maintainable and more extensible.

I think the problem is the OOP is not as simple as advertised - i.e. the idea that "everything in the real world is an object so all we have to do is codify those objects" is an oversimplification. It takes time and understanding to do it succesfully and I think most people don't have that understanding (I don't think I have that understanding, but I think I have the understanding that I don't have the understanding :) ).

Walter Rumsby
Thursday, May 08, 2003


Maybe I just shot myself in the foot.

My intended point is a well-done OO solution would be preferable, but understanding OO properly takes work.


Walter Rumsby
Thursday, May 08, 2003

thanks for your answers...

what is an "OO" ? i dont understand...

i think i would have no other choice than coldfusion, because i work with another "developper" which should be able to maintain the system if there are troubles and i'm not here... and coldfusion is the only thing he knows... (he's a graphist 80% / developper 20% :-(
The site is quite big today (sort of small and i don't know if mixing coldfusion and other language on the site is a good idea... we're CF 5.0 today, but we will use MX in a few time.

You talk of if-then-else and case... I'm not sure how i can make without that !?! I missed something ?

The ideas i have :
1/ itemize all fields that can change :
- who is concerned by the offer : everybody, european people, people who already bouth something, ...
- what is the offer : hardest part imho. i need to repertory all kind of offers we can make.
- how is applied the offer : evrybody surfing on the website, only people entering a special code

2/ make an interface that insert information in tables.
I think a sort of interface we found in firewall like "winroute"... you create rules, and you can use an up or down button to order the rules (the on on the top is the first applied)... and for each rules I have 3 windows to add parameters...

example of the tables :
offer #1 | people who bouth product ref 1234 |
offer #1 | people with $50 in cart |

TABLE what
offer #1 | free gift |
offer #1 | 5% reduction |

offer #1 | special code : 123456|

and maybe a table with "Client ID's" and "offer #" (a line per id) for offers that client can only use once. the program will remove the line if the client use the offer... so he can't reuse it. no ?

3/ find a way to use these information to apply reductions, one by one, and the make a good bill (2 tables, Orders and Orders_details, from where i can easily produce summary, statistics, without having to recalculate the offers.

Do you agree with this statement : "A bill is a static state" ?
what information should it contain ? i think :
- products (ref and title), quantity, price for one (Order_details table)
- sum, reduction (in $), shipping costs, "full" total.

Do i need to recover which reductions were applied ?

many questions... Is there any book named "the billing system" or something like that ? i need to do exactly the same thing...

Oliver B
Thursday, May 08, 2003

ummm  writing a decent billing system isn't trivial.  Apart from line discounting, you have overall discounts, multibuy discounts, special code discounts, discounts depending on the vendor, depending on the type of product, with or without carriage exceptions and exclusions, applying VAT properly per line on the discounted value and not adding it all up and working it out on the total....

etc, etc

Find a proper billing system that real people use rather than webby crap and interface to it in whatever way it allows, use an already existing solution.  The rest is UI, which is all the web interface is good for.

Simon Lucy
Thursday, May 08, 2003

If you're running Cold Fusion MX the graphic artist/developer guy can still produce markup using CFML, but the bulk of the server-side code can be written in Java.

Walter Rumsby
Thursday, May 08, 2003

OO means "object oriented". OO is an approach to structuring programs by writing a set of objects that interact with each other via methods (actions supported by the objects).

OO has become relatively mainstream over the past 10 years and one major reason for this is because OO systems tend to be more scalable and flexible than other systems, or to put it another way simpler (eg. procedural) approaches might be well suited to solving smaller problems, but tend to have problems when dealing with more complex, large scale problems.

For instance, you could/can express your logic as a series of deeply nested IF statements, but such an approach is difficult to read (particularly in CFML where the syntax is tag based and CFML tags can easily be confused with HTML tags), difficult to test, difficult to maintain and difficult to understand. Potentially in an object-oriented language you could express a set of complex rules in a way which is a lot more readable, a lot easier to understand, a lot easier to test and a lot easier to maintain.

If you don't know OO however I don't recommend going off and writing a Java-based billing system. Understanding OO takes time (see the two recent threads on OOP here).

If you're looking for a "how does its billing book" I don't know if you'll be in much luck. For one Amazon doesn't run on Cold Fusion (it's on Vignette with Java and/or TCL I think). The best place to look for the kind of advice you're after is probably the Macromedia developer forums, people there should have the most experience with trying to get the most out of Cold Fusion.

Walter Rumsby
Thursday, May 08, 2003

thanks, ok for OO (i know what it is [just i didn't knew the "oo" term) but in fact i never used it...

i will read some things about it... and check the macromedia forum, yes it's a great idea :)

Oliver B
Friday, May 09, 2003

just have to add this quote:

There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?''

"An operating system,'' replied the programmer.

Friday, May 09, 2003

"ummm  writing a decent billing system isn't trivial.  Apart from line discounting, you have overall discounts, multibuy discounts, special code discounts, discounts depending on the vendor, depending on the type of product, with or without carriage exceptions and exclusions, applying VAT properly per line on the discounted value and not adding it all up and working it out on the total...."

Simon is correct... it ain't trivial.  If you believe you can make the above into an OOP design, by all means go for it, but you will find your design folding back into/onto it's objects, you will have to do kludgy workarounds, and 80 percent of your code will have to be overhead just to support the implementation.

Billing is a very procedural process - it is not a property (or method) of any single object (e.g. object... bill thyself) It must support a relationship between multiple data items and that relationship can change as you go through the procedural steps... and those data items can change as well - not only in value, but in meaning, and in number of occurrances.

Just because the process is procedural, it doesn't imply that you have to litter the code with a bunch of "if" or case type statements.  That is exactly the way you can overly complicate the process - by making it "exception" driven across or within multiple steps. 

Joe AA
Saturday, May 10, 2003

Walter, you are wrong re CF not being a viable language for a complex app, billing or otherwise.

Solid Business rules are needed here more than a new technology. 

CF  Is not mutually exclusive of good OO design.  For apps with a single client (a browser) CF is still a very viable solution with or without JAVA.  CF has a pretty thorough script component, if you dislike tags. 

This:  >>"difficult to test, difficult to maintain and difficult to understand" is comical. 

Christopher Hester
Monday, May 12, 2003


it's really dificult for me.

I wrote the different discounts we currently use and the ones we plan to use... it's so big...

For example we make "packs" : a products (on reference) which in facts contains to products)... when you buy this pack (one article in your cart) another reduction can't be applied to the product.

So if you have a code for "5% discount"... and only this pack in cart, you have no discount...


Oliver B
Thursday, May 22, 2003

*  Recent Topics

*  Fog Creek Home