provided by Star2Billing S.L.

I found this on http://www.asterisk2billing.org/cgi-bin/trac.cgi


Is a2billing really a full featured telecom application?
The answer is YES or in my opinion very close to it. A2billing has made leaps and bounds in the last year or so and has a lot to offer. I am very impressed at some of the last changes and addons.

However there are 6 questions I have.

1. Why does a full featured telecom application like a2billing not offer a way to find-look up or filter by customers accounts using their very own Telephone number or address
2. Why are there only one address field and no billing address fields ( the name is Asterisk2billing or a2billing right?)
3. How useful can an auto refill feature be when it only adds a refill amount that = same value from the very same initialbalance field that only allows the refill to run when the customers bal value = a little as a penny less than the initialbalance field and than logs the refill in such in a way its not very easy to find the client’s account that just got refilled?
4. Is it even possible to use the Auto-refill cron script conveniently and safely in ways to reduce company labor cost or make it more convenient for clients?
5. Why design a full featured telecom billing program and add various online merchant processing gateways and then implement an Auto reoccurring +$$$ refill feature without first adding a reoccurring auto payment method to collect $$$ from clients? (Maybe Areski is being sly by sending A2billing users a hint! Support A2billing more if you don’t want your clients getting free refills)
6. Why on earth was time spent adding a Reseller’s feature or module (or whatever you call it) when some of the very essentials of a billing application were never implemented? (I will try to be positive and assume someone must of paid for the Reseller feature)


I don’t really expect anyone to answer those questions as they speak volumes for themselves but anyone is free to do so if they like.
I don’t believe in criticism without fallowing it up with a suggestion, so I will make 3 suggestions.


1. Ok to the hard working geniuses who are responsible for adding features to A2billing. I think the number one choice to make when adding new features to a rapidly growing application is examining many other related applications (regardless how they are priced) and pattern off of their key points. Example: to quickly be able to find a record of interest is important as it saves on labor. In this example we would look at their techniques. If most other application allows searches by address or zip code than there is probably a reason for it and even if there are not a lot of request being made for it, it doesn’t mean it’s not important. It could just be those making the requests are only making requests for something else that at the moment is more important to them and possibly thinking the new searches method will get done sooner or later. In my opinion A2billing user’s request should come second (even including my own request) until developer believe they have the fundamentals in their application completed. If one gets a lot of request on the forum and it’s also a common method used in other application, well that is a no brainer. Just go with it.
2. Ok. Now to A2billing USERS and forum readers.. The coders working on a2billing do read the forum so don’t hesitate to make a general request-comment on how a2billing can be improved even if you don’t need it. The support Team needs feedback and unbiased feedback is probably the most important Feedback you can give. Don’t wait until you need something to make a request or post feed-back. If you see something that can be improved even if you don’t need it let your fingers do the talking and post it! And when you do need something don’t be selfish in your request. In other words if you request something maybe not used or wanted by many, do your part and try and post 5 other request about other improvements you think will help a2billing be a better application. Don’t even be shy about posting spelling errors assuming you find any. Feed back is most important to a developer when it’s not biase, meaning you are posting to help and not because you need it.
3. Now my last suggestion goes out to a2billing users. If your feel or believe A2billing is worth more than what you have given back to the project than make a donation. It’s simple easy to do and doesn’t take but a minute!

Hi

You make some very valid points, and you have clearly give some thought to what has been written.

Point 1:

A2Billing has it's roots as a calling card platform, and only really in the 1.4 release have we moved it more towards a full featured telecoms platform mores suitable for business use. This feature may come in time. Faster if sponsored.

Bear in mind that it is 5 years since A2Billing was released, and there was no such thing as a PHP framework of any note in OSS, and Areski wrote the framework for A2Billing some time before, now the limitations of the framework are making themselves known which sometimes makes it difficult to do things as elegantly as we would like.

We have made some improvements, such as clickable links from where ever the account number is displayed.

Asterisk2Billing was the original name, but Digium don't like us using the "Asterisk" Name, so we are carefully moving over to the name A2Billing.

Point 2:

This is a hangover from the calling card roots that it comes from - improvements have been made to the address fields - e.g. we now include a company field. Additionally, no-one has requested or asked for this feature.

Point 3:

The auto refill feature has been in the system for years, but no-one has ever asked for , or indeed sponsored the development of auto decrement of a payment provider. Additionally, it has been difficult to take money from say paypal unless the account holder clicks something, e.g. a process cannot go and get money from a paypal account automatically, until now, with the Paypal pro options.

It should be noted that integration with other payment providers is a lengthy process, often requiring several days development work, as well much testing, and access to a sandbox account from the payment provider, which in itself is not always that easy.


Point 4:

Many people use A2Billing in different ways, and I have seen features used in ways that were never envisaged when they were created. I've used the auto refill feature for a Government organisation that wanted to place limits on the it's employees weekly phone usage.

