Похоже utm5_payment_tool не пересчитывает unabon_period

[Vartushkin]

Описание проблемы:
У всех абонентов стоит галка - "в заблокированном состоянии не списывать абон. плату". Деньги списываются плавно, когда на счету остается минус несколько копеек, абонент блокируется и далее деньги не списываются. Далее поступает платеж посредством утилиты utm5_payment_tool и он успешно вносится, но при следующем цикле списании баланс лицевого счета абонента дисконтируется ровно на ту сумму которая соответствует его времени простоя.

Догадки:
Помоему в момент совершения платежа, должны пересчитываться поля unabon_period и start_block_unabon в таблице periodic_service_links, но судя по записям в debug.log такого пересчета не происходит.

Версии:
utm5_core: 5.2.1-004-bsd6
utm5_payment_tool: 5.2.1 (Compile date: Dec 5 2006 17:18:48)

Вопрос:
Кто знает, что мне делать, ведь тут везде написано что даже пытаться самостоятельно ввести платеж в базу нельзя, только через payment_tools, может другая версия нужна?

[Pulse]

проблема точно не в utm5_payment_tool . А чо там в логах то? и скриншот бы отчет по услугам отчёт по блокировкам и отчет по платежам

[atdp03]

Причём это происходит далеко не всегда.

По проблеме проведено тестирование, в результате которого
удалось воспроизвести данную ошибку. Информация передана
разработчикам - Mantis ID 641.

(с) хотлайн, 25.10.2006 года, 5.1.10-017.

На нашей текущей 5.2.1-005, ситуация не изменилась.
Смирились, правим руками, благо нечасто.

[Vartushkin]

проблема точно не в utm5_payment_tool . А чо там в логах то? и скриншот бы отчет по услугам отчёт по блокировкам и отчет по платежам

Я не уверен, что виноват utm5_payment_tool, просто необоснованное списание денег происходит именно после употребления этой утилиты. При внесении платежа через UTM_Admin такого вроде бы не наблюдалось.

Как правильно заметил atdp03, это происходит не часто, у меня примерно раз в сутки. Вот, например, скриншоты сегодняшнего инцедента.

Логи, к сожалению уже ушли, в следующий раз выложу.


Вот на этой картинке видно, что человек положил 100 руб. на -72 коп., получилось 99 руб., (этот расчет у мы заносим в админские коменты с помощью utm5_payment_tool в момент платежа), но вскоре на счету осталось только 24 рубля.

То есть необоснованно списалось примерно 73 рубля, точнее можно посмотреть в discount_transactions_all :

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

+------------------------------+---------------+---------------+----------+
| from_unixtime(discount_date) | incoming_rest | outgoing_rest | discount |
+------------------------------+---------------+---------------+----------+
| 2010-03-22 16:02:03          |       99.2803 |       26.0655 |  73.2148 |
+------------------------------+---------------+---------------+----------+

На этом скриншоте видим, что последняя блокировка длилась примерно 3.5 суток, при абон. плате 600 руб в месяц, как раз и получается 73 рубля.

Вот я и делаю предположение, что utm5_payment_tool время от времени забывает пересчитать unabon_period и start_block_unabon в таблице periodic_service_links. А что еще может привести к появлению такого дискаунта!?

[Magnum72]

utm5_payment_tool точно не причем, скорее всего порушилась целостность базы, попробуйте посмотреть у этого абонента, нет ли у него двойных блокировок в таблице block_info?
Правильно ли выставляется блокировка в таблице accounts (поставьте ему кредит -1000 чтобы он заблокировался и посмотрите).
Блокировка может не срабатывать если галочка ставится после наступления блокировки или возможно биллинг теряет эту галочку в процессе работы, так как он грузит при старте таблицу accounts в память и без принудиловки ее не перечитывается с базы. В любом случае если биллинг не хупали или не ребутали то проверьте какого типа блокировка выставляется при блокировке.

[Vartushkin]

Спасибо за эти рекомендации, но к сожалению все мимо. База цела, двойных блокировок (незакрытых или 20...00) именно у этого пользователя нет, блокировка выставляется 48-я, биллинг галочку не теряет.

Я совершенно точно убедился в том, что необоснованные списания происходят:
1. после того как платеж поступает пользователю находящемуся в заблокированном состоянии без списания а.п. (у меня это 48-я блокировка);
2. не каждый раз (что мешает повторить эксперимент);
3. при следующем после платежа цикле списаний;
4. сумма необоснованного списания равна стоимости времени блокировки
(то есть длительность блокировки умножить на стоимость тарифа делить на число секунд в месяце).