5.2.1-007 u10
Расчетный период стандартный месяц 01.xx.201y 30.xx.201y
АТС выдает информацию о совершенных вызовах несколько раз в час из буфера.
Таким образом данные о вызовах с 23:45 30.xx.201y попадут в биллинг уже после окончания расчетного пероида и не фигурируют в счете ( те сумма счета меньше на стоимость вызовов за 23:45:00-23:59:59 30.xx.201y), но правильно отображаются при выборе Отчеты/Телефония/Предыдущий Месяц
Что посоветуете?
конец расчетного периода и телефония
тут где-то уже было подобное обсуждение, насчёт звонков в конце расчетного периода. имхо, в случае парсинга CDR неизбежно будет инертность, которая приведёт всегда к подобным ошибкам в расчетах. разработчики обещали в 009 попилить телефонию, в частности шёл разговор про межоператорские расчёты, может и с этими косяками чонить придумают. имхо, их надо включать в следующий счёт.
кстати, ещё непонятно как счета формируются. цена у меня почему-то выставляетя в 0.00, хотя в услуге стоит цена 0.02, количество равно количеству минут, а стоимость считается правильно(цена из услуги умноженная на количество минут). почему цена 0.00 непонятно. и ещё можно было бы счёт по зонам разбить штоль...а то такой счёт в котором цена 0.00, а так же в котором количество местных минут, внуризоновых и мг/мн тупо суммируется абоненту не отправишь...
в отчете ваще крутой глюк отловил. загнал данные с атс за июнь через unif делаю отчет по абоненту
показывает за год 8 звонков,
но я знаю что звонков было 9, ибо в базе везде 9
нету звонка который начался 31го мая, однако даже направление и зона для него определились..
UPD. вышеописаный глюк связан с тем, что нет соответствующих архивных таблиц за часть запрошенного мной в отчете периода
показывает за год 8 звонков,
но я знаю что звонков было 9, ибо в базе везде 9
Код: Выделить всё
mysql> select * from tel_sessions_detail where account_id=14352;
+------+-------------+------------+-----------+------------+-------------+----------+----------+-----------+----------+
| id | dhs_sess_id | recv_date | trange_id | account_id | disc_per_id | slink_id | duration | base_cost | sum_cost |
+------+-------------+------------+-----------+------------+-------------+----------+----------+-----------+----------+
| 39 | 48 | 1279202583 | 1001003 | 14352 | 16 | 23003 | 7380 | 0 | 0 |
| 69 | 124 | 1279202585 | 1001003 | 14352 | 16 | 23003 | 4020 | 0 | 0 |
| 159 | 328 | 1279202591 | 1001004 | 14352 | 16 | 23003 | 60 | 0.2 | 0.2 |
| 228 | 469 | 1279202595 | 1001003 | 14352 | 16 | 23003 | 1680 | 0 | 0 |
| 365 | 853 | 1279202608 | 1001003 | 14352 | 16 | 23003 | 2400 | 0 | 0 |
| 467 | 1089 | 1279202615 | 1001003 | 14352 | 16 | 23003 | 5400 | 0 | 0 |
| 553 | 1292 | 1279202621 | 1001003 | 14352 | 16 | 23003 | 4380 | 0 | 0 |
| 588 | 1375 | 1279202624 | 1001003 | 14352 | 16 | 23003 | 2640 | 0 | 0 |
| 1276 | 2963 | 1279202672 | 1001003 | 14352 | 16 | 23003 | 4980 | 0 | 0 |
+------+-------------+------------+-----------+------------+-------------+----------+----------+-----------+----------+
9 rows in set (0.00 sec)
Код: Выделить всё
mysql> select count(*) from tel_sessions_log where account_id=14352;
+----------+
| count(*) |
+----------+
| 9 |
+----------+
Код: Выделить всё
mysql> select count(*) from discount_transactions_all where service_type=6 and account_id=14352;
+----------+
| count(*) |
+----------+
| 9 |
+----------+
Код: Выделить всё
mysql> select id,account_id,zone_id,did,acct_session_id,acct_session_time,h323_setup_time,session_start_date from tel_sessions_log where account_id=14352 and id=48;
+----+------------+---------+---------+-----------------+-------------------+---------------------------------------------------+--------------------+
| id | account_id | zone_id | did | acct_session_id | acct_session_time | h323_setup_time | session_start_date |
+----+------------+---------+---------+-----------------+-------------------+---------------------------------------------------+--------------------+
| 48 | 14352 | 1 | 1001003 | 9835287 | 7377 | h323-setup-time=*21:51:46.000 MSD Mon May 31 2010 | 1275328306 |
+----+------------+---------+---------+-----------------+-------------------+---------------------------------------------------+--------------------+
UPD. вышеописаный глюк связан с тем, что нет соответствующих архивных таблиц за часть запрошенного мной в отчете периода