Абоненты

Основной задачей АСР “Pyzzle.ISP” является хранение информации об абонентах оператора связи, учет потребленных услуг и денежных средств. В системе каждый абонент описывается двумя объектами: абонент и услуга. Система может поддерживать несколько классов абонентов и несколько классов услуг. Класс абонента предназначен для хранения и управления информацией о регистрационных данных договора, платежах и т.п., класс услуги хранит и управляет параметрами получаемой услуги связи, например IP адреса, тарифные планы, условия тарификации.

Note

Обычно у оператора связи получается два или три класса абонентов: физическое лицо, юридическое лицо, технологический договор (для заведения различного оборудования оператора, в целях контроля потребления услуг связи этим оборудованием).
Классов услуг тоже может быть несколько, например “доступ в интернет по предоплатной системе расчетов”, “доступ в интернет по постоплатной системе расчетов”, “услуга отключена” или “доступ в интернет по технологии А”, “доступ в интернет по технологии B”.
Обычно получается два класса “Основная услуга” и “Удален”. Удаление абонента происходит как перевод его услуги в специальный класс.
Расчет состояний лицевых счетов абонентов проводится отдельным процессом accounting_daemon в фоновом режиме. Это процесс обслуживает абонентов, у которых в свойствах установлен флаг need_accounting, он устанавливается системой после совершения каких-либо операций с абонентом, например смена тарифа, внесение денег на счет, и т.п. Так же этот флаг устанавливается после получения сведений о новом потреблении услуг. Для выполнения действий завязанных на определенное время, например для завершения расчетного периода, необходимо устанавливать флаг need_accounting абонентам по расписанию, например в полночь (по крону).

Note

Процесс рассчета абонентов должен быть запущен как минимум на одном из серверов в составе информационной системы. Для запуска процесса нужно:
  1. В конфигурационном файле billing.cfg в блоке требуемого сервера указать необходимость запуска процесса, например так:

    [server1]
    daemon_accounting_count=1
    
    Это означает что на сервере server1 должен быть запущен процесс расчета абонентов, будет запущен один экземпляр процесса, без ограничений на обрабатываемых абонентов.
  2. Перезапустить фоновые процессы системы командой CLI:

    Pyzzle> daemon restart accounting
    Starting daemon: accounting Ok
Расчет абонентов выполняется последовательно. Для ускорения расчета большого кол-ва абонентов можно запустить несколько процессов параллельно, процессы можно запускать как на одном физическом сервере, так и распределять на разные сервера. Для этого в конфигурационном файле billing.cfg необходимо указать сколько процессов нужно запустить.
daemon_accounting_count=4

Note

Если в системе используется сервер NoSQL базы данных Redis, то очередь хранится в нем, и тогда можно равномерно распределять абонентов по процессам.

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

CLI-интерфейс системы позволяет просмотреть состояние флага need_accounting для абонентов. Для этого можно использовать команду user.

Pyzzle> user
User summary info
-------------------------
Total user count                44
Total need_accounting count     2
Total block_accounting count    0
В приведенном примере в систему заведено 44 абонента, и 2 абонента ожидают выполнения процедуры расчета. В случае фатальных ошибок в программном коде реализующем расчет абонента для него выставляется флаг block_accounting, а в лог-файлы пишется сообщение с отладочной информацией об ошибке (стек вызова функций системы в результате которого произошла ошибка - traceback) и в этом случае процедура расчета для этого абонента выполняться не будет. В нормально функционирующей системе флаг block_accounting выставляться не должен.
Через CLI интерфейс так-же можно выставить флаг need_accouning для всех абонентов системы командой user need_accounting.
Если по каким-то причинам расчет некоторых абонентов заблокирован, разблокировать его можно командой user unblock.
Через CLI интерфейс возможно выполнение ряда действий над лицевым счетом абонента. Для этого можно перейти в “контекст” конкретного абонента командой user <uid>, где uid - внутренний уникальный идентификатор абонента. В контексте абонента можно выполнить ряд команд, доступность команд зависит от настройки классов абонента и услуги.

Warning

Настройка классов абонента и услуги осуществляется в файле enviroment.py. Должны быть определены соответствующие классы, и создано два хеша.
bill_obj.user_classes и bill_obj.services_classes, в котором в качестве ключей дается внутреннее название класса, а значение - определение класса соответствующее этому названию.
Детальное описание настройки enviroment.py выходит за рамки руководства администратора. Вся настройка системы выполняется при внедрении информационной системы разработчиком, в соответствии с конкретными требованиями заказчика.

Добавление абонента

