BiTel

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

Такая политика. Сформировалась с введением 5.1

Это воспроизводиться . Причем на 5.1 и даже на 5.0 так же работает . И новый статус для этого не обязательно вводить, чтобы воспроизвести. Это никогда не работало . Режим дебетовых абонплат не учитывает приостановленных периодов в будущем , т.е тех, которые начинаются после сегодняшнего числа . Там для упрощения считается что с сегодняшнего числа договор как-будто открыт до конца месяца. Такая логика была с тех пор, как сделали эти дебетовые абонплаты .

Исправлено. В следующем обновлении будет.

Но тут встречный вопрос, а почем должен?
Тут уж оператору выбирать, надо или не надо. Мы в 5.1 для этого специально задачу в шедулер вешали, а теперь вот наоборот вообще никак не сделать, Npay то сильнее.


Касательно перехода в статус Активен из статуса Закрыт.
Логика реально поменялась при переходе с 5.1 на 5.2 и это очень печально.
Переношу скрипт из 5.1, который висел на событии NPay->Открытие договора по приходу платежа и проверял, что если поступивших средств+текущей баланс < Абонплаты по тарифу, то договор опять закрывался и так до тех пор пока абонент не накидает достаточно денег. А теперь же схватка двух якодзун. Скрипт закрывает, Npay открывает и так до тех пор, пока не удалишь платёж.
Логики в таком самостоятельном открытии вообще не вижу, не Npay ставил статус закрыт, не ему его снимать. Как можно вернуться, сэмулировать прежнюю логику?

Лол. В таком случае заведите 2 статуса.
У меня сделан статус "Недостаточно средств" которым оперирует исключительно NPAY и этот статус запрещен к ручной выборке, и статус "Приостановлен" который выставляют скрипты/операторы и иже с ними.

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Завести можно что угодно, но зачем логику менять от версии к версии? Где логика?
Работало раньше, всё устраивало и вот тебе на, бабушка - Юрьев день.

если б всех устраивало, то не меняли бы

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Забавно конечно. Про "всех". Вот появились те, кого новая ситуация не устраивает и что, кого больше "кто сильнее" тот и прав?
Почему бы в таком случае, не давать выбор по логике работы?

Как пример recalculate.on.service.change. Раньше тоже было 0 и 1 и пересчитывал весь период, а теперь есть 2, и только текущий месяц. Значит можно же и для тех и для других. А тут что помешало так сделать?

stark
viewtopic.php?p=66443#p66443

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Не понимаю , почему в вашем случае скрипт закрывает, а npay открывает . Почему денег стало достаточно после переобсчета - вы тариф поменяли ? И зачем вам нужен скрипт, если его поведение совпадает с текущей реализацией дебетовых абонплат ?

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

Вообще не понимаю, почему должно открывать при перерасчете.
Задача модуля расчет абонплаты в данном случае.
Зачем я закрываю я же вроде объяснил.
Логика такова.
Есть тариф с ежедневным списанием до текущего дня. Тариф стоит 1000 р (к примеру).
Есть абонент. Который вместо того чтобы положить 1000р и пользоваться, кладёт по 70р на выходные и пользуется только два дня.
В итоге получаем 280 рублей в месяц, вместо 1000.
Для того чтобы этого избежать, при открытии договора по платежу в 5.1 проверялось, что текущий баланс + платёж >= Тарифа.
Если это условие не выполнялось, договор опять закрывался.
Теперь же это невозможно, потому что сломали поменяли логику и возможности отконфигурировать поведение не оставили.

Я сейчас костыль то сделал. Перевесил скрипт на событие Приход платежа + поменял статусы. Для Npay и его закрытия сделал Недостаточно средств, для скрипта оставил Закрыт. Но грабли были недалеко.
Теперь, если такой закрытый звонит в ТП и просит его окрыть обещая оплатить, установка лимита не работает, поскольку Npay на мой статус Закрыт не реагирует. Теперь надо вешать ещё обработчик и на это событие, а потом может что-то ещё вылезет, а потом помнить про всю это дополнительную логику...

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

