BiTel

Добрый день!

Впервые столкнулись с такой проблемой.
Клиент (услуга интернет, режим дебет) был заблокирован 1.01.15 по недостатку средств на счете (входящий остаток около 120 руб. при абонентской плате 250 руб). 18-го числа он был разблокирован

18.01.2015-… 18.01.2015 06:03:47 Активен Сервер Разблокирован модулем абонплат по достаточному платежу

хотя никакого платежа не было. В этот момент отрабатывало задание планировщика

Начисление NPay абонплат 09.08.2013-… * * * 6 0 работает нормальный

Тарифный план с помесячным режимом снятия пропорционально периоду.

Как такое могло произойти и как избежать подобного в дальнейшем?



Информация о версии:

Сервер: вер. 6.0 сборка 1817 от 12.12.2014 19:45:32
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.7.0_45
npay вер. 6.0 сборка 229 от 14.11.2014 18:59:36

после начисления абопнлаты могло так получится, что денег ему теперь стало хватать на тот момент ?

А, кажется догадываюсь. Вначале месяца ему не хватало, а тут раз и стало хватать - пропорционально периоду же. Что то-то похожее у Phricker-а вроде было, если не путаю.

Кто поминает меня всуе
Вроде такого не было у меня. Хотя у нас и не используются пропорционально периоду ЕМНИМС.
Случаем лимит ему не выставляли? Или скрипт переобсчет баланса не делал?

Или новую опцию не пробовали ставить случайно

Оно же и открывает договора

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

Ну да, так и есть, как стало хватать его разблокировало. Только вот разблокировка у дебетовых клиентов должна происходить по приходу достаточного платежа. А тут платежа не было, а клиента открыло задание - Начисление NPay абонплат, так быть точно не должно. У нас везде такая схема, таких косяков не было.

Лимит 0, первым делом проверили. Опцию не добавляли.

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

Хм, а как защищаться? Как нам эмулировать работу версии 5.1, когда после блокирования клиента он не мог работать пока не оплатил. Нам неинтересно, чтобы клиента разблокировало где-то 18-го числа, когда входящего остатка хватает на конец месяца, а он и не подозревает что у него инет доступен и деньги снялись

Подневное списание абонплат не вариант?

Ну у нас схема работы при которой абонка снимается за месяц и всех блокирует 1-го числа. При подневном я так понимаю в любой момент как деньги закончатся блокировать будет.

Подневной режим списания авансом за месяц

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

А в чем будет отличие от помесячного режима снятия? В день, когда денег будет хватать на остаток месяца, клиента не разблокирует?

Ну у нас не разблокировывает к примеру.
Но ВОЗМОЖНО, что это у вас связано не с режимом начисления абонплат (у нас не используется пропорц. периоду, так что уверенно не могу сказать), а с каким либо скриптом который у вас запускается и делает начисления или переобсчет баланса.
Тогда вам не поможет.

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

Нет, я же написала выше что разблокировка происходит по заданию планировщика "Начисление NPay абонплат", своих скриптов у нас нет. Stark уже подтвердил эту логику работы. Поэтому я не уверенна что подневной режим снятия спасет.

Если вы думаете, что вот это

stark писал(а):

Вначале месяца ему не хватало, а тут раз и стало хватать - пропорционально периоду же.

есть подтверждение логики - то вы ошибаетесь )))))))) Щас Димон придет и скажет, что полгода назад был коммит который менял логику, а Старк об этом не в курсе, а потом окажется что Старк менял логику, но никому об этом не сказал



Спасет. Он не разблокировывает.

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

Я просто вспомнил вот эту тему

там есть нечто похожее, только наоборот. Там как раз нужно открыть, а не открывает. А тут открывает, но нужно не открывать.

Ну про флаг я тоже упоминал. топикстартер утверждает что нет ничего подобного

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

Это было мое предположение. Надо проверять как на самом деле работает. У меня теперь есть сомнения, вроде как пропорционально периоду - это пропорционально периоду действия услуги. Хотя наверное статус тут тоже учитывается.

нет, я имела ввиду


В 5.1 у нас с этим всё ок как раз.

Мне бы вот разделить эти события начисления и прихода платежа =)

А если в 5.1 рубль заплатит?

check.account.changed - этого флага нету. и чесно не поняла как он работает.

Он вам не нужен. Он решает проблему, которой у вас нет.

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

из доков:
"Перевод договора в активный статус происходит по платежу тогда, когда остаток баланса позволяет перевести открыть договор от текущей даты, начислить ему абонентскую плату и баланс при этом не должен опуститься ниже лимита. Минимально необходимая для открытия сумма платежа должна отображаться в дереве карточки договора напротив экземпляра модуля NPay."

А эта сумма у вас не уменьшается в течении месяца ?

Уменьшается, но если клиент оплатил даже рубль и ему хватило на остаток месяца то он в курсе что интернет стал доступен. А когда без платежа становится доступным то клиент сильно возмущается когда узнает в след.месяце что инет был доступен и остаток уже списан без его ведома.

Так есть какой-то способ настроить работу по старой схеме?

Подневной режим списания авансом за месяц.
Вам же уже предложили это

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