Как было описано выше, основными характеристиками абонента, влияющими всю логику обработки абонента и его информационные характеристики, являются классы абонента и услуги. В зависимости от класса поля необходимые для нормального обслуживания абонента могут быть различными. Поэтому реализовать универсальную процедуру добавления абонента за один шаг невозможно. Информационная система поддерживает добавления пустого абонента с произвольными классами абонента и услуги.
Для добавления абонента через web-интерфейс предназначена страница “Добавление абонента” - “Стандартное добавление абонента”.
_images/user_add.png
В этой форме нужно указать класс абонента и класс услуги, после добавления абонента откроется страница “изменение свойств”, где нужно будет заполнить все необходимые поля.
Аналогичная функциональность доступна через CLI-интерфейс:
Pyzzle> user add normal normal
User added. UID=85

Note

Приведенный выше метод добавления пользователя неудобен. Поэтому, при внедрении информационной системы, специально создается отдельная страница для добавления “обычных” абонентов в один шаг. На такой странице заполняются все необходимые поля относящиеся к лицевому счету (например ФИО, паспортные данные, адрес), услуге (IP адреса, тариф, тарифная группа), корректно проставлены значения по умолчанию в соответствиями к требованиями оператора связи, а так же автоматически могут выполняться определенные действия с лицевым счетом (например присваивание договору уникального номера в соответствии с правилами принятыми у оператора, распечатка договора и т.п.).
Пример страницы для добавления абонента настроенная для определенного оператора связи:
_images/user_add_custom.png

Поиск абонентов

В информационной системе поиск объектов можно осуществлять по комбинации различных критериев. Поиск абонентов осуществляется через web-интерфейс на странице “Поиск Абонентов”. На странице поиска присутствует таблица, в шапке которой, перечислены допустимые критерии поиска, а так же поля для вводе фильтрующих значений для поиска. Нажав на кнопку “Искать” в таблице будут отображены абоненты, удовлетворяющие критериям. Если будет найден только один абонент, то система автоматически перейдет на страницу с подробной информации об этом абоненте. Если в результате поиска будет найдено много абонентов, то система покажет только часть абонентов а в низу страницы будет кнопка “Показать все”.

Note

Кол-во абонентов отображаемое в результатах поиска настраивается в системном параметре “Кол-во записей на странице поиска абонентов”. По умолчанию значение: 50. Если в качестве значения указать 0, то система будет всегда сразу показывать всех абонентов.
В инсталляциях системы с большим кол-вом абонентов не рекомендуется ставить 0, так как если при осуществлении поиска критерии не будут заданы, то система будет отображать таблицу с полным списком абонентов, что будет приводить к сильному потреблению системных ресурсов, необходимых для отображения информации по тысячам абонентов.

Note

Дополнительно информационная система может скрывать результаты поиска если критериям поиска удовлетворяет большое количество абонентов. Для этого в системных настройках можно указать параметр “Лимит на поиск абонентов”. Например при использовании этой настройки, при попытке найти абонента указав только номер дома система найдет много абонентов и вместо списка выведет сообщение, о том что критерии поиска не достаточно жесткие.

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

Для поиска абонентов в конфигурационном файле enviroment.py должен быть определен специальный класс, в качестве компонентов этого класса включаются различные классы добавляющие возможность поиска по различным критериям. Этот класс должен быть объявлен в bill_obj.user_search_class. Детальное описании процедуры настройки этого класса выходит за рамки данного руководства, и осуществляется разработчиком в ходе внедрения системы.
Для текстовых критериев поиска допустимо использовать специальный символ *, который означает любое количество любых символов. Для числовых критериев можно использовать знаки > и < для фильтрации абонентов у которых значение этого критерия больше или меньше указанного значения. Например если в поле “баланс” ввести “>10000” то система найдет абонентов у которых баланс лицевого счета больше 10 тысяч. Для IP-адресов в критерий можно использовать как текстовое поле, используя символ * (например 192.168.*.15) или ввести сеть с указанием маски (например 192.168.0/23)
При поиске можно комбинировать различные критерии, например найти всех абонентов, проживающих на улице Ленина, с фамилией начинающейся на определенные буквы.
_images/user_search_result.png
Для более удобной работы с поиском, система может позволять скрывать часть критериев поиска от операторов, сокрытие критериев может осуществляться сами оператором на странице “Мои настройки” - “Поля поиска” - “Поиск абонентов”. Это позволяет не захламлять интерфейс поиска, при этом различным операторам пользоваться теми критериями, которые им нужны. Например для абонентского отдела нужны только ФИО, адрес, номер договора. Для службы тех поддержки так же могут понадобиться IP-адреса, другие сетевые реквизиты и т.п.
_images/user_search_setup.png
Так же можно указывать допустимые поля поиска для групп операторов, если поля поиска были спрятаны для группы, то оператор обратно включить их не сможет.

