Billing solution for FusionPBX

[albert-g]

Hello,
I am looking for some billing solution, but my problem is that I don't clearly understood the billing logic, my idea is that there are two ways:

1. Need to have some billing server/tool (astpp or pyfreebilling as you said), and 'redirect' fusionpbx calls to this tool, and the it will bill all the calls?
2. Or for ex., export CDR from FPBX (in csv format) and then import to some tool and then it will bill for me?

Would appreciate for some points, please be condescending because I am just starting to go deeper into voip.

 

[Adrian Fretwell]

As no one else has picked this up I will respond, but I know nothing about ASTPP or PyFreeBilling.

I wrote my own billing platform in pure PHP back in 2006 when there was nothing available that would do what I wanted. The system still remains fit for purpose so I see no need to change it for something more modern.

I adopted the approach of taking .CSV file downloads extracted from CDR data. The concept is basically very simple, all one needs to know is who made the call, to what destination, on what date, and how long the call lasted. With these four pieces of information one can produce a bill.

I have to maintain a database table of destination number prefixes, that shows the destination and the call cost per minute (for weekday, evening and weekends) and any fixed charges or surcharges for the destination in addition to the cost per minute charge. My table is currently running at about 65000 records, per carrier route - yes different carriers have different charges, and I need this data to not only bill my customers but to also check that my carriers are billing me correctly. Typical destinations look like this:

0088299    AEROMOBILE
0093            AFGHANISTAN
009377       AFGHANISTAN AREEBA MOBILE
...

00263        ZIMBABWE
0026378  ZIMBABWE ECONET MOBILE
0026386  ZIMBABWE VOIP

The process gets more complicated where we have calls that we are charged for but we are not allowed to charge the customer, like calls to the emergency services. This is further complicated by the fact that we will be charged £2.90 for an emergency call if the customer address associated with the number is correct or £5.00 if the address is wrong. There are some calls that we are not even allowed to show on a customers bill, for example calls to Childline in the UK.

You can also make your billing system more complicated, by configuring it to do bundles for certain customers, like 5000 free minutes or by introducing affinity groups whereby calls to certain numbers are cheaper. I also have multiple tariffs, so customers can choose a tariff that best fits their needs, I also have "at cost" tariff for customers who would rather pay a fixed monthly charge.

I also use the billing system for non call related recurring charges, like line rental, ADSL, fibre, or lease lines etc.

If you take CDR data from multiple sources, the format will not always be the same so you will need a process to normalise that data in to a format that will load into your billing CDR database table.

The system needs to be fully automated, so it collects CDR data daily, and emails bills in a PDF format to the customer, at a frequency of their choice, eg. weekly, monthly etc. The system also needs to send you notifications, especially if something is going wrong, like it can't find a destination number, or you are selling at a loss for any given destination.

Finally, its nice to give customers a little more than just a bill. Pie charts showing call types, and a list of the most frequently called numbers/ most expensive calls etc. always go down well.

That has probably given you enough to think about for now!

Cheers, Adrian.

 

[albert-g]

As no one else has picked this up I will respond, but I know nothing about ASTPP or PyFreeBilling.

I wrote my own billing platform in pure PHP back in 2006 when there was nothing available that would do what I wanted. The system still remains fit for purpose so I see no need to change it for something more modern.

I adopted the approach of taking .CSV file downloads extracted from CDR data. The concept is basically very simple, all one needs to know is who made the call, to what destination, on what date, and how long the call lasted. With these four pieces of information one can produce a bill.

I have to maintain a database table of destination number prefixes, that shows the destination and the call cost per minute (for weekday, evening and weekends) and any fixed charges or surcharges for the destination in addition to the cost per minute charge. My table is currently running at about 65000 records, per carrier route - yes different carriers have different charges, and I need this data to not only bill my customers but to also check that my carriers are billing me correctly. Typical destinations look like this:

0088299    AEROMOBILE
0093            AFGHANISTAN
009377       AFGHANISTAN AREEBA MOBILE
...

00263        ZIMBABWE
0026378  ZIMBABWE ECONET MOBILE
0026386  ZIMBABWE VOIP

