Writing a Billing System

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

The hardest part of this question is for me to figure out how to state it. Please bear with me! :)

Project: Recurring and non-recurring billing with various discount structures.

Here I need a system that will bill for various services, many of which are delivered on a monthly basis. The goal is to write the system in such a way so that customers who are on a certain 'plan' which gives them definable discounts and freebies, can all have the discounts applied to their accounts automatically reflect changes in the master 'plan'.

What I have trouble envisioning is the actual structure of how discount plans are recorded. Customers may be on more than one plan, so a need for precedence sorting also exists.

I imagine I will have a table in which I will store all possible 'products', and then sign up customers to be billed for one-time or recurring sets of these products. Two things may happen here: A) a discount 'plan' is applied which affects the pricing of the products the customer is purchasing. B) another 'plan' is added which gives a customer a certain group of products at a certain grouped price, in this case, if the customer already has these products in their purchase list, the 'regular priced' items are supposed to be overridden by the (identical) promo items, BUT if the promo is removed, the original set of products must be re-established.

SO... I am not asking any of you to write this system for me :) I've got most of it under control.

What I am looking for is advice on how to allow non-programmers to enter and maintain sets of promo rules, that may be applied to certain clients or products. Of course, I would like to establish this system in the most general and efficient way possible.

I have thought of having a Rules table that will look like this:

Rule Name | Field Name | Condition | Action
----------+------------+-----------+-------
blah      | item       | is "abc"  | item_price = regular_price * 0.85
[download]

However, here the Action column is essientially code, which I want to avoid. It is preferable that the person entering this would not have to be a programmer.

Any ideas or suggestions for this? Ever done something similar? All information greatly appreciated!

Andy

Comment on Writing a Billing System Download Code

Replies are listed 'Best First'.
Re: Writing a by ignatz (Vicar) on Jul 22, 2002 at 02:43 UTC
Andy, I'm afraid that it's hard to see the Perl in this question. The thing that springs to mind from your problem of allowing non-programmers to specify rules is a spread-sheet application. They allow users to specify equations with a simple grammer. Isn't that basically what you are talking about? Whenever possible I try to get any application that I write to mirror things that users are familiar with, so I would make my "rule" thingy act like a spreadsheet as much as possible. I would even say that this sounds like the type of problem best suited for a spreadsheet application, not that I'm mentioning any specific ones... COUGH COUGH EXCEL COUGH Excuse me. ()-() \"/ `	[reply]
Re: Writing a Billing System by tjh (Curate) on Jul 22, 2002 at 14:56 UTC
Experimentally, take a look at the Rules Wizard in MS Outlook for an example of a UI for rule creation without equations or much other thinking required by the rule-creator. :) Not that I think their rules wizard is extra brilliant or flexible enough, but it is an effective approach, and a good idea-sparker when thinking about rules-based systems. Possibly another rule-builder that may show greater dynamic flexibility would be MS Access' query builder. (Egads, lots of MS examples here.) If you can be sure that only approved persons, with reasonably viable computer skills, will be creating rules (or macros, or other rule equations), now and in the future, then a hand-entered equation system can be considered. Frankly, I think it's risky to assume the skillset of future rule creators. It's probably a valid argument that the % of the user population of MS Word or Excel that actually creates and uses macros or even slightly complex equations is amazingly small, for a reason. You may consider having a new rule stored with a unique ID or rulename, have a second person approve the rule before enacting it, database these approvals, have a rule for every pricing issue including regular retail, have a way for the creator to test the equation and approve the results, and, never allow the rule to be deleted or otherwise exorsized. Never alter an older in-use rule -create a new rule instead. The audit trail of what rule was active for any account at any time, etc., will someday be a critical function. Also, if the rule creates code that gets run (eval'd, etc.) each time the account is looked at (not recommended, store the altered numbers, reference the rule that created the numbers), the deletion of it will forever effect the numbers so it must always be stored. Designing systems like this can spin wildly out of control when you consider all the variables you'd like to see implemented, or those that you think your users will ask for in the near future. Think simple, but reasonably flexible. Just some thoughts...	[reply]
Re: Writing a Billing System by greywolf (Priest) on Jul 22, 2002 at 18:24 UTC
I'm actually in the middle of doing something fairly similiar to this so I know what you're going through. I can think of 2 possibile solutions off the top of my head. A) If the action will always be a discount percentage you can just store the discount (15%). This will also help maintenance when the price goes up in 6 months. B) If there are multiple types of actions you can store 2 fields. 1) reference to type of action (percentage, promo price etc) and 2) value of the action (15%, $9.99 etc). The user would then select a type and a value and be on their merry way. mr greywolf	[reply]
Re: Writing a Billing System by Anonymous Monk on Jul 24, 2002 at 01:56 UTC
Hi all, thanks for the insights. What I'm leaning towards at this point is to have a tabular entry form with different simple actions that can be performed on different fields. The individual actions would be grouped to make a rule. (The rules I need to create bundle specific groups of items together, each at various discounts or set prices) So, when the user chooses to enter a new rule, I start adding rows to my rules table with the same group_id value. The user would provide values for field, comparison/action, and value. The action could be a comparison to establish whether the rule may be applied, and an assignment, to set different fields to a certain value. I guess my question was more about how to best achieve the above syntactically, or if I should use a slightly different entry structure. I'm assuming that the people entering the rules are fairly smart (dangerous, I know) and also have a strong knowledge of the conditions they want their rules to work under. Further feedback on this would be, of course, very welcome. Thanks all you Monks, Andy	[reply]


Welcome to the Monastery
	PerlMonks