Billing/LCR for FusionPBX 1.1.0 Released

Last two weeks I  have been working hard trying to release a new version of the Billing/LCR for FusionPBX software. There are some exciting changes which I will talk about in this post. I encourage everyone to update to this release.

The Tax Logic has changed

Usually, the taxes are taken out from the paid amount. However, this was doing balance calculation very complex, not to mention that there is no a clear way of dealing with this with the different payment processors. The logic now is at follows: when you pay, if there is a tax configured it will be calculated and added to the quantity you want to pay. For example, if you have a 5% tax, and willing to pay 10 USD, you will be forwarded to pay 10.50 USD. This works on all payments plugins now.

Payment Plugins are now included in the Main Download Package

Talking about payment plugins, in 1.0.x release if you want the credit card or off-line payments you would need to acquire the plugins separately. Since release 1.1.0 they are included in the main tarball. This call was taken in order to stimulate the funding I am doing to convert this software into open source.

Better Compatibility with FusionPBX 4.2

There were many internal changes from FusionPBX 4.0 to 4.2. The software has been polished to use all the new elements as much as possible. Many SQL queries were updated as well.

Better Caching

The software has now better caching when looking for data. When you need to convert currencies, it will save in cache the data to avoid unnecessary network traffic. The caching is used in the CDR analysis as well.

Pseudo-ENUM Support

Maybe this is one of the coolest addition. When there is an outgoing call, the CDR is being analyzed to know if the target number is being local. If the number is found, it will forward directly to the public context to be routed properly. FusionPBX has already something similar with the is_local dial plan, however, the logic is very different. FusionPBX only verifies if a destination object matches. There are some advantages of the CDR approach:

• Destinations may be missed if you use a dial plan with regular expressions. When creating a destination, you might use local dialing and your carrier sends the number in e164 format. This produces a mismatch that won't make you save money.
• If a number is ported out without notification, and destination object still exists it will be routed wrongly. Usually, this happens in big environments where you are hosting many DID's. It is well-known users port-out their telephone numbers without notification when this happens the CDR analysis will know because there are no more incoming calls events, this will route the number correctly through the PSTN and not until you realize because a customer complain.

To be fair, there is only a one con I have found:

• The first hit of the number will be routed through the PSTN. The CDR analysis needs at least one recent hit to work. However, it can be worked around using the is_local dial plan.

HTTPS Support

If you are using the automatic scripts to install FusionPBX, you will find it auto-configures SSL for you. Which it leads to HTTPS. Paypal and Stripe payment plugins need to know this in order to do the proper callback.

Have a nice billing!

P.D. Don't forget to support the open source funding.