provided by Star2Billing S.L.

Hello everyone, I am wondering if any of you tried the recurring services. I have noticed that the file a2billing_batch_process.php runs as scheduled, but it never update any card.

The bug is due to an error in the SQL query. Here is the fix.

.

I cant find that file on my server or anything even close to it. I really need to use the Cront service and would be happy to pay you to help me out. I currently have someone who does a great deal of setting up my A2B and does a wonderful job at it as well as teaching me how to use the new features but he hasnt got back to me for a while in regards to how the Cront works. I have a number of customers I charge a flat rate per day for unlimited calling. I had a script wrote for this a year ago but now that I am upgrading to the latest a2b I don’t want to use my old script if I don’t have to.

the file is here...
/var/lib/asterisk/agi-bin/libs_a2b/crontjob/a2billing_batch_process.php

Yep, gue is right. And I have configured successfully the cront services. For the moment, I have only one recurring service added in a2billing for testing purpose, and every day a 12:00, it makes some changes to my card. Let me know if the patch has fixed your problem.

Thanks Asiby and Gue

I was looking in the wrong place and didn’t do a search on the Linux server. (Stupid me) I found the file and replaced it and will see if it works.

I was hoping that I could set up different recurring services on a per customer level and it doesn’t look like the Cront feature works in this way. Correct me if I am wrong. If I set up 10 recurring services, these services will not effect clients that doesn’t have RUNSERVICE on their account set to true and all 10 recurring services will effect the accounts where set to true? Is this right?

Does this mean I wont be able to run 5 recurring services for some clients and 5 completely different recurring services for other clients?


I charge different clients differently per month based off average use as well as other things retlated to them. I divide the per month charge by 30 and charge that amount per day. My lowest per month charge for unlimited long distance is $13.95 and highest is $19.00 These amounts comes to 0.465 and 0.6333 per day. Is there anything in A2b that will let me charge one calling card client 0.465 perday another 0.6333 perday? keep in mind this same client might have DIDS and other services he or she buys from me so i dont want no rigged solution that messes up other billing aspects of a2b.

Hello Sam,

Unfortunately I think that your are right. I badly need that kind of solution too, and I am going to see too it. I will develop it unless someone else did it. And hopefully, if people like it, it might find its way in A2Billing.

Basically, in a calling card, right next to the runservice checkbox, I will add a field that will allow the administrator to select any service that might be relevant to the given calling card. It's pretty straight forward, and it will save us a lot of time in the future.

Also, with can be added to the Batch Update script.

Hi Asiby
I am working on it right now. I done added 2 new tables called cc_service_group and cc_service_group_plan. This will allow multiple cron services to be grouped under one ID. This way the a servicegroup id can be added to the cc_card table on a per client or calling card account . Thus multiple cron services of choice can apply to pacific clients or card accounts of choice.

Since I don’t depend on the a2b interface I will not do anything to the a2b interface. I will leave that to someone else. What I will do is have my programmer to modify a2billing_batch_process.php and any other files to make this work. I will share this work. If you want to add this to the web interface and need these tables I will give you access to my mysql Db

Maybe Areski would like to jump in on this and give me a quote to add it. If he hurries before my programmer gets back I would be happy to pay him something for it. I just donated $104 US dollars to Areski 30 minutes ago. But this donation was with no strings attached. It was a donation to show my gratitude and appreciation for the good work he has already done with a2b. Since I am going to have to pay to get this done anyways it would be nice to have it implemented right into the a2b application. This would make easier for me to update in the feature.


I would be happy to pay $50 for starters, or even more if no one else steps forward to pitch in.

Samuel

Good stuff Sam.

I am sure that you contribution a welcomed and appreciated.

As for the 2 additional tables I was thinking about another approach. I would have just added 1 field to the cc_card table. And that field would contain data looking like : 2,3,12

Where 2, 3 and 12 will be the id of the selected recurring services.

And to match any services in a SQL statement, I will either one of the following:

SELECT ..... FROM ...... WHERE ... recurring_service_id IN (cc_card.recurringservices)

or

SELECT ..... FROM ...... WHERE ... AND FIND_IN_SET(recurring_service_id, cc_card.recurringservices)

The reason why I would have done it this way is that when you delete a card, you won't have to bother cleaning up the other related tables. And it will keep the SQL queries lighter.

I may be wrong. Let me know when the changes are done and how user friendly it is

