BiTel

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

• При создании договора ему устанавливается статус "приостановлен", который для него будет пожизненным.
• В момент подключения (речь пока о dialup, но с inet аналогично) проверяем хватает ли денег на абонентку.
  
  • Если денег хватает, то ставим статус "активен" на этот день.
  • Если абонент подключается в след. день - продлеваем предыдущий "активен" еще на один день.
  • Если абонент подключается через день, то статус "активен" на этот день.
  • И т.д. и т.п.
  Т.е. фактически делаем врезку/продление статуса "активен" в постоянный "приостановлен".

В чем профит?
Статус можно использовать как средство мониторинга реальной активности абонента и, при необходимости, производить с договором какие нибудь операции при длительном нахождении его в статусе "приостановлен".
По идее должно работать практически с любыми тарифами.

В чем минус - нагрузка на БД.

Собсно вопросы:
Насколько подобная схема жизнеспособна?
Вопрос риторический, но все же - можно ли как-то автоматизировать стандартными средствами? Если все только своими скриптами - буду рад любому пинку в нужном направлении.

а не проще ли при смене статуса, когда он блокируется по недостатку средств менять группу? =)


Бдыщ!!!

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Так можно, но ...

Суть замута в том чтобы _точно_ знать когда абонент работал не лазая в сессии. Представь, что из месяца в 30 дней ты видишь что 40% юзеров активны Х дней, 30% юзеров активны Y дней и 20% активны Z дней (оставшиеся 10% выпадают из общей статистики). При этом можно посмотреть кто и когда активен в каждой из этих групп. Ты сможешь предложить тарифы не только на основе своей выгоды, но и на основе неких "предпочтений" пользователей, например если большой % сидит в инете только в выходные. Да, такие вещи можно мониторить и по кол-ву сессий, но статусы позволяют бОльше, чем сессии В качестве примера - ты можешь с точность до дня узнать когда юзер был активен последний раз и уже дальше думать что с ним делать.

а если использовать параметр договора с галочкой и логировать его изменение?

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Каким образом параметр договора влияет на услуги/перерасчеты?

Так и не понял зачем . Чем не устраивают дебетовая схема абонплат ? Если нужно мониторить реальную активность абонента - чем сессии не устраивают ? При чем тут статус? зачем лишние сущности плодить если они не несут никакой дополнительной информации ?

Этим:

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



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



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

Ну сделайте отчет об активности абонентов .

Я не вижу смысла в проставления статуса каждый день . Ну сделайте скрипт тогда глобальный, который будет каждый день запускаться анализировать сессии и проставлять статусы . Причем лучше в отдельную таблицу какую-нибудь (типа своих статусов ) и по это таблице стройте отчет. А еще лучше просто отчет сразу без проставления статусов. Вы хотите чтобы система сохраняла больше данных ради аналитики - это неверный подход. Системе должна сохранять мимимум данных(в данном случае есть сессии и статусы текущие) , а по ним уже стройте необходимую вам аналитику.