provided by Star2Billing S.L.

currently buying cost is set in rate, in turn, associated with ratecard, and in turn with a trunk.

the problem is, for each call plan, we have to create a ratecard for each trunk.

the problem is worse when we bill a call depending on incoming trunk (collect call or local call) and callerid (different cost if collect call).

to the nature of calling card business, the buying cost is upon trunk. and btw, we should consider buying cost as summed cost of incoming leg and outgoing leg, which i start another REQUEST post.

one of benefits is when buying cost changes, we don't need to update every rate in every ratecard in every callplan.

my suggestion is like
1. for each trunk, we can set ratecard-like buying cost for prefixes.
2. add available trunk selection to ratecard
2. remove buying cost from rate. add appicable trunks for each rate.

regards

It sounds like you are onto something, but I didn't rally understood a thing

the most important thing is about buying cost.
if we have many ratecard using the same trunk, when the trunk buying cost varies, we have to make changes to all rates sharing common trunk.

any further discussion is welcome

yes, I'am agree with dream!!!!

the buycost should be inherently associated to the trunk, rather than the ratecard... If you have a ratecard defined, you can use different trunks for some prefixes, and because of the philosophy of a2billing, it's imposible to know your real cost....

best regards,

Hi there,
Is there any progress on the request in this post? This looks to be a real problem with a2billing.
It would have been a lot better if buying rates and selling rates could be separated.

regards
mazhar

Modifying v1.3/v1.4 to work this way would be a major undertaking, and would likely introduce many bugs. I'm not aware of any effort to implement this.
The rate cards already function this way in v2.00.
Don't hold your breath waiting for a release of v2.00 though.

Can someone post the code where it looks at the ratecards.

I am making the assumption ( I know that is bad) that it is done with database lookups. It would seem that we could change the lookups or add additional lookups to accomplish this.

I am going to need this modified for our business. We have a team the will do it and we will submit our changes to the a2b team for consideration into the product.

The bulk of the code should be in Class.RateEngine.php.
That sounds like a perfectly valid assumption to me.
Yeah, as I said, it's possible. It's just that such a change has wide-reaching implications that promise to make the job a real pain to complete satisfactorily.
Given your admirable intent may I suggest, if you do develop this, that you base your modifications on v1.4 (trunk) rather than v1.3, so they stand a better chance of being incorporated into the main tree.

Btw when is relaease 2.00 expected?

I can live with the current ratecard options, but would definitely upgrade to 2.0 once its released.

I think Knuth once said something about the finest software being released only when it's ready.
It's not ready yet.

We will do it on the 1.4 platform.

I am also having the reseller module made as well. This should not be that difficult either. We have an idea of adding some fields to a couple of tables and using the existing admin module and just locking each admin down to a specific set of accounts.

We will submit it all to the team for inclusion in future versions.