Hi.

Could you explain about the Code changes in your API. It seems that the file for the future code updates is always empty.

My problem right now is that when you change a destination code I have no way of detecting this change and update my local tables. So I need some sort of record when a destination code is removed or changed to know which is the new code that should be used instead.

something like: code: 3040 removed and code 3041 should be used instead.

Thanks in advance.






>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


Hi

Codes don't change very often so it is normal for this report to be empty. If you check it regularly, there will be something in it it when codes change. Alternatively, you can simply diff the CSV rate files we put out.

Kind regards
Simon

October 01, 2014 12:29
User photo Vip-Consult
Vip Consult Limited
Yes I can find out which codes have been removed easily , but no way to automatically find out which are the codes I need to replace the missing ones with.

Like on my last example :

lets say the code 3040 have been removed from your tables , how would I find out which is the new code I need to use instead ?

This is crucial for an accurate call cost calculation.

When I pull the calling rates from the API I set a default profit margin for most customers , but some need to have custom rates for some destinations.

So on the next rates update If a destination ID has been removed I need to know which is the new destination ID I have to use so that I can update the custom rates accurately.

October 01, 2014 12:52
User photo Simon Woodhead
Simwood eSMS Limited
I don't see how such a mapping would ever be workable. Codes are linked to breakouts; the codes change. You should always be using the longest match to see which code matches a country, there is never a straight forward in/out as it is way too complicated to do so. your rating/billing should work at the breakout level and the codes linked to it are what they are. If you price at the prefix level you're setting yourself an impossible task.

Simon

October 01, 2014 12:58
User photo Vip-Consult
Vip Consult Limited
Our business logic Is to have a default profit margin of lets say 80% , but sometimes to keep a customer happy we would have to offer lower rates for some destinations so for example for destination UK T-Mobile they will be at 50% profit margin.

so here is a simplified example

rates_table
dest_id prefix cost default_charge
3010    3592   0.01 0.02
3011    447    0.02 0.03
3011    4479   0.03 0.04

rates_table_custom
dest_id customer_id custom_charge
3010    10          0.015

then when a customer visits their account
(I run a query on the rates_table with a join on the rates_table_custom) for destination Id 3010 they will see charge 0.015 instead of the default one 0.02 and all other destinations will show the default charge

So lets say on the next update the rates table is updated to :

dest_id prefix cost default_charge
3019    359    0.06 0.12
3020    35921  0.03 0.06
3021    35922  0.05 0.10
3011    447    0.02 0.03
3011    4479   0.03 0.04

rates_table_custom
dest_id customer_id custom_charge
3010    10          0.015

How would I test if that destination ID 3010 should be replaced with 3019, 3020 or 3021 ?

my hope was that on each update the API rates updates will return best match for the new dest ID. In this case it would be 3019

something like
3010 replaced with 3019

Otherwise the only solution would be run a query for each custom rate and find the longest destination prefix and use the destination ID as a replacement.

One other query : if the dest id still exists after each update it is safe to use for the custom rates ?
I the same dest id will be set for a completely new prefix range right ?

for example
before update:
dest id 3333 - prefixes : 35920,35921
after the update it will still be something like:
dest id 3333 - prefixes : 3592,3591

it will not change for a completely new prefix range like
dest id 3333 - prefixes : 4474,4475

October 01, 2014 15:10
User photo Simon Woodhead
Simwood eSMS Limited
Hi

I'm afraid we can't help specify your billing system. If you have specific
questions about the API output, don't hesittate to ask.

Kind regards
Simon

October 01, 2014 15:50
User photo Vip-Consult
Vip Consult Limited
Hi.

I understand.

Could you offer some paid support on this ?

October 01, 2014 15:58
User photo Vip-Consult
Vip Consult Limited
or any reference of someone that will be able to help us get this properly solved.

There are many ways to do this , but I prefer to get some help from someone that has already been with this dilemma.

October 01, 2014 16:10
User photo Simon Woodhead
Simwood eSMS Limited
Hi,

We can do paid consultancy but to be honest are taking none on at the
moment given our own internal committments.

I'd price your customers at the breakout level and just link codes to that.
Give each code and rate a start and end date so you can match the longest
match valid at the time you're interested in. You can do the same with
rates and the output from the API naturally lends itself to this.

Kind regards
Simon

October 01, 2014 16:14
User photo Vip-Consult
Vip Consult Limited
I have read your suggestion 10 times and can't understand it :) I am not sure what you mean by a "breakout level"

Is it too much to ask for a simple example.

to be honest I would feel better if I pay you at least an hour of your time for answering my query.

October 01, 2014 20:24
User photo Simon Woodhead
Simwood eSMS Limited
Hi,

I thought I'd told you how to do it for free in the last mail...

I'm afraid I wouldn't know anyone consulting in billing.

Kind regards
Simon

October 01, 2014 20:28
User photo Simon Woodhead
Simwood eSMS Limited
If you were to create a table based on the data coming back from our API,
with from and to dates for each code, you'd be pretty much there.

cheers
Simon

> Hi,
>
> I thought I'd told you how to do it for free in the last mail...
>
> I'm afraid I wouldn't know anyone consulting in billing.
>
> Kind regards
> Simon
>
> On 1 October 2014 16:10, Simwood <team@simwood.com> wrote:
>
>>

October 01, 2014 20:31
User photo Vip-Consult
Vip Consult Limited
Yes the table is based on the values coming from your API.

The part I don't understand it is how to keep the custom rates (based on a customer ID) linked to the new table after each rate update.

I don't think I will understand it without an example, but thanks for your time anyway.

I will try to find someone in the freeswitch channel I know quite a few people there use your SIP termination.

You have been most helpful.

October 01, 2014 21:11