Point 5.

You may find that Auto refill arrived first, or at least at a similar time as online payment methods, or possibly a customer paid for the development, but did not need payment processing. The reasons may have been lost in the mists of time.

Point 6:

We have had request after request for Agent / Reseller features. We thought of a way of doing within the existing framework, and so came up with a partial solution to judge customer acceptance. It has been embraced and accepted, so more development time and work has been spent on it.

Suggestion 1:

What is regarded as the fundamentals of A2Billing will vary depending on who you ask, and the purpose to which A2Billing is being put. My opinion is that the fundamental purpose of A2Billing is to rate calls accurately, and charge the customer accurately.

Suggestion 2:

The feedback and bug reports are absolutely required, this is the reason you have seen more releases in the last 6 months, than the whole 1.3.4 series, because we have had feedback and bug reports. Feedback, documenting processes, helping others on the forum is the best way you can contribute, and A2Billing becomes better because of it.


Suggestion 3:

Donations are nice, and are appreciated, but frankly, I'd prefer that you spend the same money on Star2Billing for support or help, or sponsoring a new feature or improving an old one. Writing up your success story can encourage people to adopt A2Billing, who may become paying customers of Star2Billing, while helping others on the forum can relieve some of the pressure on everyone else to answer questions, and documentation is helpful as well. So my point is, that although donations are excellent to see, I think everyone gets more out of it with other methods of donation.


In Conclusion:

A2Billing grows and improves by a combination on what we decide is the most pressing of issues, coupled with sponsorship for particular features, as well as bug fixes reported by users.

Also bear in mind that whatever is included in A2Billing has to be designed in such a way that previous versions can be upgraded without loss of data. This does place some restrictions on us.

Features in A2Billing arrive because they have been sponsored, which may mean that they are peculiar to that person's requirements, although we try and make them as generic as is possible within the confines of the original customer's specification. The vast majority of these features make it into A2Billing, and I can only think of a couple features in the last 3 years that have not been included in A2Billing, mainly because they were so customised for the customer and did not really fit into the general release. Other features are put in because they may be deemed useful, but not necessarily fully completed in every respect. This is to see if there is a demand for the feature, and await suggestions for improvement - e.g. what does the customer want.

We are currently planning and investigating A2Billing version 2 which should address many of these issues. But don't expect to see anything workable for a long time yet.



Joe Roper
Commercial Director

Hi Joe,
Thanks for your reply.

I been using A2b for a few years now and yes you are right some features in a2b are there because they were sponsored.

My post was meant to be a little controversial and I was trying put in words some reasonable thoughts that some people new to a2billing might have, who could be looking for a telecom solution. Those are just a few things that can really stand out and deter some potential new clients. When the statement “full featured telecom platform” is used and client’s accounts can’t be searched by their phone number it makes eyebrows go up.

The auto refill cron is another example. When it runs it doesn’t log anything in the fields “FIELDS description and refill_type” in the cc_logrefill so there is really no way to even find which client is refilled so they can be billed later like running their credit card on file. If I am not badly mistaken running an auto refill to prevent services from being disrupted is one of the most common reason auto refill is used. Putting some details in fields “description and refill_type” would have taken less than 2 minutes to do when the script was made and still probably a 5 minute job.

A combination of too many small things can and often do really raise eyebrows of many businesses owners or anyone who has experience with other common billing software. Especially to someone that doesn’t know history of a2billing. Without knowing the history of a2billing I think a2b would rightfully scare some business owners from trying it.
A2billing as you say been around for 5 years and is really turning out to be an awesome application. With this in mind I would really hate to see some trivia details hinder its development in anyways such as deterring a possibly good paying client.


You are absolutely right however each feature that is added also has fundamentals which come with it.
Example: Its generally customary for coders to add second set of first name, last name, Business name and address fields when the software contain certains specific features or design for specific uses such as.

1. Sales of products or services to businesses
2. Governmental sales
3. Integration of merchant payment gateway

Any ones of the above would require those extra fields automatically and it is standard with almost all billing software that offer any of the 3 mention above. And there are some really good reasons for it. Those extra fields as you say are not directly the fundamentals of a2billing but they the fundamental of most billing application that does any of the 3 mentioned above. I think A2billing already does or is quite suited for all three and I pretty sure Areski and the other developers are reasonably proud of it.

Now that a2billing as came this far it might be a good idea to teak it here and there a little to meet some standards generally found or required in billing solutions. Some employees are paid quite well so labor can be very expensive. the auto refill feature working right and an auto reoccurring payment not only can save companies $$$$ in valuable time it can also significantly increase the quality of service a client gets

If any of the developers of a2b already have a list of features they know are common in telecom solutions but not yet implemented in a2b and can be implemented, it might not be too bad of an idea to do a poll on the forum to see what a2b users would like to see first. I am sure the search by phone number would get a few hits.