BiTel

Форум BiTel
bgbilling.ru     docs.bitel.ru     wiki.bitel.ru     dbinfo.bitel.ru     bgcrm.ru     billing.bitel.ru     bitel.ru    
Текущее время: 28 апр 2024, 19:22

Часовой пояс: UTC + 5 часов [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 3 ] 
Автор Сообщение
СообщениеДобавлено: 15 апр 2014, 15:43 
Не в сети

Зарегистрирован: 15 апр 2014, 14:49
Сообщения: 4
Карма: 0
Здравствуйте, у меня проблема с обсчетом звонков по операторскому тарифу. Debian 6, BGBilling 5.1, настраивал по этой инструкции - http://bgbilling.ru/v5.1/doc/ch04s11s02.html

Проблема заключается в том, что при формировании отчета за месяц по операторскому объему минут (oper_round_session_time) и стоимости (oper_session_cost) возникли расхождения порядка 17% с оператором для которого отчет предоставлялся.

При дальнейшем разбирательстве выяснилось, что в базе данных в таблице логов сессий (log_session_11_yyyyxx) не на всех нужных звонках выставлен параметр oper_id=1, соответственно не везде подсчитаны oper_round_session_time и oper_session_cost. Причем какой-то закономерности не наблюдается, т.е. возможна ситуация, когда на одном и том же договоре (с правильно выставленным тарифом) часть логинов(телефонов) считается полностью, а часть начинает считаться только с какого-то определенного момента времени. При этом поля round_session_time и session_cost считаются верно на протяжении всего месяца.

Если смотреть на примере данных из log_session_11_201402, то выглядит это примерно так:
Один и тот же номер, звонки в разные числа месяца:
Код:
+---------------------+--------------+--------------------+-------------+-------------+--------------+---------+-------------------------+-------------------+
| session_start       | session_time | round_session_time | from_number | to_number   | session_cost | oper_id | oper_round_session_time | oper_session_cost |
+---------------------+--------------+--------------------+-------------+-------------+--------------+---------+-------------------------+-------------------+
| 2014-02-10 10:57:55 |           31 |                 60 | 318219      | 79050393372 |      1.77000 |       1 |                      31 |           0.71817 |
| 2014-02-10 11:48:10 |            0 |                  0 | 318219      | 79139216212 |      0.00000 |       1 |                       0 |           0.00000 |
| 2014-02-10 12:44:34 |           17 |                 60 | 318219      | 79045152023 |      1.77000 |       1 |                      17 |           0.38533 |
| 2014-02-10 13:49:07 |           36 |                 36 | 318219      | 787701      |      0.00000 |       0 |                       0 |           0.00000 |
| 2014-02-10 15:11:14 |           62 |                120 | 318219      | 79139648436 |      3.54000 |       1 |                      62 |           1.40533 |
| 2014-02-10 15:41:03 |           84 |                 84 | 318219      | 451369      |      0.00000 |       0 |                       0 |           0.00000 |
| 2014-02-10 15:45:50 |           94 |                 94 | 318219      | 453624      |      0.00000 |       0 |                       0 |           0.00000 |
| 2014-02-10 16:35:32 |          106 |                106 | 318219      | 325211      |      0.00000 |       0 |                       0 |           0.00000 |
+---------------------+--------------+--------------------+-------------+-------------+--------------+---------+-------------------------+-------------------+

10 февраля видим что oper_id включается на внутризону и операторские время и стоимость засчитываются

Код:
+---------------------+--------------+--------------------+-------------+-------------+--------------+---------+-------------------------+-------------------+
| session_start       | session_time | round_session_time | from_number | to_number   | session_cost | oper_id | oper_round_session_time | oper_session_cost |
+---------------------+--------------+--------------------+-------------+-------------+--------------+---------+-------------------------+-------------------+
| 2014-02-27 10:25:53 |            0 |                  0 | 318219      | 79236935055 |      0.00000 |       0 |                       0 |           0.00000 |
| 2014-02-27 10:38:08 |           14 |                 14 | 318219      | 660788      |      0.00000 |       0 |                       0 |           0.00000 |
| 2014-02-27 11:25:36 |           20 |                 20 | 318219      | 376601      |      0.00000 |       0 |                       0 |           0.00000 |
| 2014-02-27 12:09:58 |           49 |                 49 | 318219      | 453588      |      0.00000 |       0 |                       0 |           0.00000 |
| 2014-02-27 12:47:41 |           35 |                 60 | 318219      | 79059424052 |      1.77000 |       0 |                       0 |           0.00000 |
| 2014-02-27 13:45:40 |           51 |                 51 | 318219      | 453574      |      0.00000 |       0 |                       0 |           0.00000 |
| 2014-02-27 14:23:06 |           59 |                 60 | 318219      | 79620376846 |      1.77000 |       0 |                       0 |           0.00000 |
| 2014-02-27 15:17:46 |           49 |                 60 | 318219      | 79620376846 |      1.77000 |       0 |                       0 |           0.00000 |
| 2014-02-27 16:45:33 |           57 |                 57 | 318219      | 533733      |      0.00000 |       0 |                       0 |           0.00000 |
+---------------------+--------------+--------------------+-------------+-------------+--------------+---------+-------------------------+-------------------+

27 февраля видим что oper_id не включается на внутризону и операторские время и стоимость не засчитываются

Изменений на договоре по смене тарифа или добавлению/удалению номеров не происходило. Причем некоторые контрагенты обсчитываются вообще без проблем, а у некоторых проблемна рандомная часть номеров(логинов) в случайные промежутки месяца.
В конфигурации модуля voiceip:
Код:
#название
operator.1.title=mts_operator
#код(id) договора-оператора
operator.1.cid=9991
#наработку по оператору c кодом услуги ХХХ класть в наработку договора с кодом услуги ХХХ
operator.1.account.55=55
operator.1.account.56=56
operator.1.account.57=57


В скриптах предобработки на насах выставлены request.setOption( "operator", 1 ); . Установка балансов VoiceIP включена.

Может кто-то сталкивался с чем-то подобным или если есть какие-то мысли по этому поводу, буду очень благодарен за совет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 16 апр 2014, 10:22 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Вам нужно найти в логах радиуса эти звонки и проверить факт вызова скрипта ..Там пишет "REQUEST_AFTER_SCRIPT" . Или в самом скрипте можно сделать вывод дополнительный в логи прямо в том месте где вы ставите setOption чтобы убедится, что код вызывается.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 16 апр 2014, 11:50 
Не в сети

Зарегистрирован: 15 апр 2014, 14:49
Сообщения: 4
Карма: 0
Спасибо за совет, voip радиус-логи у нас хранятся около недели. В последнее время проблемных звонков судя по базе не было, как появятся - будем искать в логах. Отпишусь по результатам.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 3 ] 

Часовой пояс: UTC + 5 часов [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
POWERED_BY
Русская поддержка phpBB
[ Time : 0.068s | 24 Queries | GZIP : On ]