Блокировка юзера без списания АП при окончании РП

[kaN5300]

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

Руководством было принято решение дать варианты работы схемы, при которой у абонента при очончании РП прекращают списываться деньги.

Что имеем сейчас - 4 тысячи абонентов, АП в течении всего РП.
... если баланс <0

Варианты:
1. Добиться того, что бы при достижении отрицательного баланса абонент блокировался и прекращалась списываться АП. При создании новых пользователей такой функционал возможен, добавлением переменной block_recalc_abon.
Но старые 4к абонентов продолжают работать по старому принципу (как им тоже заставить не списывать АП после окончания РП?)
2. Перевести всех на систему списания АП вначале РП, таким образом, пока юзер не пополнит свой баланс, он не сможет работать, иначе блокируется без последующего списания АП.
3. Устанавливать системную блокировку без списания АП на момент окончания РП в случае, если баланс отрицательный. Это идеальный вариант, которого требует начальство.

Реализация п. 1,2 ясна. А как реализовать третий пункт?

[MiO]

помоему единственный нормальный вариант это "снятие АБ в течение расчётного периода"
эту схему уже описывали тут.

и в общем всё получится чётко.... ну хотя у человека получается в "остатке с месяца" 0,50к...

[Arti]

Так чем штатные средства билинга не утраивают ?

Или условие "в начале РП" обязательно к исполнению?

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

[Pei0t]

помоему единственный нормальный вариант это "снятие АБ в течение расчётного периода"

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

[mikkey finn]

так есть же галка "не списывать в заблокированном состоянии"

[AndrewE]

Что бы у "старых" клиентов не списывалась абонка при уходе в минус (в том числе и у того кто уже в минусе и у кого списывается)
стопаем ядро, выполняем запрос в БД УТМ5
UPDATE accounts SET dont_charge_if_block =1, block_recalc_abon=1, block_recalc_prepaid=1 WHERE is_blocked <> 0

Последние 2 поля по желанию

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

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

[AndrewE]

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

Либо ждать от разработчиков реализации такой схемы списания, когда биллинг смотрит достаточно ли у абонента средств для списания (скажем на начало р/периода) если нет, то переводит лиц. счет в состоянии заблокирован, не списывать абонку. при пополнении счета снова смотрит и если все еще не хватает денег то блок не снимать.

думаю реализация такого механизма не составляет большой сложности, но облегчит жизнь всем это однозначно.

[Arti]

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

Обсуждали не так давно это

viewtopic.php?t=6087&highlight=

При желании не сложно все реализовать штатными средствами.

[AndrewE]

именно так как я описал, нельзя.

[Pei0t]

так есть же галка "не списывать в заблокированном состоянии"

Вы имеете в виду block_recalc_abon? Я так полагаю она работает при просто отрицательном балансе, а нужно именно при отрицательном балансе на новом РП.
Тоесть у абонента было в текущем РП +200 рублей, он за этот РП ушёл в минус 50 рублей, и нужно что бы в новый РП он перешёл в заблокированном состоянии без списания АП.

Иначе возможны случаи, когда при лимитированном тарифе, человек за 2 дня (за 50 рублей) скачивает 10гигов, а потом просто блокируется без списания РП. Затем кладёт в новом РП ещё 50 рублей и опять скачивает 10 гигов.

[Arti]

именно так как я описал, нельзя.

можно

[AndrewE]

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

Я хотел бы немного другого метода, можете прочитать о нем еще раз.

[Arti]

Ну в указанной ветке про это уже говорилось. Задача стоит в не разблокировании раньше времени (напрмер пока после блока не принесут XX% абонентки)

На изменения типа блокировки натравливаем правило фаирвола. Ну а там кто во что горазд, проще всего передернуть блокировку в случае необходимости урфаскриптом.

[AndrewE]

Что биллинг делает?
1) Наступил новый период
2) Надо списать бабки по тарифу? Надо!
3) Списали 500 рублей (в начале периода если стоит)
4) Баланс отрицательный, в Блокировку!
При этой схеме, да можно поменять тип блокировки, но в принципе тоже самое делают и нужные галочки.

а хочется что бы так:
1) Наступил новый период
2) Надо списать бабки по тарифу? Надо!
3) Смотрим, хватает денег для списания на балансе
4-1) Хватает, списываем, работаем дальше
4-2) Не хватает, блокируем счет, ждем когда будет хватать.

[Pulse]

urfaclient вам в руки. я так и сделал.. проблема в разблокировке её можно делать только по крону... но в условия поиска попадают пользователи заблокированные по заявлению. это решалось бы, занесением самостоятельнозаблокированных в отдельную группу, но в текущей реализации глюк с поиском по группам не позволяет это сделать.

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