оффтоп, но...

to Khoma

я правильно понимаю, что у вас тарифы N рублей за месяц, при этом начало периода может плавать, в зависимости от оплаты?

Да, тарифы вида 100Мбит/с за 1000 рублей в месяц.
Списание подневное до текущего дня.

В нашем случае, начало периода не важно. Главное чтобы баланс был положителен, а уж если заблочился, то пополни на не меньше 1000р.

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

Я удивлен.
Зачем мне подписки? У меня обычный, типовой тариф. Сделанный штатными средствами и меня полностью устраивает его логика работы. Уже несколько лет.
Мне нравится ежедневное списание, удобно при перерасчетах, блокировках/разблокировках и т.д.
Проблема только в том, что поменяли логику работы в Npay. Он стал открывать закрытые договоры при балансе достаточном для работы, чего раньше не делал. Вопрос только в том, можете ли вы сами сделать параметр, возвращающий предыдущую логику или это надо заказывать. (Это прям бизнесмодель ))). Берём убираем/меняем что-то работающее до этого, а возврат за деньги).

Мне нужно, чтобы в 5.2, 6.x была возможность поведения Npay как в 5.1, в случае пересчета договоров в статусе debet.npay.locked.status.

Но мы же не знали о вашем костыле и не могли его учитывать . Изначально кто-то просил дебетовые абонплаты , мы добавили эту логтику , потом поменяли логику при переобсчете, которая не ломает дебетовые абонплаты . Но при этом не работает ваш скрипт . И вы требуете вернуть как было ..Но поменяли мы не только в npay, а еще и в ipn, dialup, drweb и стальных модулях, где есть переобсчет. Теперь любой переобсчет создает событие "баланс изменился" и все вытекающие проверки и действия из этого. Вернуть нужно все , как раньше ? Или только npay ?

Само собой не знали. И не обязаны знать. Есть просто некая базовая логика работы и возможность обрабатывать события.
Если клиент не должен зависить от логики, так надо вообще убрать BGBS и Динкод. Не влезай убьёт.

Просто если что-то меняется внутри модуля, необходимо предусматривать возможность оставить как было.
Я уже приводил пример с recalculate.on.service.change.
Эдак получается завтра любой скрипт можно костылем назвать.

Одного глобального флага вам хватит , на все модули ?

Да, конечно.
Я, не ручаюсь за остальных, может кому-то потребуется и помодульно. ))
Но за общий флаг - спасибо!

А все-таки объясните что глобально поменялось то в вашем случае ? У вас был скрипт , который по приходу платежа исправляет статус обратно . Теперь переобсчет npay тоже генерирует событие приход платежа, опять срабатывает ваш скрипт и меняет статус обратно .Работает как раньше , только чаще .Скорее всего раз в сутки у вас еще одно срабатывание скрипта. Разве нет ? Это просто без ввода доп. статусов и т.п.

Скрипт висел на событии Npay->После открытия договора по платежу. Это позволяло отслеживать открытия и по высталвению лимита также.
В нынешней ситуации, при срабатывании скрипта, если необходимо, договор закрывается, но потом Npay его открывает! И опять срабатывает скрипт, закрывает и опять Npay открывает и так до бесконечности, пока платёж не прибьешь. (((

А как часто у вас запускается переобсчет npay?

Один раз в сутки. В 0:45
Но это задача в планировщике, а то открытие, про которое я пишу, происходит без планировщика.

Т.е кто-то запускает начисление вручную и снова ваш скрипт все исправляет .

Я один, никого больше нет. Могу дать свои конфиги, попробуйте у себя сэмулировать, есть вероятность, что у меня руки кривые.

Ну, хорошо. Вы, один, запускаете переобсчет вручную ?