Управление абонентом

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

  • Шапку абонента, в котором указывается ФИО, номер договора и другая информация об абоненте. (Поля и внешний вид шапки настраивается в описании класса абонента)

  • Меню со списком доступных страниц управления абонентом.

  • Поле для просмотра и правки произвольных текстовых комментариев к абоненту. (Если такая функциональность активирована в настройках системы)

    _images/user_page_example.png

Основная информация

При переходе на конкретного абонента, открывается страница “Основная информация” эта страница состоит из набора информационных окон, наличие и содержимое которых, зависит от установленных дополнительных компонентов и поддается гибкой настройке, путем редактирования определения классов абонента и услуги.
В центре странице располагается блок “Информация об абоненте”
_images/user_info_box.png
В этом блоке отображается разнообразная информация о состоянии абонента: реквизиты, телефоны, тарифные планы, состояние услуг, баланс лицевого счета и т.п.

Note

Какие именно данные отображать, и в каком порядке, настраивается в enviroment.py, в определении классов абонента и услуги. За содержимое строк отвечают вызовы функций info_table_box_*(), а за порядок отображения константы INFO_TABLE_BOX_ORDER, INFO_TABLE_ORDER_LAST, INFO_TABLE_BOX_EXCLUDE.

Помимо блока “Информация об абоненте” на странице может отображаться информация о кол-ве потребленных услуг, таблица отображающая текущее состояние IP адресов абонента. Если в систему установлены дополнительные компоненты, то в правой части страницы могут показываться дополнительные блоки, например блок показывающей текущее состояние сетевого оборудования связанного с абонентом, формы для быстрого заведения заявки в тех. поддержку и т.п.

Платежи и списания

АСР “Pyzzle.ISP” предназначена для учета поступлений и списаний денежных средств на лицевом счете абонента. У каждого абонента имеется один лицевой счет. Все действия по изменению его баланса протоколируются (история платежей). Система отдельно хранит текущий лицевой счет, и историю проведения операций по его изменению. История платежей используется только для отображения информации о совершенных операциях не влияет на работу других компонентов системы.
При начислении стоимости потребленных услуг, система может не всегда сразу фиксировать эту стоимость в истории платежей, а может фиксировать ее например при завершении расчетного периода.
Информационная система позволяет иметь у лицевого счета неограниченное кол-во “неподтвержденных платежей”. Неподтвержденный платеж может быть активным в этом случае он учитывается при расчете баланса лицевого счета, или же быть “удаленным”. При этом сохраняется возможность просмотреть все внесенные в систему неподтвержденные платежи. У неподтвержденного платежа может быть установлен срок действия, в этом случае система автоматически удаляет платеж по истечении срока его действия.
При вычислении текущего баланса лицевого счета система использует три вида баланса:
  • “Баланс абонента” - значение баланса хранимое в базе данных системы, полученное по итогам последней операции изменения баланса лицевого счета.
  • “Текущий баланс” - баланс с учетом стоимости уже оказанных услуг, но которая еще не учтена в истории платежей
  • “Эффективный баланс” - текущий баланс + сумма всех активных неподтвержденных платежей.

Note

