Не списывать абонентскую плату при недостатке средств

[Nicola]

Списываем абонентку целиком в начале учетного периода. Надоело делать перерасчеты пользователям, поэтому хочу реализовать такую систему списания абонентской платы, чтобы при недостатке средств на счету она не списывалась, но пользователь блокировался. Встречал упоминания, что кто-то умудрялся реализовать такое, однако без описания, каким именно образом.
После размышлений пришел примерно к следующей схеме:
1. Всем пользователям делать индивидуальные расчетные периоды. Ведь их границы придется двигать индивидуально для каждого юзверя...
2. Абонентскую плату начислять внешним скриптом, а не биллингом. Скрипт проверяет баланс, в случае достаточности средств списывает абонентку, выставляет продолжительность РП. В случае недостатка - блокирует пользователя админской блокировкой, выставляет продолжительность РП, опционально списывает деньги "за блокировку". Скрипт этот запускать раз в сутки. Но тут не ясно, биллинг пересчитывает РП в течение ощутимого времени, как определить, что он уже пересчитал все периоды для пользователей? Достаточно ли будет проверять в базе, не устаревший ли РП у обрабатываемого пользователя?
3. Платежи вносятся так же самописным скриптом, проверяющим, нужно ли списать абонентку и выставляющим окончание РП.

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

[Chrst]

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

А зачем тогда вообще UTM использовать

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

Это как вариант, не более

[Nicola]

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

[Chrst]

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

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

[mrDefault]

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

Какие-то странные у вас пользователи, они что не знают что в конце РП идет списание АП и надо платить деньги?

Я думаю вариант предложенный chrst стоит добавить ещё одним скриптом, который будет выполнятся по крону с какой-то периодичностью, выбирать тех пользователей у которых не прошло списание АП, снова проверять у них наличие средств для списания и если у кого-то уже хватает денег , списывать АП и снимать блокировку.

[XoRe]

2Nicola:

Не ясен алгоритм.
Можно поподробнее про:

Надоело делать перерасчеты пользователям

?

P.S.
Вообще, если нужно снимать абонплату пропорционально тому времени, которое юзер был не заблокирован, то можно сделать так.
Поставить пользователям галочку "В заблокированном состоянии не снимать абонплату".
И в услуге абонплату указать "снимать деньги в конце".
Тогда биллинг сам будет высчитывать, сколько человек "насидел" абонплаты, и снимать соответственно.

[rem_111]

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

А зачем тогда вообще UTM использовать

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

Это как вариант, не более

Скриптом проверки "Хватает денег или нет" поделитесь с обществом ?

[Makariy]

а если вообще отказатся от услуги абонентская плата, а деньги снимать через границы тарификации
к примеру первые 10 мегабайт бесплатно 11 - стоит по цене абонплаты
12 и остальные бесплатно

[integral]

Ну это безлимитный тариф получается, а если абонплата 5 руб и в них включено 100 метров, а превышение стоит по 5 копеек за метр то можно ещё одну границу на 110 мегобайт с суммой 5 копеек.

[Chrst]

Скриптом проверки "Хватает денег или нет" поделитесь с обществом ?

Чтобы чем-либо поделится, это что-либо нужно иметь

[integral]

Скриптом проверки "Хватает денег или нет" поделитесь с обществом ?

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

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

SELECT 
  users.id AS uid,
  users.basic_account AS aid,
  accounts.balance,
  accounts.int_status,
  periodic_services_data.cost,
  accounts.is_blocked
FROM
  users
  INNER JOIN accounts ON (users.basic_account = accounts.id)
  INNER JOIN service_links ON (accounts.id = service_links.account_id)
  LEFT OUTER JOIN periodic_services_data ON (service_links.service_id = periodic_services_data.id)
WHERE
  users.is_deleted = 0 AND 
  accounts.is_deleted = 0 AND 
  service_links.is_deleted = 0 AND 
  periodic_services_data.is_deleted = 0 AND 
  periodic_services_data.discount_method = 1 AND 
  periodic_services_data.cost > 0 AND
  accounts.balance < periodic_services_data.cost

[integral]

Ну а используя консольную админку можно вот так отключать юзверей.

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

#!/bin/sh

PSQL="/usr/local/pgsql/bin/psql"
PGUSER="postgres"
UTM5DB="UTM5"
RUNAS="/usr/local/bin/runas"

RESULT=`echo "SELECT users.basic_account AS aid FROM users \
            INNER JOIN accounts ON (users.basic_account = accounts.id) \
            INNER JOIN service_links ON (accounts.id = service_links.account_id) \
            LEFT OUTER JOIN periodic_services_data ON (service_links.service_id = periodic_services_data.id) \
            WHERE users.is_deleted = 0 AND accounts.is_deleted = 0 AND service_links.is_deleted = 0 AND \
                  periodic_services_data.is_deleted = 0 AND periodic_services_data.discount_method = 1 AND \
                  periodic_services_data.cost > 0 AND accounts.balance < periodic_services_data.cost" | $RUNAS $PGUSER $PSQL -t -U $PGUSER -d $UTM5DB`

for i in $RESULT;
do
  java -jar u5sh.jar --AdminLogin init --AdminPass init --CoreHost 127.0.0.1 --CorePort 11758 --ChangeAccount -aid $i -block 1792
done

PS. На себе не проверял..

[Andriuxa]

У меня такая же проблема.
Вначале думали установить сумму на безлимитные тарифные планы и сделать ежедневный РП. Но проблема в том - как это будет влиять на загруженность сервера.

Сейчас парюсь так же, как и основатель темы.
Сначала проверяю когда абонент платил, потом проверяю сколько он платил и состояние его баланса на начало прошлого месяца.
К этому добавляется запара с тем, что если пользователь не пользовался 1 месяц и у него на балансе, скажем долг -400 рублей (абонент заблокирован), то при внесении платежа 29, 30 или 31 числа система принимает эти деньги и разблокирует его. А с 1го числа у него снова минус.
Биллинг не понимает, что платеж должен пойти на следующий месяц.

[integral]

Так теперь бы заставить запускаться скрипт в последний день месяца.. Ведь где то 30 где-от 31 день, а где-то и 28-29 дней.

[Chrst]

Так теперь бы заставить запускаться скрипт в последний день месяца.. Ведь где то 30 где-от 31 день, а где-то и 28-29 дней.

Скрипт запускать каждый день, в начале скрипта проверять валидность даты для каждого из месяцев (всего 12 проверок), при несовпадении просто завершать. За 5 минут можно сделать проверку дат через if, но можно и покрасивше сделать.

P.S.: корректность проверки високосный/не високосный год не учтена, но это тоже не проблема.