Непонятки с основным отчетом

Технические вопросы по UTM 5.0
Ответить
cyb3r_ang31
Сообщения: 25
Зарегистрирован: Сб авг 02, 2014 07:38
Откуда: Красноярский край
Контактная информация:

Непонятки с основным отчетом

Сообщение cyb3r_ang31 »

Господа разработчики,
объясните пожалуйста свою логику при формировании основного отчета.

Есть некий абонент 7404.
1. Формируем по нему основной отчет за предыдущий расчетный период (апрель 2016), получаем:

Код: Выделить всё

Входящий остаток: -174.476
Сумма с налогами: 41.736
Платежи: 0.0
Исходящий остаток: -216.212
В этом периоде абоненту высставляется административная блокировка и с абонента перестают списываться средства совсем (так настроены политики списания).

1 мая проведено архивирование таблиц списаний, все списания до 1 мая ушли в архив.

Формируем основной отчет за текущий период (май 2016) и получаем:

Код: Выделить всё

Входящий остаток: 0.0
Сумма с налогами: 0.0
Платежи: 0.0
Исходящий остаток: 0.0
Из дебага видим, что при формировании основного отчета биллинг делает следующие запросы:

Код: Выделить всё

May 05 11&#58;19&#58;04 ?Debug &#58; 51c9c700 DBConnection_mysql&#58; <0x1cec6a0> SQL SELECT query&#58; SELECT start_date,end_date FROM discount_periods WHERE id='156'
May 05 11&#58;19&#58;04 ?Debug &#58; 51c9c700 DBConnection_mysql&#58; <0x1cec6a0> SQL SELECT query&#58; 1 rows in 0.000 sec
May 05 11&#58;19&#58;04 ?Debug &#58; 51c9c700 DBConnection_mysql&#58; <0x1cec6a0> SQL SELECT query&#58; SELECT archive_id,start_date,end_date FROM archives ORDER BY id
May 05 11&#58;19&#58;04 ?Debug &#58; 51c9c700 DBConnection_mysql&#58; <0x1cec6a0> SQL SELECT query&#58; 357 rows in 0.000 sec
May 05 11&#58;19&#58;04 ?Debug &#58; 51c9c700 DBConnection_mysql&#58; <0x1cec6a0> SQL SELECT query&#58; SELECT SUM&#40;discount&#41;,SUM&#40;discount_with_tax&#41;,service_type,account_id,charge_type FROM discount_transactions_all WHERE discount_date >= 1462039200 AND discount_date <= 1464717600 AND account_id='7404' GROUP BY service_type, account_id, charge_type ORDER BY account_id
May 05 11&#58;19&#58;04 ?Debug &#58; 51c9c700 DBConnection_mysql&#58; <0x1cec6a0> SQL SELECT query&#58; 0 rows in 0.000 sec
&#91;b&#93;May 05 11&#58;19&#58;04 ?Debug &#58; 51c9c700 DBConnection_mysql&#58; <0x1cec6a0> SQL SELECT query&#58; SELECT MIN&#40;id&#41;,account_id FROM discount_transactions_all WHERE discount_date >= '1462039200' AND discount_date <= '1464717600' AND account_id='7404' GROUP BY account_id
May 05 11&#58;19&#58;04 ?Debug &#58; 51c9c700 DBConnection_mysql&#58; <0x1cec6a0> SQL SELECT query&#58; 0 rows in 0.000 sec
May 05 11&#58;19&#58;04 ?Debug &#58; 51c9c700 DBConnection_mysql&#58; <0x1cec6a0> SQL SELECT query&#58; SELECT MAX&#40;id&#41;,account_id FROM discount_transactions_all WHERE discount_date >= '1462039200' AND discount_date <= '1464717600' AND account_id='7404' GROUP BY account_id
May 05 11&#58;19&#58;04 ?Debug &#58; 51c9c700 DBConnection_mysql&#58; <0x1cec6a0> SQL SELECT query&#58; 0 rows in 0.000 sec&#91;/b&#93;
May 05 11&#58;19&#58;04 ?Debug &#58; 51c9c700 DBConnection_mysql&#58; <0x1cec6a0> SQL SELECT query&#58; SELECT SUM&#40;payment_absolute&#41;,account_id FROM payment_transactions WHERE payment_enter_date >= '1462039200' AND payment_enter_date <= '1464717600' AND account_id='7404' AND method <> '7' GROUP BY account_id
May 05 11&#58;19&#58;04 ?Debug &#58; 51c9c700 DBConnection_mysql&#58; <0x1cec6a0> SQL SELECT query&#58; 0 rows in 0.000 sec
Т.е. следуя вашей логике, если в текущем расчетном периоде у абонента не было списаний (т.е. биллинг не нашел записей в таблице discount_transactions_all), то и входящий остаток у него 0? Даже не смотря на то, что у него баланс -216.212? Где логика?

cyb3r_ang31
Сообщения: 25
Зарегистрирован: Сб авг 02, 2014 07:38
Откуда: Красноярский край
Контактная информация:

Сообщение cyb3r_ang31 »

Плюс ко всему последнее списание по данному абоненту было -0.0 за секунду до смены расчетного периода.

Я так понимаю, что чтобы увидеть корректный входящий остаток по текущему расчетному периоду, в нем должно появиться хоть какое-то списание (какая то запись в таблице discount_transactions_all), для этого и сделан механизм нулевого списания. Но почему только в конце, т.е. чтобы увидить корректный текущий остаток на лицевом счету я должен ждать окончания расчетного периода?

Аватара пользователя
Magnum72
Сообщения: 1947
Зарегистрирован: Чт сен 22, 2005 06:54
Контактная информация:

Сообщение Magnum72 »

cyb3r_ang31 писал(а):Плюс ко всему последнее списание по данному абоненту было -0.0 за секунду до смены расчетного периода.

Я так понимаю, что чтобы увидеть корректный входящий остаток по текущему расчетному периоду, в нем должно появиться хоть какое-то списание (какая то запись в таблице discount_transactions_all), для этого и сделан механизм нулевого списания. Но почему только в конце, т.е. чтобы увидить корректный текущий остаток на лицевом счету я должен ждать окончания расчетного периода?
Вот такая особенность, отчет некорректен в случае если в заданном временном интервале по которому строится отчет не было списаний у абонента.

cyb3r_ang31
Сообщения: 25
Зарегистрирован: Сб авг 02, 2014 07:38
Откуда: Красноярский край
Контактная информация:

Сообщение cyb3r_ang31 »

Беда, значит придется изобретать собственный очередной велосипед для отчета. Жаль, очень жаль.

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

Аватара пользователя
Magnum72
Сообщения: 1947
Зарегистрирован: Чт сен 22, 2005 06:54
Контактная информация:

Сообщение Magnum72 »

cyb3r_ang31 писал(а):Беда, значит придется изобретать собственный очередной велосипед для отчета. Жаль, очень жаль.

Может кто-нибудь делал уже свой костыль для такого рода отчетности и поделиться своими наработками?
самый совместимый вариант:
воткнуть пользователям у которых не было транзакций запись с нулевым списанием

basker
Сообщения: 51
Зарегистрирован: Вт апр 28, 2015 13:40

Сообщение basker »

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

Ответить