The process gets more complicated where we have calls that we are charged for but we are not allowed to charge the customer, like calls to the emergency services. This is further complicated by the fact that we will be charged £2.90 for an emergency call if the customer address associated with the number is correct or £5.00 if the address is wrong. There are some calls that we are not even allowed to show on a customers bill, for example calls to Childline in the UK.

You can also make your billing system more complicated, by configuring it to do bundles for certain customers, like 5000 free minutes or by introducing affinity groups whereby calls to certain numbers are cheaper. I also have multiple tariffs, so customers can choose a tariff that best fits their needs, I also have "at cost" tariff for customers who would rather pay a fixed monthly charge.

I also use the billing system for non call related recurring charges, like line rental, ADSL, fibre, or lease lines etc.

If you take CDR data from multiple sources, the format will not always be the same so you will need a process to normalise that data in to a format that will load into your billing CDR database table.

The system needs to be fully automated, so it collects CDR data daily, and emails bills in a PDF format to the customer, at a frequency of their choice, eg. weekly, monthly etc. The system also needs to send you notifications, especially if something is going wrong, like it can't find a destination number, or you are selling at a loss for any given destination.

Finally, its nice to give customers a little more than just a bill. Pie charts showing call types, and a list of the most frequently called numbers/ most expensive calls etc. always go down well.

That has probably given you enough to think about for now!

Cheers, Adrian.

Thanks Adrian, your answer cleared for me, (and I am sure for other interested in VOIP beginners) many things, which I suspected but did not know for sure. Now I understood one way how to bill customers, and surely it is probably the best way to use your own billing method and platform. But it's easier to understand that it requires many resources to have complete system (I admire the work you have done).

But other way like some integrated system tools that I noted earlier (not only, it can bee not opensource) is interesting too.
Please who knows share your experience with working logic with this systems.

 

[elkato]

Hi albert-g,

As you, I was in the same road time before.
As you most probably you already saw different external billing solutions (astpp, pybilling, cgrates, Irontec's IVOZ and other), there are other approach on doing it on the same fusionpbx/FS box.
I ended using a module for fusion that basically use LCR and nibblebill from own fusion/FS, that handles and control calls on the same fusion by checking bills. So can work (more or less) doing prepaid and postpaid billing. Basically each call is being checked realtime to know best route and price (LCR) and to bill the call after it (or meanwhile if prepaid based on what nibblebill can do).
I don't think is very scalable for many servers, but worked for me for a standalone or primary/secondary failover server.

I think for many servers an external solution (forwarding calls, or "asking" the billing platform like cgrates does) would be better.

But as Adrian said, different countries and business needs/obligations, requires different logic for billing. So sadly don't think any out of the box solution will fit perfect for you, except of course you just need to do simple billing rules and does it, or able to modifiy logic.

 

[comdif]

Hi all,
I just start to write a billing for my fusionpbx parsing the v_xml_cdr table datas > add rate datas frome a rate table and finaly pushing in a new table
by this way I can use my old billing scripts it's not something difficult to do for a postpaid billing.
I use this query to extract SELECT * FROM v_xml_cdr WHERE domain_name = '".$domain."' AND destination_number != '' AND billsec > 0 AND direction = 'outbound' AND caller_destination = destination_number
seem to make the job.

 

[albert-g]

Thanks for your replies. I assumed that the best way for me is the way like described Adrian, and comdif.
All steps is really clear, the one thing, is to have some base rates list, can someone share/advise me how to get such list with country codes?

 

[comdif]

Thanks for your replies. I assumed that the best way for me is the way like described Adrian, and comdif.
All steps is really clear, the one thing, is to have some base rates list, can someone share/advise me how to get such list with country codes?

You can get one here https://www.commpeak.com/wp-content/uploads/2020/11/CommPeak_20201102_Premium_021002.xls
for example or on any other Carrier, then format it to import in your new v_routing table.
My side my need is simple, just postpay company account unlimited for some destinations or paying for minutes
The second one is very easy to write
The first one need more dev and tables