Your way is every simple and sweet and would probably be all that is needed to roughly 95% of those needing this feature. I think for a quick solution that is the way to go. I will take a closer look at it if the way I was doing it turns out to be too costly. However it doesn’t follow the basic way Areski is using when he groups things. This is clear by looking at how the tariffs were grouped. Unless I am wrong, by just adding one field in the cc_card table using the 2,3,12 approach you might limit scaling a little and usefulness to some degree. For instance A2b works well as a billing application on top of other applications like freePBX. (Better then most people know) I will talk more about this project later. This opens up a lot more services one will need to bill for. Suppose someone wants to offer service packages similar to the local LECs and charge for various features like callwaiting, caller Id, three way calling, voice mail and the many other features instead of packaging it all in the monthly bill. Trying to do this all in one field might get cumbersome 2,3,12,4,6,7,9,15. Ect,



I don’t think I explained it right. There will be no cc_card related records in the 2 new tables so there is no cleaning up if you delete a card ID or client.
Look at how the grouping was done in the tables cc_tariffgroup and cc_tariffgroup_plan and cc_tariffplan. The same principle is applied here with cc_service, cc_service_group, cc_service_group_plan. Hypothetically one will be able to create 100 or more types of recurring services and package it in 10,000 or more different ways with each packae having a special name (of ones liking) for that group. Only the cc_service_group ID has to be added in the cc_card table. All the recurring services under that group id will apply to that Card account.

I here you Sam, and I understand your approach. Yours is more suitable specially when we try to keep an eye on possible integration with future applications.

The cleanup I was talking about is necessary in some cases like the callerid attached to the calling cards. In your case, if a card needs more than one service group, will it be possible to assign them?

Unless you are AT&T and trying to create various extravagant service package beyond the scope of the average human ability to understand for the sole purpose of ingeniously ripping off clients you probably wont need to add multiple recurring service groups to a single account.

If one service group doesn’t have all the services you want to offer just simply create another service group containing all the possible services from each of the 2 service groups you had in mind to offer the client.

For example,

- One client can be on a plan for 15$ a month (Service A)
- Then, the same client want to have one DID to receive incoming calls from another area code for 5$ a month (Service B).

In the mean time, we may have more than on plan for inbound DID. 10$ a month for unilimited incoming (Service C), and 5$ a month for a per minute based did (Service B again).

Let's say that we also have voicemail services 4$ a month (Service D)

This is just a pretty simple scenario. But as you can see, we have 7 of possible combinations here. Some customers may having just one recurring service, or any combination or 2 or 3 here. This number increase rapidly with the number of individual services.

In this case, the combinations are:

- A alone,
- B alone
- C alone
- A anb B
- A and C
- B and C
- A and B and C

I still think that my solution we be more flexible. And there was no intend to rip off clients. I wasn't even referring to hidden fees. I was talking about real visible service pricing. Usually, we do not even charge hidden fees, connection or disconnection fees, ...

Regards

Sorry, I was just joking about the AT&T thing and sort of being a smart ass.
You made mention to put one new few field in the cc_table that we can put multiple services separated by commas like 1,4,7,3,8. The method I was talking about will do exactly what you want and offers no less. The 1,4,7,3,8 will be representing by a group ID so all you need to do is added on number into the cc_card table.

Say we have these services in the A2b table cc_service
1 = $2 for 911 or so many cents perday
4 = $15 permonth or so many cents perday
7 = $4 for voicemail or so many cents perday
3 = $1 call forwarding or so many cents perday
8 = $5 ATA payment set to run 90 days or so many cents perday

I understand, and I agree with your method. It wasn't clear at first. I will wait for the final product then

My programmer as informed me this feature is now completed in coding although nothing has been added to the admin UI yet. As it turned out it was way more difficult that I originally thought it would be. There were a couple of things I totally over overlooked when I was posting on this topic before. One is there are another feature in a2b called subscription which allows for true monthly billing for services which also needed to be combined in the grouping with the cront services. And the other is when the cront service is run, it is logged so that it doesn’t get ran again until the right time. Since the cront feature was modified so multiple cront services and subscription services could be grouped together under one group ID and be applied or charged to indivisible accounts of choice instead of being applied to all accounts this created a need for a rather more complex logging scheme to keep track of not only when the services was ran but also to which card accounts it was ran on so card accounts wouldn’t be charged multiple times before the next charge is to occur.


The patch and DB changes will be posted after more testing. Hopefully this will be less then 2 weeks. Its my understanding, Areski has implied this feature will be added to a future release of a2b if found not to be buggy and doesn’t removes any functions he intended for the cront and subscription to offer. What now remains to be done is a patch for the admin UI to allow entering of data in the new tables or fields for this feature to work. I won’t be doing this since I use a different admin GUI for a2b. If anyone wants to pitch in and make patch for admin UI it would be great.