Чтобы было понятней как работает система рассмотрим практический пример:
Абонента Василий Пупкин завели в систему, первоначальный баланс равен нулю. Пока никаких операций с ним не производилось, у него нулю равны все три баланса используемые системой. Абонент совершил платеж в размере 500 рублей, и его завели в систему, при внесении платежа все три баланса стали равны 500 рублей, а в истории платежей появилась запись про этот платеж, с указанием суммы платежа, баланса счета после операции (500 рублей), даты и времени платежа, оператора совершившего внесение платежа и т.п.
Абоненту установили тарифный план “Первый тариф”, который подразумевает аб. плату в размере 400 рублей, 1000 мегабайт интернет трафика, и 1 рубль за мегабайт дополнительного трафика. (Схемы тарификации, параметры тарифных планов описаны в Тарификация). АСР открывает абоненту расчетный период и списывает 400 рублей, списание аб. платы фиксируется в истории платежей. В этот момент все три баланса абонента равны 100 рублям.
Абонент успешно пользуется услугами связи в пределах 1000 мегабайт, в этом случае дополнительных денег система с абонента не списывает и балансы продолжают равняться 100 рублям.
Как только абонент в течении расчетного периода начинает потреблять больше чем 1000 мегабайт система начинает “списывать” с него стоимость трафика из расчета 1 рубль за трафик превышающий 1000 мегабайт. Стоимость дополнительного трафика не фиксируется в истории платежей до окончания расчетного периода. Поэтому когда абонент потребил 1090 мегабайт трафика, “баланс абонента” равен 100 рублям. “текущий баланс” равен 10 рублям (100 рублей-(1090 мегабайт - 1000 мегабайт)*1 рубль). Поскольку у абонента нет неподтвержденных платежей, то “эффективный баланс” равен 10 рублям.
Информационная система при определении необходимости заблокировать доступ к услугам связи будет руководствоваться “эффективным балансом”.
Абонент знает что ему скоро заблокируют доступ, договаривается с провайдером о том, что абонент в течении нескольких дней оплатит через банк 500 рублей, и оператор вносит а АСР неподтвержденный платеж на сумму 500 рублей и сроком 7 суток. После этого абонент потребляет еще 60 мегабайт трафика.
В результате “баланс абонента” равен 100 рублей (так как стоимость дополнительного трафика будет зафиксирована только по окончании расчетного периода). “Текущий баланс” будет равен -50 рублей, а “эффективный баланс” равен 450 рублей.
Больше абонент трафик не потреблял и пришло время завершать расчетный период. В ходе завершения расчетного периода, АСР зафиксирует стоимость дополнительного трафика, отразив это в истории платежей одной записью вида “дополнительный трафик за расчетный период 150 мегабайт - 150 рублей” В результате “баланс абонента” и “текущий баланс” абонента будут равны -50 рублей, а “эффективный баланс” равен 450 рублей.
После этого оператор связи получает документальное подтверждения оплаты абонентом 500 рублей через банк, и вносит в информационную систему, так же оператор информационной системы отмечает как “удаленный” неподтвержденный платеж абонента, т.к. поступили реальные деньги. В результате все три баланса абонента стали равны 450 рублей.
В случае если бы информация о поступлении средств не поступила бы в течении 7 суток, то система автоматически удалила бы неподтвержденный платеж, и все три баланса абонента были бы равны -50 рублей.
Вносить платежи операторы могут на странице “Прием платежа”.
_images/user_payment_add.png
В поле дата, можно указать другую дату, если платеж был совершен не сегодня (это может потребоваться при внесении расшифровок из банка, которые приходят с запозданием). Подтип платежа - информационное поле позволяющее классифицировать платежи по способу оплаты (наличные, пластиковая карта, банковские переводы, электронные деньги). Комментарий - текстовое поле в которое можно внести произвольную информацию.

Note

Допустимые значения для под-типа платежа определяются в файле enviroment.py в параметре bill_obj.SUB_PAY_TYPE_DESC, это хеш в котором ключ - внутреннее имя подтипа, а значение - отображаемое операторам и абонентам.

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

Note

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

Для внесения неподтвержденных платежей используется страница “Обещанные платежи”, на этой странице можно вносить новые платежи, отменять существующие, а так же просмотреть список активных или удаленных неподтвержденных платежей. Доступ к функциям внесения, удаления и просмотра платежей регулируются отдельно для группы доступа оператора к страницам системы. Удаленные платежи в таблице отмечены серым фоном, а так же для них заполнена дата удаления платежа.
_images/user_untrusted.png
Для просмотра истории платежей абонента используется страница “История платежей”, на ней отображаются все изменения с “балансом абонента”, неподтвержденные платежи, а так же стоимость услуг, которые еще не зафиксированы в виде платежей, на этой странице не отображаются.
_images/user_pay_history.png
Просмотреть все платежи системы за определенную дату, сгруппировав их по типам можно на странице “Статистика” - “Платежи”
_images/stat_pay_history.png

Note

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

История операций

Все операции над абонентом протоколируются. Для просмотра используется страница “История операций”. На этой странице отображается таблица с записями. Так как действия протоколируются очень подробно записей у абонента может быть много, поэтому web-интерфейс системы разбивает записи на страницы. В верхней части таблицы можно, заполнив поля, осуществить фильтрацию сообщений. Для каждой записи указывается время, текст сообщения, а так же указывается какой оператор системы вызвал этот действие. Если процесс был инициирован самой информационной системой (например в ходе выполнения операции расчета состояния лицевого счета) то в колонке “Оператор” будет указано “system”.
_images/user_log.png

Страница “Управление абонентом”

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

Note

Страница “Управление абонентом” настраивается разработчиком индивидуально для каждой инсталляции системы, и включает в себя интерфейс ко всем необходимым функциям управления абонентом, таким как:

  1. Внесение платежей
  2. Внесение и удаление неподтвержденных платежей
  3. Изменение тарифных планов
  4. Управление добровольной заморозкой счета

Так же при необходимости на эту страницу можно добавить интерфейс к другим операциям с абонентом.

_images/user_management.png
В приведенном примере страницы реализовано внесение денег на счет, ручные корректировки и списания, управления неподтвержденными платежами, смена тарифа, продление расчетного периода(подробнее о возможностях компенсаций: Компенсация услуг), а так же таблица с информацией о последних зафиксированных в системе платежах абонента.