I developed e-Bills as a result of doing some Project Management work within a major Telecommunications company. The project I was working on needed to add some billing codes to a well-known (with Telcos) and proprietary billing system. The cost and complexity was huge and I couldn't understand why. I developed e-Bills to prove to myself that I could develop a application and to understand billing issues.
I still maintain that there's a great deal of business productivity software out there that is actually a business-detriment! e-Bills is an attempt to produce something simple and effective. In fact one of the design principals was that it should require little training and be resilient for call centre type environments as well as others around the business.
I started development in November 2000 by looking in depth at some of the technologies that made sense in this application. I was already using PHP (for Intranet sites) and MySQL. I spent some time looking into different text processing engines that could run under Linux and in the end decided to do the first release using LaTeX. Development continued in 'spurts' between January and June 2000. From the July I found myself with more time on my hands and spent the next 4 months in intense development, testing, launch, feedback and everything else that goes hand-in-hand with getting an application to market.
Since its early releases there have been several improvements to performance and functionality. One such area is the "Billing Engine", which was developed to support a high volume of bills in many different billing scenarios. e-Bills can now export customer, product and bill data.
We now have an excellent road map of where the product is going based upon email feedback from distant users as well as more local businesses. New planned features include: support for metered billing, conglomerate bills, customer notes and a collections tool
Other extensions will include sending bills by email and fax, which is now partly supported, new bill templates (e.g. for Utilities companies) and bill messages.
We will shortly be including a language file, for ease of translation, and will look for volunteers to translate.
Overall this application is very 'live' and I hope to keep it so over the years. There are also other applications that are on my development list.
Personally I've learnt a great deal from the Linux and the open-source communities. Without the free publishing of source code I would not have been able to develop my technical skills (development or understanding of the IP world) in the way that I have.
The web-side aspect of e-Bills seemed appropriate to publish in this way. Originally I considered selling the application with a per-server price. I doubt I would have made many sales. The web-side PHP code provides all the user interface, manage data and provides the basic capability to produce bills. It is very usable for any business that produces a few bills per month and does so manually.
The PHP version only supports bills with one-off and monthly charges. This wasn't a deliberate restriction. It's just that the effort to do the job properly in PHP looked like loads of effort. For me it was easier to have a single piece of code (the Billing Engine) to do this.
If there's any opportunity for revenue for me from support, customer-specific enhancements and installation then fantastic!
The Billing Engine is written in C and runs as a background job, activated by cron and also by the PHP. It runs through the entire database and sees which bills need producing them and does so. It can also spool bills directly to a printer. It is more relevant to larger businesses - i.e. those that need a real billing run of many bills per night. The Billing Engine offers some real productivity value and is worth paying for.
The web-side application also detects if the Billing Engine is there. If it is it makes use of it.
As I mentioned above the Billing Engine also copes with different billing scenarios. It was easier for 'change control' reasons to have one location for the detailed billing stuff. The Billing Engine will cope with UNIT, WEEKLY, MONTHLY and ANNUAL charges in bills issued monthly, quarterly or annually.
Metered billing will be supported shortly
Some limited work has been done regarding integration, but basically an application is set up to run through RADIUS or other (say syslog) logs or to import from CDR's (Customer Data Records). The results are matched against configured product codes in the database and then stored directly into the products_sold database against the relevant customer contract.
The rest of e-Bills does the rest.
The basic infrastructure and database design will cope with many different billing scenarios and other application add-ons.
I've only tested e-Bills under Linux configured with the Apache web server with PHP configured to run as a module. This allows which allows files with .php extensions to be processed by PHP. These generate the html which creates the user screens on your browser. The database is written to use MySQL.
In order to produce PDF files your system must have LaTeX loaded too.
At the moment the answer is yes. A later release may use troff (or anything else that is suggested) - but this would mean learning how to create a billing template in something other than tex! There are only so many hours in the day.
Again the answer is yes for the moment, but I'm presently doing some work to optionally allow the use of other databases.
This is limited by the database being used. I admit I've not yet done any real volume benchmarks here (beyond around 300 customers and respective contracts). From what I read about MySQL and PostgreSQL there's no reason why databases in excess of 10,000 customers/contracts cannot be used.
On the rather slow Pentium II server here it will produce 1,000 bills (as PDF files) in one hour. It will take around 3 hours to print them on a reasonable laser printer.
e-Bills allows different classes of user to use the system, each having specific privileges. The user types map onto job title names such as:
User names are assigned privileges when the account is created. When a user logs in they are presented (and only have access to) functionality appropriate to their user class.
All of the e-Bills files contain additional protection such that they will exit if a user enters the filename directly into their browser. In future this will add a line to syslog too!
When a user logs in e-Bills also opens a new window without the buttons, menu and navigation bar. This results in users not seeing filenames, but also provides a bigger display area.
e-Bills has been designed to work with any W3C compliant browser. It has been fully tested with Internet Explorer 5 and Netscape Navigator 6. We have also run some initial tests with Opera.
The charge logic is most advanced in the billing engine, as this is the target supported mechanism for generating invoices. However the charge logic in the web server alone (print_the_bill.php) will get you by as it supports one off charges at any billing frequency and monthly charges on monthly bills.
The billing engine is written in C and runs as a binary. In the future it will support even more complex billing scenarios, such as multiple contracts per bill (conglomerate billing) and metered billing (with summaries and sub sections).
There are two things to consider when looking at the charge logic:
The following table shows how these are supported by the billing engine:
|Milestone||Next bill only||Next bill only||Next bill only||Charged 1st bill then annually|
|Monthly||Next bill only||Charge x 52 / 12||Charge||Charged 1st bill then annually|
|Quarterly||Next bill only||Charge x 52 / 4||Charge x 3||Charged 1st bill then annually|
|Bi-annual||Next bill only||Charge x 52 / 2||Charge x 6||Charged 1st bill then annually|
|Ten Times||Next bill only||Charge x 52 / 10||Charge||Charged 1st bill then annually|
|Annually||Next bill only||Charge x 52||Charge x 12||Charged 1st bill then annually|
Those shown in italics are not the ideal scenario, but milestone bills are not really supposed to support repeat charges.
There are times when customers need to bill things other than an integer number of items. This could be a daily rate, a percentage utilisation of a service or space, or some fractional use of a service or space.
The following are the types of quantity defined and how they are used:
|Type of unit||Purpose||Whether supported|
|QTY||Integer number of items||Yes|
|TIME||Fractional portion of days or hours. Allows a product code to be defined with a standard daily or hourly rate and then to charge a fraction of that (e.g. 1.5 hours or 2.5 days)||Yes|
|PERCENT||Fractional units||Yes, but will be improved to understand percentage usage in future|
Please see the section on problem solving.