BiTel

Сдается мне платеж должен прийти текущим месяцем, в противном случае шлюз остается заблокирован. Если это так, просьба поправить.
И не появилось ли мыслей сделать открытие шлюзов не только по приходу платежа, а скажем при проверке (все равно ведь по всем договорам идет сверка баланса с лимитом для закрытия шлюзов) если баланс не превышает лимит и статус шлюза "заблокирован" и договор активен, то переводить шлюз в состояние status.after.unlock ? Разве это не логичнее, чем выискивать заблокированные договора при "положительном" балансе и гадать почему он не разблокировался ?

А что значит не текущим месяцем ? пришёл платеж за будущий число ?



Ну по идее разблокирование может происходит в одном месте - по приходу платежа..Вот оно там и происходит , так оптимальнее . Можем и добавить , записал в TODO . В 5.1 статус шлюза будем менять отдельная задача , отличная от проверки шлюзов .

я перегружал платежи из 1с, все, между моментом когда я потер все платежи из базы биллинга и моментом когда закончился экспорт биллинг сделал проверку и заблокировал шлюз на договоре, экспорт платежей завершился а шлюз так и остался заблокирован
экспорт добавляет платежи через экшен
я подозреваю что шлюз не разблокировался потому что последний платеж по этом договору был в сентябре


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

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

P.S. что же касается обратной совместимости, если вдруг возникнет мысль реализовать разблокировку шлюзов в задаче проверки статусов, то не проблема же добавить опцию в конфиг ?