Универсальная биллинговая система BGBilling 4.6


Содержание

1. Описание основной части программы BGBilling
1. Как построено данное руководство
2. Логическая структура биллинга
3. Программная структура биллинга
4. Установка сервера биллинга на OS Linux
5. Установка сервера биллинга на OS Windows
6. Логирование
7. Установка и первый запуск клиента биллинга
8. Описание интерфейса клиента биллинга
8.1. Конфигурации
9. Настройка сервера биллинга
9.1. Настройка почтовой подсистемы
9.2. Настройка системы оповещения
9.3. Закрытый период
10. Модули
11. Плагины
12. Установка обновлений биллинга
13. Установка лицензии биллинга
14. Настройка SSL между сервером и клиентом
15. Настройка планировщика
16. Стандартные задачи планировщика
17. Справочники
17.1. Типы платежей
17.2. Типы расходов
17.3. Параметры договоров
17.4. Группы параметров и Привязка параметров
17.5. Города, кварталы, улицы, дома
17.6. Обслуживание договора
17.7. Значения списков
17.8. Фирмы
17.9. Виды рассылок
17.10. Группы договоров
17.11. Типы времени
17.12. Скрипты поведения
17.13. Шаблоны комментариев договоров
18. Договор
18.1. Общие сведения, создание договора
18.2. Обзор карточки договора
18.3. Параметры договора
18.4. Группы договоров
18.5. Поиск договоров
18.6. Баланс
18.7. Лимит договора, режимы договора, управление лимитом
18.8. Режимы баланса договора
18.9. Статус договора
18.9.1. Роль статуса в дебетовых договорах
18.9.2. Роль статуса в кредитовых договорах
18.9.3. Система работы с кредитовыми должниками
18.10. Тариф и группа тарифов
18.11. Примечания
18.12. Дополнительные действия
18.13. Подключение модулей и их услуг к договору
18.14. Карты регистрации договора
18.14.1. FOP-карточки.
18.14.2. Полная карта договора
18.15. Шаблоны договоров
18.16. Переоформление договоров
19. Тарифные планы
19.1. Стандартные узлы тарифных планов
19.1.1. Услуга
19.1.2. Мульти услуга
19.1.3. Период
19.1.4. Фильтр по времени
19.1.5. Фильтр по типу времени
19.1.6. Параметры тарификации
19.1.7. Использовать карту зон
19.1.8. Зона
19.1.9. Часть префикса и Диапазон префиксов
19.1.10. Стоимость минуты
19.1.11. Множитель цены
20. Субдоговоры
20.1. Добавление субдоговоров
20.2. Зависимые субдоговора
20.3. Независимые субдоговора
21. Объекты
22. Удаление договоров, архив договоров
23. Web-интерфейс пользователя
23.1. Настройка доступа к статистике
23.2. Настройка внешнего вида страницы статистики
23.3. Новости
23.4. Смена пароля на доступ к статистике
23.5. Просмотр баланса, истории платежей, расходов и наработки
23.6. Временное понижение лимита
23.7. Пользовательские рассылки
23.8. Смена тарифных планов пользователем
24. Разграничение прав доступа
25. Загрузка платежей и расходов из файла
25.1. Автоматическая загрузка реестров платежей
26. Сервис
26.1. Индикатор лицензии
26.2. SQL Редактор
26.3. Менеджер рассылок
26.4. Журналы ошибок
26.4.1. Ошибки обработки логов
26.4.2. Ошибки периодических процессов
26.5. Групповые операции над договорами
26.5.1. Операция "Изменение статуса"
26.5.2. Операция "Добавление группы тарифов"
26.5.3. Операция "Открытие тарифных планов"
26.5.4. Операция "Закрытие тарифных планов"
26.5.5. Операция "Добавление(Удаление)модулей"
26.5.6. Операция "Добавление разрешённых услуг"
26.5.7. Операция "Удаление(Прерывание на период) разрешённых услуг"
26.5.8. Операция "Смена тарифа"
26.5.9. Операция "Добавление скрипта"
27. Администрирование и оптимизация
27.1. Настройка логов сервера, планировщика и загрузчика логов
27.2. Конфигурация базы данных, память
27.3. Поддержка репликации
27.4. "Мусорные" базы данных
27.5. Настройка типа хранения помесячных и подневных таблиц в MySQL
2. Язык BGBilling Script (BGBS)
1. Назначение
2. Скрипты поведения
2.1. События скриптов поведения
3. Глобальные скрипты поведения
3.1. Периодическое выполнение глобальных скриптов
4. Скрипты предобработки RADIUS запросов
3. Модуль DialUp
1. Назначение модуля
2. Базовые понятия и алгоритм работы модуля
2.1. SNMP и NetFlow
2.2. Режимы работы RADIUS сервера
2.3. Статус соединения
2.4. Работа с соединением
3. RADIUS атрибуты
4. REALMы
5. Группы атрибутов
6. Выдача атрибутов соединения и выделение IP адресов
7. Настройка модуля
8. Настройка NASов
8.1. Скрипт предобработки запроса
9. Настройка RADIUS сервера для DialUp
9.1. Установка BGRadiusDialup на LINUX платформу
9.2. Установка BGRadiusDialup на Windows платформу
9.3. Настройка radius.properties
9.4. Администрирование BGRadiusDialup
9.4.1. Управление BGRadiusDialup
9.4.2. Расширение словаря RADIUS
9.4.3. Антиспам
9.4.4. Поведение BGRadiusDialup при критических нагрузках
9.4.5. Оптимизация работы с базой данных
9.4.6. Reject-To-Accept
10. Настройка встроенного коллектора
10.1. Переобработка NetFlow трафиков
11. Настройка клиентов
11.1. Вкладка "IP адрес"
11.2. Вкладка "Атрибуты RADIUS"
11.3. Вкладка "Ограничения"
11.4. Вкладка "Логи"
11.5. Вкладка "Пароль"
11.6. Перенос логинов
12. Настройка тарифных планов
12.1. Простейший тариф
12.2. Разделение стоимости по времени суток
12.3. Зависимость стоимости от объема
12.4. Комбинированные зависимости
12.5. Детализация по тарифу
12.6. Использование узла "Мультиуслуга"
12.7. Указание в тарифе свойств соединения
12.8. Тарифы с переоценкой всего потребленного трафика
12.9. Ограничение по NASам
13. Переобсчёт соединений
14. Монитор соединений
15. Интеграция с модулем "Карточки"
16. Отчёты
17. Web-интерфейс
18. Начисление наработки за максимальные трафики
19. Динамическое управление DNS сервером
19.1. Пример настройки DNS сервера
19.2. Пример настройки модуля
19.3. Пример настройки логина
20. Настройка автозакрытия соединений
21. Поддержка CallBack
22. Настройка RADIUS сервера с различными шлюзами CISCO
23. Настройка WiFi-агента для работы с модулем Dialup
23.1. Описание WiFi-агента
23.2. Установка, настройка и запуск
23.3. Связь WiFi-агента с модулем "Карточки".
23.4. Защита WiFi-сети от ARP-спуффинга
23.5. Настройка ограничения скорости(шейпинг) для трафика WiFi-сети.
23.6. Настройка REALM-ов
23.7. Web-интерфейс
4. Модуль VoiceIP
1. Назначение модуля
2. Базовые понятия и алгоритм работы модуля
3. Настройка модуля
4. Настройка режимов поиска и типов логинов
5. Настройка NASов
5.1. Скрипт предобработки запроса
6. Монитор
7. Настройка RADIUS сервера для VoiceIP
7.1. Установка BGRadiusVoip на LINUX платформу
7.2. Установка BGRadiusVoip на Windows платформу
7.3. Настройка radius.properties
7.4. Управление BGRadiusVoip
8. Настройка клиентов
9. Интеграция с модулем "Карточки"
10. Настройка тарифных планов
10.1. Тарификация по префиксам
10.2. Зоновая тарификация
10.3. Смешанный режим
10.4. Модификация стоимости звонка
10.5. Импорт/экспорт тарифов
11. Работа с операторами
12. Отчёты
13. Web-интерфейс
14. Переобсчёт сессий
15. Создание договоров пользователем через Web
5. Модуль обсчёта выделенных каналов IPN
1. Назначение модуля
2. Настройка модуля
3. Базовые понятия и алгоритм работы модуля
4. Привязки услуг (категории трафика)
5. Создание источников и интерфейсов
6. Управление ресурсами IP адресов
7. Добавление адресов абонентам
8. Настройка сбора и обработки логов
8.1. Настройка коллектора в автономном режиме
8.2. Настройка коллектора в связке с flow-tools
8.3. Запуск коллектора
8.4. Наладка приёма данных коллектором в автономном режиме
8.5. Настройка обработки данных
9. Подсистема аудита
10. Тарификация
10.1. Создание тарифных планов
10.1.1. Простейший тариф
10.1.2. Тариф с зависимостью стоимости от объема
10.1.3. Использование узла "Мультиуслуга"
10.1.4. Детализация по тарифу
10.1.5. Установка параметров доступа в тарифе
10.1.6. Комбинированный тариф
10.2. Запуск начисления
10.3. Начисление наработки за максимальные трафики
11. Настройка шлюзов
11.1. Настройка типов шлюзов
11.2. Настройка шлюза
11.3. Типы правил
11.4. Добавление шлюза в договор.
11.5. Выделение ресурса vlan на шлюз.
11.6. Настройка портов шлюза.
11.7. Настройка шлюзов типа Manad
11.7.1. Спецификация Manad
11.7.2. Обработка команд Manad.
11.7.3. Настройка шлюзов типа Manad под FreeBSD
11.7.4. Настройка шлюза типа Manad под Linux
11.8. Настройка шлюзов типа Switch
11.9. Настройка шлюза BGRadiusIPN
11.10. Настройка шлюза CISCO
11.11. Настройка шлюза DLINK 35xx, 38xx
11.11.1. Настройка в связке с DHCP шлюзом.
11.12. Настройка сервера/шлюза DHCP
11.13. Настройка шлюза Mikrotik RouterOS
11.14. Настройка шлюза Cisco2 c коммутаторами
11.14.1. Настройка шлюза Cisco2
11.14.2. Настройка шлюза коммутатора Zyxel
11.14.3. Настройка шлюза DHCP в связке с Cisco2.
11.15. Реализация шлюза на языке BeanShell
12. Отчёты модуля, детализация
13. Web-интерфейс модуля
6. Модуль Карточки
1. Назначение модуля
2. Настройка модуля
3. Дилеры
4. Работа с карточками
5. Генератор логинов и паролей для модуля "Карточки"
5.1. Установка генератора
5.2. Использование генератора
6. Web-интерфейс
7. Web-активация
8. Суперкарты
9. IVR-Система
10. Удалённые платежи
10.1. Настройка модуля
10.2. Настройка дилера
10.3. Web-клиент
10.4. Сверка платежей
7. Модуль TrayInfo
1. Назначение модуля
2. Конфигурация модуля
3. Создание типов логинов
4. Активация TrayInfo клиентом
5. Настройка утилиты TrayInfo
8. Модуль E-Mail
1. Назначение модуля
2. Установка и настройка модуля
2.1. Домены
2.2. Настройка конфигурации
2.3. Хранилище почтовых аккаунтов
2.3.1. LDAP база
2.3.2. SQL база
2.4. Настройка планировщика
3. Использование модуля
9. Модуль отчётов
1. Установка и настройка модуля
2. Отчёты основного модуля
3. Отчёты модуля DialUP
4. Отчёты модуля IPN
5. Отчёты модуля IP Телефония
6. Отчёты плагина CRM.
7. Отчёты модуля Телефония(Phone).
8. Отчёты модуля Карточки
9. Отчёты модуля RSCM
10. Отчёты модуля CerberCrypt
10.1. Отчет "Количество абонентов"
10.2. Отчет "Наработка пакетов"
11. Создание собственных ответов
11.1. Настройка фильтра
11.2. Отчёты JasperReports.
11.3. Табличные отчёты.
10. Модуль Бухгалтерии
1. Назначение модуля
2. Краткий алгоритм работы модуля
3. Настройка модуля
3.1. Настройка позиций
3.1.1. Экстакторы
3.1.2. Детализация по тарифу
3.2. Типы документов
3.3. Настройка банков
4. Настройка параметров договора
5. Выставление счетов и счетов-фактур администратором
6. Работа со счетами
6.1. Первичная подготовка для курьерской службы
7. Работа со счетами-фактурами
8. Панель просмотра документов
9. Генерация печатных форм
10. Отчёты договора модуля
11. Web-интерфейс пользователя
12. Тонкости интеграции с внешними (1С) системами
13. Групповые операции над договорами
13.1. Операция "Добавление типов документов"
11. Модуль Assist
1. Назначение модуля
2. Настройка модуля
3. Оплата через систему Assist
4. Мониторинг и администрирование платежей
5. Важные замечания
12. Модуль WebMoney
1. Назначение модуля
2. Настройка модуля
3. Оплата через Merchant WebMoney Transfer
4. Безопасность
5. Слежение за платежами
6. Коды ошибок
13. Модуль ГОРОД
1. Назначение модуля
2. Настройка модуля
3. Работа с реестрами
14. Модуль RSCM
1. Назначение
2. Установка и настройка модуля
3. Использование модуля
4. События модуля
15. Модуль NPAY (Абонплаты)
1. Назначение модуля
2. Настройка модуля
3. Привязка абонплат к клиентам
4. Алгоритм начисления, примеры тарифов
4.1. Абонплаты, не зависящие от других модулей
4.2. Абонплаты, зависящие от наработки в других модулях
5. Методики построения тарифных планов
6. Начисление
16. Модуль CerberCrypt
1. Назначение модуля
2. Настройка модуля
3. Настройка клиентов
4. Дополнительные возможности для Irdeto Pisys
5. Настройка задач планировщика
5.1. Сопоставление договоров картам
5.2. Установка актуальных статусов пакетов в картах договоров
5.3. Начисление CerberCrypt
5.4. Блокировка должников
5.5. Обновление подписок
6. Настройка тарифных планов
7. Возможности Web-интерфейса модуля
8. Создание договоров пользователем через Web
9. Виртуальный кинозал
17. Модуль MPS (модуль интеграции с платёжными системами)
1. Назначение модуля
2. Настройка модуля
2.1. ОСМП, Empay, Pegas, Rapida, Comepay
2.2. CyberPlat
2.3. XPlat
2.4. Eport
2.5. SFOUR PayBox Alternative
3. Сертификаты
4. Менеджер платежей
5. Сверка платежей
6. Web-интерфейс
18. Модуль Телефония
1. Назначение модуля
2. Настройка модуля
3. Подготовка логов
4. Настройка загрузки и обработки логов
5. Географические коды и карты зон
6. Управление ресурсами номеров
6.1. Добавление ресурсов
6.2. Слежение за ресурсами
7. Учёт абонентского трафика
7.1. Тарифы на местную связь
7.2. Тарифы на МГМН связь
7.2.1. Тарификация по префиксам
7.2.2. Тарификация по зонам
7.2.3. Тарификация с несколькими МГМН операторами
7.2.4. Импорт и экспорт тарифных планов голосовых модулей
7.3. Специфичные тарифные узлы модуля
7.3.1. Стоимость минуты
7.3.2. Фильтр по портам
7.3.3. Установка услуги
7.3.4. Диапазон наработки
7.4. Отчёты в клиенте
7.4.1. Сессии
7.4.2. Наработка
7.4.3. Направления
7.4.4. Услуги
7.4.5. Детализация
7.4.6. Входящие сессии
7.5. Отчёты в Web-интерфейсе
8. Учёт операторского трафика
8.1. Редактирование правил
8.2. Отчёты операторов
8.3. Транзитные операторы
9. Тарификация при работе по агентской схеме
9.1. Составление тарифов при агентской схеме
9.2. Отчетность
19. Модуль DBA
1. Назначение модуля
2. Установка и настройка модуля
3. Использование модуля
20. Модуль DrWeb
1. Назначение модуля
2. Базовые понятия и алгоритм работы модуля
3. Установка и настройка модуля
4. Управление подписками
5. Web интерфейс
21. Плагин HelpDesk
1. Назначение плагина
2. Алгоритм работы
3. Установка и настройка плагина
4. Работа с сообщениями
5. Работа с пакетами обращений
6. Web-интерфейс клиента
22. Плагин CRM
1. Введение
2. Настройка плагина
3. Справочники
4. Журнал звонков
5. Журнал проблем
6. Журнал задач
7. Журнал работ.
23. Плагин "Документооборот"
1. Назначение плагина
2. Установка и настройка плагина
3. Использование плагина
4. Web-Интерфейс
24. Плагин КЛАДР
1. Назначение плагина
2. Установка и настройка плагина
3. Использование плагина
25. Плагин CashCheck
1. Назначение и структура плагина, архитектура системы
2. CashCheck - сервер (сервер печати)
2.1. Установка rxtx-библиотеки.
2.2. Настройка сервера печати и оборудования, поддерживаемые устройства.
2.2.1. Фискальный регистратор Штрих-ФР-К для использования его в BGBilling
2.2.2. Эмулятор принтера, подразумевающегося к использованию в BGBilling
2.2.3. Любой системный принтер, для печати на нём XSL-FO шаблонов.
2.2.4. Устройства с протоколом от компании АТОЛ
2.3. Запуск сервера печати
2.4. Запуск двух копий сервера
2.5. Тестирование
2.6. Анализ ошибок и логгирование
3. Настройка плагина
3.1. Настройка плагина в биллинге
3.2. Настройка внешнего вида чеков (скрипты)
4. Использование плагина
4.1. Очередь печати
4.2. Выбор принтера, отчёты, сервис
4.3. Печать чека
26. Плагин Organizer
1. Назначение плагина
2. Настройка плагина
3. Использование плагина
3.1. Общий обзор
3.2. Добавление задания
3.3. Просмотр текущих заданий
3.4. Поиск заданий
3.5. Выполнение заданий
3.6. Журнал

Глава 1. Описание основной части программы BGBilling

1. Как построено данное руководство

Данное руководство в пошаговом режиме описывает развёртывание системы BGBilling.

Мы настоятельно рекомендуем вам прочитать раздел 1 Описание основной части программы в полном объёме и последовательно. Это поможет вам лучше представлять общую идеологию системы и не теряться в главах - описаниях модулей и плагинов. Последующие за первым разделы вы можете читать в зависимости от тех модулей/плагинов, которые вы будете использовать.

В руководстве принято несколько простых соглашений:

  1. Все названия: файлов, пунктов меню, частей графического интерфейса, пути файловой системы, URL и т.п. выделены жирным шрифтом;

  2. Названия пунктов меню выглядят так: Меню 1=>Пункт 1;

  3. Всё заключённое в скобки <текст> либо {тест} следует трактовать как (подставьте вместо этих скобок то, что описано в тексте);

  4. Иногда названия скриптов указывается таким образом: radius.sh(.bat) ps, что следует трактовать как: запустите radius.sh ps для LINUX-платформы, либо radius.bat ps для Windows-платформы.

Вам также потребуются навыки запуска консольных приложений с набором аргументов. Для пользователей LINUX это не составит проблемы, для Windows мы рекомендуем сразу установить и использовать консольные оболочки, например FAR Manager, либо пользоваться пунктом меню Пуск=>Выполнить, где сначала запускать командный интерпретатор cmd (чёрное окно с командной строкой), а далее в нем вводить команды.

Данное руководство описывает вопросы настройки непосредственно биллинга, вопросы настройки вспомогательного ПО, примеры тарифов и более подробные описания решений на базе биллинга вы можете найти в WiKi. Вы также можете описать там ваши интересные разработки.

2. Логическая структура биллинга

В системе BGBilling можно выделить следующие основные подсистемы:

  • ядро системы,

  • плагины ядра,

  • модули.

Ядро системы выполняет следующие функции:

  • подключение модулей и плагинов;

  • ведение перечня услуг;

  • ведение справочников;

  • ведение базы договоров;

  • ведение базы объектов;

  • ведение баланса договоров, истории приходов/расходов;

  • СРД - система разграничения доступа пользователей к функциям ядра, плагинов и модулей;

  • некоторые дополнительные функции.

Плагины - это программные компоненты, расширяющие функционал ядра.

Плагины инсталлируются в систему и могут быть активированы/деактивированы администратором в меню Сервис=>Настройка плагинов. После инсталляции в систему плагины нельзя удалить, можно только деактивировать. Потребность в отключении плагина может возникнуть, например, при истечении тестового периода лицензии на плагин.

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

Модули - это программные компоненты, расширяющие функционал ядра и предоставляющие, обычно, функционал связанный с тарификацией тех или иных услуг в биллинге.

Экземпляры модулей и перечни услуг в них создаются администратором в меню Модули=>Редактор модулей и услуг. Экземпляры модулей могут быть впоследствии удалены вместе со всеми данными.

Отличия плагинов и модулей в следующем:

  1. плагины никогда не предоставляют функционала по тарификации услуг, соответственно, услуг в плагинах нет;

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

  3. один и тот же модуль, в отличие от плагина, может быть создан в биллинге в нескольких экземплярах (например, вы можете создать DialUp и VPN модули как 2 экземпляра модуля DialUp).

Услуга - способ разделения наработки договора по типам. Например, в модуле DialUp могут быть определены услуги: Входящий трафик, Исходящий трафик, Время. Наработка в договоре будет начислена с разбиением по данным услугам.

Договор - это ключевое понятие системы. В терминах BGBilling договор - это отдельная сущность, содержащая набор параметров, подключённых к нему модулей и тарифного плана по которым услуги модулей тарифицируются. Каждый договор обладает отдельным балансом.

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

Биллинг работает в единой валюте, мультивалютность не поддерживается.

3. Программная структура биллинга

Данная биллинговая система выполнена в клиент-серверном варианте. Общая структура изображена на рисунке.

На представленной схеме цветами выделены следующие виды компонентов:

Зелёным - отдельный процесс в операционной системе, запущенная программа;
Синим - библиотеки модулей, плагинов, либо ядра (серверные или клиентские части);
Жёлтым - часть базы данных;
Серым - визуальное отображение в клиентском приложении.

Можно выделить несколько основных частей:

Cерверная часть (BGBillingServer) - обрабатывает запросы клиента и Web запросы;
Клиентская часть (BGBillingClient) - визуализирует работу с сервером, AРМ оператора и администратора биллинга;
Web интерфейс пользователя (Web браузер клиента) - позволяет пользователям просматривать и модифицировать свои параметры а также получать оперативные отчёты по модулям (просмотр сессий, звонков и т.д.);
База данных MySQL - единое хранилище и связующее звено компонентов биллинговой системы.

Можно заметить, что приложения BGBillingServer, BGScheduler, BGDataLoader используют общие библиотеки (BGBillingServer/lib), но физически являются разными процессами.

Связь клиента с сервером биллинга осуществляется через HTTP протокол, также к серверу может обращаться браузер клиента провайдера для получения доступа к странице статистики. К серверу биллинга могут одновременно обращаться большое число клиентских приложений. Более того, под видом клиента для получения данных или их модификации к серверу могут обращаться сторонние приложения (например, бухгалтерское ПО). При этом сервер биллинга также производит авторизацию и контроль прав доступа этого клиентского приложения.

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

Также на схеме изображено, что экземпляр модуля (отдельный пункт в меню Модули) является ничем иным, как обособленным блоком данных в БД.

Преимущества клиент-серверной технологии заключаются в:

  • возможности удалённого управления серверной частью с помощью клиента;

  • одновременном доступе неограниченного количества рассредоточенных операторов к данным биллинговой системы;

  • независимости автономной работы сервера от наличия запущенного клиентского приложения;

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

4. Установка сервера биллинга на OS Linux

Для простоты приведён пример установки сервера биллинга в директорию /usr/local для Fedora Linux 7. Если вы хотите установить систему на другой диск, поменяйте пути везде где необходимо их указать. Для всех BASH скриптов необходимо установить права на исполнение.

Все указанные ниже шаги выполняются под пользователем root.

Проверены SUN и работают дистрибутивы LINUX, указанные здесь. Разработчиками BiTel проверена работа в системах ASP LINUX, Fedora LINUX.

Fedora LINUX является официально рекомендуемым дистрибутивом BiTel.

Замечание

При использовании Gentoo LINUX обнаружена проблема с некорректным определением java текущей временной зоны. Данная ошибка связана с тем что SUN JAVA определяет временную зону по содержимому файла /etc/sysconfig/clock, который отсутствует в данном дистрибутиве.

Для решения проблемы создайте этот файл самостоятельно, заполнив следующим содержимым:

# The ZONE parameter is only evaluated by system-config-date.
# The timezone of the system is defined by the contents of /etc/localtime.
ZONE="Asia/Yekaterinburg"
UTC=false
ARC=false

Название временной зоны вы можете получить из названия каталога и файла в /usr/share/zoneinfo. Правильность установки зоны можно проверить по отметкам времени, выводимому в логе BGBillingServer/log/server.log.

1) Установите MySQL Server версии 5.0 либо новее. Мы рекомендуем вам устанавливать версию, входящую в репозитарий вашего дистрибутива.

Например, в Fedora и других дистрибутивах с поддержкой yum вы можете сделать это так (выполняется под пользователем root):

yum install mysql, mysql-server

В случае если ваш дистрибутив не предоставляет пакетов, вы можете загрузить универсальные LINUX RPM пакеты на нашем сайте bgbilling.ru.

Найдите в /etc файл my.cnf - конфигурация MySQL и скорректируйте в нем следующую опцию (если опции нет, добавьте её после соответствующего тега [mysqld]):

[mysqld] 
max_allowed_packet=50M
myisam_data_pointer_size = 6
max_connections=1000

Первая опция позволит передавать большие пакеты между сервером BGBilling и SQL. Если вы это не сделаете, вы не сможете ставить модули. Вторая - увеличивает максимальное количество строк в MyIsam таблицах.

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

Скорректируйте следующую опцию (если опции нет, добавьте её после соответствующего тега [mysqld_safe]):

[mysqld_safe]
open-files-limit=32000 

Опция увеличивает количество разрешённых одновременно для открытия файлов.

Внимание

Внимательно проверяйте по документации все устанавливаемые опции в my.cnf, запрещается установка в параметре sql-mode режимов STRICT_TRANS_TABLES и STRICT_ALL_TABLES, это приведёт к неработоспособности некоторых компонентов биллинговой системы.

Запрещается установка опции skip-networking, т.к. Java приложение подключается к серверу с использованием TCP протокола, а не через файловый сокет.

2) Выполните команду service mysqld start для запуска MySQL сервера.

3) Установите (если нет) JRE (JAVA машина), последнюю версию можно найти по адресу http://java.sun.com/j2se, либо вы можете загрузить её с нашего сайта. JAVA - язык на котором написан биллинг является интерпретируемым и запускается с помощью специальной программы JAVA - машины. Для нормальной работы необходимо JRE версии 1.6.0 либо выше.

После загрузки возьмите .bin файл (например jre-6u2-linux-i586.bin), скопируйте его в директорию /opt/java (создайте если её нет), перейдите в неё, дайте права на исполнение файла и запустите.

Программа проинсталлируется в текущий каталог, создав подкаталог, например jre1.6.0_02. Путь /opt/java/jre1.6.0_02 является JAVA_HOME - путём к JAVA машине.

Для более удобного обновления JAVA в дальнейшем рекомендуем перейти в папку /opt/java и создать символическую ссылку /opt/java/jre.

ln -s jre1.6.0_02 jre

И использовать во всех скриптах JAVA_HOME=/opt/java/jre

Замечание

Вместо JRE вы можете использовать JDK (Java-машина + набор утилит для разработки). В случае возникновения проблем с серверными приложениями JDK предоставляет набор инструментов для отладки и локализации проблемы.

4) Извлеките из архива BGBillingServer_X.X_Y.zip файл dump.sql и BGBillingServer (X.X - номер версии, Y - билда)

5) Запустите

/usr/bin/mysql --default-character-set=cp1251 < dump.sql

для создания базы данных.

6) Скопируйте извлечённую папку BGBillingServer на в папку /usr/local

7) Откройте файл /usr/local/BGBillingServer/data/data.properties и произведите настройку подключения к БД:

db.driver=com.mysql.jdbc.Driver
db.url=jdbc:mysql://127.0.0.1/bgbilling?useUnicode=true&characterEncoding=Cp1251&allowUrlInLocalInfile=true&zeroDateTimeBehavior=convertToNull&jdbcCompliantTruncation=false
db.user=bill
db.pswd=bgbilling

Если база данных MySQL и сервер биллинга стоят на одной машине, то ничего менять не надо. В противном случае вместо 127.0.0.1 укажите IP адрес машины с БД. Параметры db.user и db.pswd определяют имя пользователя и пароль под которыми сервер биллинга будет подключаться к базе данных. Пользователь bill с паролем bgbilling создаётся при начальном создании БД (скрипт dump.sql).

Не пытайтесь в этом месте поменять пароль для подключения к серверу биллинга, он меняется через клиента (меню Сервис=>Администрирование=>Пользователи).

8) С помощью команды export установите переменную JAVA_HOME как путь к JAVA, или же укажите его в начале файлов server.sh, scheduler.sh, bg_installer.sh, data_loader.sh:

cd ${0%${0##*/}}.

JAVA_HOME=/opt/java/jre

Также проверьте все *.sh файлы на наличие символов ^M и удалите их если есть. Если в системе установлена утилита dos2unix, можно воспользоваться ей:

dos2unix *.sh

Запустите скрипт prepare_for_linux.sh или же установите права на исполнение для всех BASH скриптов в каталоге BGBillingServer:

chmod 744 *.sh

9) Создайте службу сервера. Для этого откройте скопируйте скрипты из BGBillingServer/script в /etc/rc.d/init.d

Скрипты запуска также нужно очистить при необходимости от символов ^M, дать права на выполнение и добавить переменную JAVA_HOME (см. выше). Если переменная JAVA_HOME не установлена можно указать ее в скрипте bgcommonrc:

export JAVA_HOME=/opt/java/jre

10) Для того чтобы ваш сервер запускался автоматически выполните команду runlevel, чтобы узнать уровень запуска.

[root@bill-2 init.d]# runlevel
N 3

Перейдите в папку /etc/rc.d/rcN.d (N - ваш уровень запуска, 3 в этом примере) где выполните команду.

ln -s /etc/rc.d/init.d/bgbilling S99bgbilling

11) Аналогично создайте ссылки на bgscheduler и bgdataloader в папке ранлевела. В дальнейшем можете создавать аналогичные скрипты запуска для радиусов, коллекторов и другого сопутствующего биллингу ПО.

12) Теперь вы можете запустить сервер биллинга выполнив

/sbin/service bgbilling start

При успешном запуске в папке log биллинга должны появится server.log и server.out. В первом должно быть примерно следующее:

INFO   13.07.2005 19:42:42  Starting BGBillingServer..
INFO   13.07.2005 19:42:42  HTTP port: 8080
INFO   13.07.2005 19:42:42  Browsing installed modules..
INFO   13.07.2005 19:42:42  dialup v.3.5
INFO   13.07.2005 19:42:42  email v.3.5
...
INFO   13.07.2005 19:42:42  Starting listen admin port 2005

Для запуска планировщика и загрузчика логов используйте команды.

/sbin/service bgscheduler start
/sbin/service bgdataloader start

13) Проследите, чтобы для пользователей, под которыми запускаются сервер биллинга и другие приложение было установлено достаточное количество разрешённое количество процессов и открытых файлов. Список текущих ограничений можно вывести с помощью команды ulimit.

[root@shamil etc]# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 32755
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 32755
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Следует постоянно мониторить текущее число процессов и открытых файлов и при необходимости увеличивать значения.

5. Установка сервера биллинга на OS Windows

Внимание

Следует учитывать, что ОС семейства Windows не являются оптимальными для запуска серверных приложений. Их применение снижает производительность дисковой подсистемы и оптимальность использования ресурсов аппаратуры. Кроме того, операционные системы данной серии менее гибко управляемы. Для запуска высоко нагруженных биллинговых систем используйте ОС *NIX семейств. Ещё одним негативным фактором использования Windows является усложнение предоставления тех. поддержки вследствии отсутствия полноценного shell доступа.

ОС семейства Windows НЕ РЕКОМЕНДУЮТСЯ разработчиками BGBilling для установки серверной части программы, однако хорошо подходят для запуска клиентского приложения.

Для простоты приведён пример установки биллинга на диск C: OS Windows 2K(2003) либо XP. Если вы хотите установить систему на другой диск, поменяйте пути везде где необходимо их указать.

1) Установите MySQL Server и клиента версии 5.0 либо новее на диск С:\ в папку C:\MySQL. Вы можете загрузить нужную версию на нашем сайте bgbilling.ru. Переместите конфигурационный файл C:\MySQL\my.ini на диск на С:\ и скорректируйте следующую опцию (если её нет - добавьте в соответствующие секцию конфигурации после тега [mysqld]):

Замечание

Перемещение файла конфигурации необходимо, т.к. консольный клиент mysql ищет файл конфигурации с указанием кодировок на диске C:

[mysqld] 
max_allowed_packet=50M
max_connections=1000

Это позволит передавать большие пакеты между сервером BGBilling и SQL. Если вы это не сделаете, вы не сможете ставить модули. Вторая опция увеличивает количество разрешённых одновременных подключений к MySQL серверу. Каждое приложение биллинга ведёт пул соединений с базой данных, из которого по мере надобности получают соединения потоки приложения.

Скорректируйте следующую опцию (если опции нет, добавьте её после соответствующего тега [mysqld_safe]):

[mysqld_safe]
open-files-limit=32000 

Опция увеличивает количество разрешённых одновременно для открытия файлов.

Внимание

Внимательно проверяйте по документации все устанавливаемые опции в my.cnf, запрещается установка в параметре sql-mode режимов STRICT_TRANS_TABLES и STRICT_ALL_TABLES, это приведёт к неработоспособности некоторых компонентов биллинговой системы.

Запрещается установка опции skip-networking, т.к. Java приложение подключается к серверу с использованием TCP протокола, а не через файловый сокет.

2) Запустите службу MySQL через Пуск=>Настройка=>Панель управления=>Администрирование=>Службы и запустите её.

3) Установите (если нет) JRE (JAVA машина), последнюю версию можно найти по адресу http://java.sun.com/j2se, либо вы можете загрузить её с нашего сайта. JAVA - язык на котором написан биллинг является интерпретируемым и запускается с помощью специальной программы JAVA - машины. Для нормальной работы необходимо JRE версии 1.6.0 либо выше.

Установка производится мастером, смените каталог установки на не содержащий пробелы, выбрав опцию Change destination folder в начале установки.

Замечание

Вместо JRE вы можете использовать JDK (Java-машина + набор утилит для разработки). В случае возникновения проблем с серверными приложениями JDK предоставляет набор инструментов для отладки и локализации проблемы.

4) Установите переменную окружения JAVA_HOME - путь к JRE. Для установки переменных окружения в Windows нажмите правой клавишей мышки по ярлыку Мой компьютер затем выберите Свойства=>Дополнительно=>Переменные среды.

В нижнем окошке (Системные переменные) нажмите Создать и введёте данные как показано на рисунке ваш путь к JAVA (каталог, выбранный вами для установки).

5) Аналогично скорректируйте переменную окружения PATH, добавив в конце путь к каталогу bin JAVA машины, например ;E:\j2sdk1.5.0\bin.

6) Извлеките из архива BGBillingServer_X.X.zip файл dump.sql и BGBillingServer (X.X - номер версии)

7) Запустите

C:\mysql\bin\mysql.exe -uroot --default-character-set=cp1251 < dump.sql

для создания базы данных.

8) Скопируйте излеченную папку BGBillingServer на диск C:

9) Установите переменную окружения BGBILLING_SERVER_DIR=C:\BGBillingServer.

После этого необходимо перезагрузить компьютер.

10) Откройте файл C:\BGBillingServer\data\data.properties и произведите настройку подключения к БД:

db.driver=com.mysql.jdbc.Driver
db.url=jdbc:mysql://127.0.0.1/bgbilling?useUnicode=true&characterEncoding=Cp1251&allowUrlInLocalInfile=true&zeroDateTimeBehavior=convertToNull&jdbcCompliantTruncation=false
db.user=bill
db.pswd=bgbilling

Если база данных MySQL и сервер биллинга стоят на одной машине, то ничего менять не надо. В противном случае вместо 127.0.0.1 укажите IP адрес машины с БД. Параметры db.user и db.pswd определяют имя пользователя и пароль под которыми сервер биллинга будет подключаться к базе данных. Пользователь bill с паролем bgbilling создаётся при начальном создании БД (скрипт dump.sql).

Не пытайтесь в этом месте поменять пароль для подключения к серверу биллинга, он меняется через клиента (меню Сервис=>Администрирование=>Пользователи).

11) Проинсталируйте службу сервера. Для этого перейдите в папка C:\BGBillingServer и запустите server_install.bat.

12) Зайдите в управление службами и запустите службу BGBillingServer.

13) При успешном запуске в папке log биллинга должны появится server.log.

6. Логирование

По умолчанию логи серверов сохраняются в папке log приложения. В качестве подсистемы логирования используется библиотека log4j. Конфигурирование логирования заключается в правке файла data/log4j.xml (log4j-radius.xml - для радиус сервера, log4j-collector.xml - для коллектора). Это xml файл определенной структуры.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j='http://jakarta.apache.org/log4j/'>

 <appender name="APPLICATION" class="org.apache.log4j.RollingFileAppender">
  <param name="File" value="${log.dir.path}${app.id}.log" />
  <param name="MaxFileSize" value="100MB" />
  <param name="MaxBackupIndex" value="2" />
  <param name="Append" value="false" />

  <layout class="org.apache.log4j.PatternLayout">
   <param name="ConversionPattern" value="%d{MM-dd/HH:mm:ss} %5p [%t] %c{1} - %m%n" />
  </layout>

  <filter class="ru.bitel.common.logging.Log4JMDCFilter">
   <param name="key" value="nestedContext" />
   <param name="value" value="${app.id}" />
  </filter>
 </appender>

 <appender name="ASYNC" class="ru.bitel.common.logging.Log4jAsyncAppender">
  <appender-ref ref="APPLICATION"/>
 </appender>

 <root>
  <priority value="INFO" />
  <appender-ref ref="ASYNC" />
 </root>

</log4j:configuration>

Логирование в системе основано на категориях и контекстах. Разные контексты (server/script или collector/processor/loader) разнесены по разным аппендерам. Аппендер - это куда и как добавляется запись лога - т.е., например в файл server.log такого вида:

server 04-06/12:04:49  INFO [main] DefaultServerSetup - Init DB connection pools
server 04-06/12:04:49  INFO [main] DefaultServerSetup - Init trash pools..
server 04-06/12:04:49  INFO [main] DefaultServerSetup - Init trash pool trash_1
server 04-06/12:04:49  INFO [main] Server - Starting BGBillingServer..
server 04-06/12:04:49  INFO [main] Server - HTTP port: 6565
server 04-06/12:04:49  INFO [main] Server - Starting HTTP connector..
server 04-06/12:04:49  INFO [main] Server - HTTPS port: -1

root - это главная категория, по умолчанию priority/@value='INFO', т.е. все логирование в режиме info. Чтобы переключить логирование в режим debug, необходимо указать здесь 'DEBUG'. Также в каждом аппендере можно указать фильтр по приоритету. Например, в root указать DEBUG, а в аппендере APPLICATION добавить указанную ниже ветку, чтобы логирование для всех контекстов, кроме APPLICATION было в режиме DEBUG.

<param name="Threshold" value="ERROR" />

7. Установка и первый запуск клиента биллинга

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

1) Загрузите клиент биллинга BGBillingClient_X.X_Y.zip (X.X - номер версии, Y - билда)и распакуйте его в произвольное место. На машине, где установлен клиент должна стоять JAVA машина (если клиент устанавливается на другой от сервера машине, посмотрите инструкцию по установке JRE выше, в главе о установке сервера под нужную ОС).

2) Если установка производится под ОС LINUX проверьте все *.sh файлы на наличие символов ^M и удалите их если есть. Если в системе установлена утилита dos2unix, можно воспользоваться ей:

dos2unix *.sh

Дайте права исполнения на все .sh файлы в каталоге BGBillingClient, пропишите переменную JAVA_HOME в начале .sh скриптов:

cd ${0%${0##*/}}.

JAVA_HOME=/opt/java/jre

3) В каталоге BGBillingClient найдите файл client.properties.

db.server.0.title=MyBilling
db.server.0.url=http://127.0.0.1:8080/bgbilling/executer
db.server.0.proxy.host=
db.server.0.proxy.port=

В случае, если клиент установлен на одну с сервером машину, ничего менять не надо. Если необходимо подключиться к серверу с другого рабочего места укажите вместо 127.0.0.1 адрес машины, где установлен сервер BGBilling и, при необходимости, хост и порт прокси, если подключение идёт не напрямую.

Аналогичным образом вы можете добавить ещё один сервер BGBilling, доступный для подключения. Нужно лишь добавить аналогичный набор записей ниже, исправив server.0 на следующий номер. Например:

db.server.1.title=NextBilling
db.server.1.url=http://www.bill.com:8080/bgbilling/executer
db.server.1.proxy.host=my.proxy.com
db.server.1.proxy.port=3128

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

4) Запустите клиента с помощью пакетного файла bgbilling_w9x.bat для Win98/ME, bgbilling_w2k.bat для Windows2000/XP/2003, bgbilling.sh для LINUX. Если клиент не стартует, либо после старта обнаруживаются проблемы, запустите DEBUG версию bgbilling_debug.bat либо bgbilling_debug.sh, при этом в каталоге BGBillingClient должен появится файл log, который вы можете передать разработчикам при разборе проблемы.

5) Если клиент стартовал, вы увидите окошко авторизации (см. рисунок).

В списке подключений необходимо выбрать требуемую базу.

При установке базы биллинга в ней создаётся единственный пользователь admin c паролем admin. После первого входа желательно поменять пароль в целях безопасности.

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

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

Созданные таким методом подключения, так же как и сохранённые логины и пароли запоминаются в файле HOME_DIR/.bgbilling/config, где HOME_DIR - домашний каталог пользователя.

Если ошибок авторизации не выдаётся, а просто происходит очистка окошек ввода логина и пароля то, скорее всего проблема в сервере.

Проверьте лог C:\BGBilling\log\server.out на наличие ошибок (Exception). Вероятнее всего, сервер не может соединиться с базой данных. Попробуйте взять логин и пароль из файла data\data.properties и с их помощью соединиться с БД. Для этого используйте консольный клиент mysql, расположенный в директории C:\mysql\bin. Наберите в командной строке

mysql -ubill -pbgbilling bgbilling

Если соединение не прошло, проверьте, запущен ли сервер MySQL.

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

Если после логина требуется сменить текущий сервер биллинга (в случае если у вас их несколько, см. выше как можно их добавлять) вы можете воспользоваться выпадающим списком расположенным справа от надписи БД: на панели инструментов. При первом входе на новый сервер биллинга будет запрошен логин и пароль, при последующих переключениях авторизация не требуется. Открытые вкладки клиента при переключении на другой сервер и возврате на исходный сохраняются.

8. Описание интерфейса клиента биллинга

Так выглядит основное рабочее окно программы BGBillingClient (приведена только верхняя область окна):

Интерфейс клиента биллинга построен на вкладках, открывающихся в основном окне. Это позволяет оператору держать одновременно открытыми несколько договоров/редакторов/справочников и т.п. Во вкладках открываются договоры, редакторы справочников, редакторы свойств модулей и пр.

Для закрытия вкладки (вкладок) можно нажать крестик на вкладке в нижней области окна, либо вызвать пункт меню Договор=>Закрыть вкладку (Закрыть вкладки). Пункты меню продублированы на панели инструментов кнопками Закрыть вкладку (Закрыть вкладки).

Панель инструментов расположена ниже меню. Первые шесть кнопок дублируют часто используемые пункты меню Договор. Расположенные далее кнопки Новый элемент, Редактировать, Удалить элемент, Обновить действуют на текущую вкладку биллинга и являются универсальными. В контексте текущей вкладки они позволяют:

  • создать новую сущность на выбранной вкладке;

  • редактировать существующую сущность;

  • удалить выбранную сущность;

  • обновить информацию на вкладке данными с сервера биллинга.

Далее идёт выпадающий список подключений к серверу(БД). Если сменить текущий сервер , то вызовется снова диалог авторизации с вводом логина/пароля к серверу. Переключение между серверами, на которые уже произошла авторизация, происходит без вызова диалога. Если такой сервер выбрали в диалоге авторизации(диалог вызвали для не авторизованного сервера, а потом сменили на уже авторизованный), то правка логина пароля недоступна, в диалоге при этом появляется кнопка "Выйти" - она разрывает соединение с сервером и он становится не авторизованным.

При смене сервера запоминаются все текущие вкладки и активная вкладка , они восстанавливаются, если вернуться к старому серверу. Далее на панели идёт вывод текущего логина и кнопка разрыва соединения с текущим сервером биллинга.

Меню и панель инструментов могут быть настроены редактированием файла BGBillingServer/data/menu.xml и toolbar.xml. Установленные плагины и модули могут дополнять содержимое меню и панели инструментов новыми пунктами.

Пример 1.1. Пример работы с вкладками

Выберите пункт меню Справочники=>Другие. В открывшемся справочнике типов платежей выберите корневой узел, нажмите Новый элемент в панели инструментов. В появившемся редакторе введите название типа платежа, установите галочку Элемент группы и нажмите OK.

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

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

Во всех тестовых полях работают горячие клавиши копировать/вырезать/вставить - Ctrl+C/Ctrl+X/Ctrl+V, что позволяет использовать в работе с клиентом буфер обмена. Для копирования в буфер обмена информации, содержащейся в таблице, выберите требуемое количество строк таблицы мышью нажимая кнопки Shift, Ctrl либо Ctrl+A для выбора всех строк и нажмите Ctrl+C. Пример таблицы с выделением изображён на рисунке сверху.

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

Кнопка ОК устанавливает выбранную дату. Х - оставляет существующее значение даты в поле ввода (отмена). Стрелки влево и вправо позволяют проматывать года и месяцы, стрелки продублированы кнопками с установленными значениями годов. Текущий год и месяц выделены жирным шрифтом.

Ctrl+стрелка вверх/Ctrl+стрелка вниз изменяют год, Ctrl+стрелка влево/Ctrl+стрелка вправо - месяц.

Пример 1.2. Пример работы с календарём

Для тренировки вы можете нажать меню Договор=>Новый договор либо кнопку Новый договор на панели инструментов. Нажатие поля ввода даты вызывает календарь. При вновь созданной базе биллинга список шаблонов будет пуст.

При наборе с клавиатуре на выделенном выпадающем списке (ComboBox) производится автоматический поиск первой совпадающей по подстроке записи. При этом выше отображается набранный отрывок, а при навигации кнопками вверх/вниз выделение переходит по совпадающим полям. Esc - обнуляет отрывок поиска.

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

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

Вывод таблицы и списков данных с большим количеством пунктов организован в биллинге постранично. Для перемотки страниц и настройки количества записей на странице используется такой элемент управления:

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

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

Левая область задаёт размер страницы. Нажатием кнопки можно установить предопределённое значение. Для установки пользовательского значения нажмите кнопку SW, далее набрать на правой клавиатуре нужное значение и нажать OK.

Сохранённые настройки записываются в файл $USER_HOME/.bgbilling/config.

В элементе интерфейса выбор договора:

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

В клиентском приложении есть возможность отключить фоновый рисунок (например, при использовании терминал сервера), добавьте в BGBillingClient/client.properties

bg.enable=0

8.1. Конфигурации

Очень большое количество редко меняющихся настроек поведения системы вынесено в конфигурации. Конфигурация - это текстовый блок, состоящих из записей вида: <ключ>=<значение>. На одной строке может быть только одна такая запись, символ # в начале строки означает комментарий. Порядок записей в тексте значения не имеет. При необходимости указания порядка в ключе вводятся дополнительные числовые индексы.

Конфигурации вводятся либо в текстовых properties файлах (опции подключения к БД, базовые настройки) либо в редакторах конфигурации в клиенте биллинга, сохраняясь в базе данных. Ядро биллинга, каждый экземпляр модуля биллинга, плагины обладают различными конфигурациями, конфигурация ядра доступна в меню Сервис=>Настройки.

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

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

@macroName=<значение>

Здесь <значение> - произвольная строка, которая будет просто подставляться в место, где будет вызвано макроопределение. Синтаксис вызова макроопределения следующий:

#определяем макрос howYou
@howYou=how you

#используем макросы
some.kind.of.config.record=Thats {@howYou} should {@useMacro}

#определяем макрос useMacro
@useMacro=use macro!

Т.е. при такой конфигурации при взятии значения some.kind.of.config.record получаем в результате строку "Thats how you should use macro!".

В большинстве случаях при смене конфигурации необходим перезапуск сервера, использующего данную конфигурацию. Например, при установке опций для работы RADIUS сервера в конфигурации привязанного модуля DialUP необходим перезапуск RADIUS сервера.

9. Настройка сервера биллинга

После установки сервера и клиента сервер должен быть настроен, для этого откройте в клиент пункт меню Сервис=>Настройка. В появившейся вкладке в нижней части найдите и нажмите кнопку Создать для создания новой конфигурации сервера.

Если в дальнейшем где-то упоминается Конфигурация сервера, то следует знать, что речь идёт именно об этой конфигурации. В биллинге много различных редакторов конфигурации, ориентироваться в них на стадии освоения системы может быть затруднительно.

#путь, по которому сервер будет искать XSLT файлы
server.xslt=http://127.0.0.1:8080/bgbilling/xsl/
#кэширование XSLT шаблонов памяти, 1 - включить 
#необходимо отключать опцию на момент модификации любых XSLT шаблонов
xslt.cache=0
#XSLT шаблон для печати баланса
contract.xslt=contract_balance_print.xsl
#настройки почты
mail.smtp.host=bill.ru
mail.from.email=bill@bill.ru
mail.from.name=BGBilling Server
mail.to.email=bill@bill.ru
mail.to.name=bill@bill.ru
mail.encoding=windows-1251
#параметры SMTP авторизации
#mail.smtp.user=
#mail.smtp.pswd=
#проверка уникальности адреса договора при вводе - 1, 0 - не проверять
address.unique.check=1
#формат адреса (доступен также параметр ${comment} - комментарий параметра)
addrs.format=(${index})(, ${city})(, ${area})(, ${quarter})(, ${street})(, д. ${house})(${frac})(, кв. ${flat})( ${room})(, ${pod} под.)(, ${floor} эт.)
#разрешение создавать дома в редакторе адреса параметров договоров и объектов
#address.create=1
#заголовок и адрес к шаблону карточки (доступны в свойствах договора)
contractcard.1=card_inet.xsl:Карта регистрации
#вывод в server.log XML возвращаемых клиенту в режиме DEBUG - 1 
server.response.debug=0
# Заголовок HTTP пакета в котором передаётся IP адрес клиента, если параметр не указан или не передан, то используется request.getRemoteAddr()
# нужен при проксировании запросов с помощью nginx
header.name.remote.addr=X-Real-IP
#максимальный размер запроса к серверу, запросы большего размера обрезаются, что может привести к некорректной работе сервера
#признак того, что нужно увеличить - ошибка вида "Модуль null не найден!"
max.post.size=10000000
#разрешение платежей и расходов будущим числом
allow.future.payment=0
allow.future.charge=0
#разрешение платежей и расходов для закрытых договоров
allow.closed.payment=0
allow.closed.charge=0
#путь к временному каталогу, используется обработчиком логов для загрузки логов по FTP и сервером биллинга для хранения промежуточных файлов
#если не указан, то используется каталог BGBillingServer/tmp 
#temp.dir.path=
#что выводить в поле "сальдо" монитора статуса, 1 - сальдо, 2 - исх. остаток
contract.status.monitor.saldo.show.mode=1
#проверка закрытого периода при операциях, 1 - включить
closed.date.enabled=1
#
#----------------------------------------
# опции планировщика заданий 
#----------------------------------------
#количество одновременных потоков для выполнения периодических заданий по расписанию
scheduler.periodic.thread.count=5
#количество одновременных потоков для выполнения асинхронных задач (переобсчёты)
scheduler.nonperiodic.thread.count=5
#
#----------------------------------------
# опции BGBS 
#----------------------------------------
#логирование вызовов функций BGBS (1-логировать, 0-нет)
#логируются выводы print, error и ошибки, после установки перезапустить BGBillingServer
log.function.process=1
#через запятую E-Mail адреса, на которые высылать сообщения об исключительных ситуациях при выполнении скриптов
#script.error.mail=
#
#----------------------------------------
# опции BGSecure 
#----------------------------------------
#проверка прав, 0 - не проверять
bgsecure.check=1
#логирование действий в журнале событий, 0 - не логировать
bgsecure.log=1
#
#----------------------------------------
# система алармов - экстренных оповещений
#----------------------------------------
#на какой адрес высылать оповещения, указать обязательно!
alarm.mail=
#
#----------------------------------------
# опции Web интерфейса клиента 
#----------------------------------------
#режим выдачи страниц: xml либо html - сборка страниц браузером либо на сервере
web.mode=html
#web.admin.password=21232F297A57A5A743894A0E4A801FC3
#в режиме xml по этому пути браузер будет получать xls
#адрес должен быть доступен отовсюду
web.xslt=http://127.0.0.1:8080/bgbilling/xsl/
#в режиме xml при обращении через порт https по этому пути браузер будет получать xls
#адрес должен быть доступен отовсюду
web.xslt.https=https://127.0.0.1:8443/bgbilling/xsl/
# режим авторизации для доступа к Web статистике код модуля:режим;код модуля 1:режим 
# модуль 0 - ядро
# режим 0 - не разрешена, 1 - FORM
web.auth.modes=0:1
#добавление в XML на странице статистике детальной информации по договору - 1
web.add.contract=0
#страница куда пересылать при выходе с Web статистики
web.exit.redirect=about:blank
#максимально количество запросов для договора на сервер статистики в день, 0 - не ограничено
web.max.day.request.count=0
#логирование web-запросов пользователя (web-интерфейс)
webquery.log=0
#длина пароля договора для доступа к статистике
password.length.min=5
password.length.max=10
#длина автоматически генерируемого пароля
password.length.auto=6
#допустимые в пароле символы
password.chars=1234567890
#
#настройка страниц ошибок сервера по ошибкам (можно указвать различные коды ошибок)
server.error.404=/error/error404.html
server.error.403=/error/error403.html
#----------------------------------------
# защита от подбора пароля Web статистики 
#----------------------------------------
#максимальное количество неудачных попыток авторизации подряд
logon.counter.max=20
#базовый интервал времени в секундах между неудачными попытками авторизации
logon.timeout.period=0
#время блокировки в секундах после исчерпания количества попыток авторизации
logon.timeout.lock=21600
#размер кэша паролей
logon.lock.cache.size=100
#время устаревания записи в кэше паролей в секундах
logon.lock.cache.expired=600
#алгоритм увеличения времени между попытками (+ или ^)
logon.timeout.action=+
#
#-----------------------------------------
# восстановление пароля Web статистики
#-----------------------------------------
# код текстового параметра, содержащий E-Mail на который будет высылаться письмо по восстановлению пароля
contract.password.forgot.email.param.id=<числовой код параметра>
# в течении сколько часов после высылки письма можно войти на статистику по ссылке в письме
contract.password.forgot.expire.hour=24
# ссылка на страницу статистики в письме с восстановлением пароля
contract.password.forgot.link=http://localhost:8080/bgbilling/webexecuter?action=ChangePassword&mid=contract
# тема письма
contract.password.forgot.email.subject=Постановление пароля
# текст письма
contract.password.forgot.email.body=Для восстановления пароля к серверу статистики по договору {contract} - перейдите по ссылке ниже (в течении {hour} часов) и смените пароль.
# набор символов одноразового пароля
contract.password.forgot.char.array=1234567890QWERTYUIOPLKJHGFDSAZXCVBNMqwertyuioplkjhgfdsazxcvbnm
#
#-----------------------------------------
# настройки интерфейса
#-----------------------------------------
# задаём порядок элементов в дереве договора клиента
client.gui.contract.tree.order=parameters objects hierarchy status limit mode balance tariff modules groups web tariffGroup script addAction memo
# какие лимиты предлагаются на выбор в договоре 
client.gui.contract.limit.values==-2000;=-500;=-300;=-150;=-50;=-30;=-10;=0;-5/1;-50/1;-100/1;-15/3;-50/3;-100/3
# какие лимиты предлагаются на выбор в шаблоне договора 
client.gui.pattern.limit.values=-2000;-500;-300;-150;-100;-50;-10;0;5;30;100;15;50;100
# в какие статусы можно переводить договора 0 - подключить, 2 - отключить, 3 - закрыть, 4 - приостановить
# если переменная не указана, разрешено переводить во все предусмотренные статусы
#client.gui.allow.to.change.status=0,2,3,4

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

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

В поле Вид и поведение вы можете изменить текущую тему оформления клиента.

Внимание

Установка темы оформления отличной от Metal может привести к проблемам с отрисовкой. Смена темы оформления производится пользователем на его страх и риск, нарушение в отрисовке клиента не считается ошибкой ПО.

Рассмотрим более подробно настройку почтовый подсистемы и системы оповещения.

9.1. Настройка почтовой подсистемы

Обязательно настроить опции почты:

#настройки почты
mail.smtp.host=bill.ru
mail.from.email=bill@bill.ru
mail.from.name=BGBilling Server
mail.to.email=bill@bill.ru
mail.to.name=bill@bill.ru
mail.encoding=windows-1251
#включение отладки SMTP обмена в .out лог, 1 - включить, 0 - выключить
#mail.debug=1

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

В mail.smtp.host укажите ваш почтовый сервер, адрес и имя подставляемые в поля ОТ письма (mail.from.email, mail.from.name). Также укажите адрес и имя администратора (mail.to.email, mail.to.name). В кодировке можете указать windows-1251 либо KOI8-R на ваш выбор.

Если SMTP сервер требует авторизации логин и пароль указываются в параметрах mail.smtp.user, mail.smtp.pswd.

Для поддержки отправки почты через SSL соединение (например, smtp.gmail.com) добавьте следующие настройки (SMTP порт 465).

mail.properties.mail.smtp.socketFactory.class=javax.net.ssl.SSLSocketFactory
mail.properties.mail.smtp.socketFactory.fallback=false
mail.properties.mail.smtp.quitwait=false
mail.properties.mail.smtp.port=465
mail.properties.mail.smtp.socketFactory.port=465

9.2. Настройка системы оповещения

В опции alarm.mail укажите почтовый ящик для отправки экстренных оповещений о нештатной ситуации в биллинге (потеря связи с БД, недостаток памяти и т.п.). При наступлении нештатной ситуации приложение биллинга вышлет письмо со следующей темой: [<имя приложения>] <название ошибки>, где:

<имя приложения> - название процесса биллинга, уникально для каждого процесса биллинга, может быть переопределено передачей ключа -Dapp.name=<новое имя> в скрипте старта процесса (.sh, .bat);
<название ошибки> - краткое описание ошибки.

Например: "[BGBillingServer] Достигнут лимит одновременных подключений к Master базе". Если, например, у вас установлено несколько серверов биллинга и необходимо получение алармов на один ящик, то вы можете скорректировать скрипт server.sh следующим образом (имя приложения изменено на BGBillingServer2):

if [ "$1" = "start" ]; then
   #starting
   nohup  ${JAVA_HOME}/bin/java -Dapp.name=BGBillingServer2 ....
else

Аналогично может быть скорректировано имя любого приложения. В теле письма содержится идентификатор проблемы, время регистрации и краткое описание, например:

ID события: db.master.connection.limit.over
Время регистрации события: 10.03.2009 16:12:01

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

Connections pool to Master status Idle: 0; Active: 4; maxActive: 4; maxIdle: 4

9.3. Закрытый период

В меню настройки сервера (пункт меню Сервис=>Настройка) также существует возможность указания закрытого периода для сущностей ядра и модулей системы. Проверка закрытого периода работает только при установленной опции конфигурации сервера биллинга closed.date.enabled=1.

Назначение закрытого периода с в том, чтобы установить невозможность изменения (удаления) какой-либо сущности ядра или модуля (например, платежа или абонентской платы), период действия или дата добавления которой пересекается с закрытым периодом. Для закрытого периода устанавливается его правая граница. Например, если дата закрытого периода устанавливается в 01.01.2009, то невозможны любые измнения сущностей, датированных ранее 1 января 2009 года.

10. Модули

Модули необходимы для расширения функциональности системы в основном для тарификации различных услуг. В этой главе полагается, что ваш сервер биллинга установлен в C:\BGBillingServer на ОС Windows. Если вы установили его в другое место, используйте ваши пути.

Установка модуля производится инсталлятором, который расположен в каталоге BGBillingServer. Для запуска положите zip файл модуля рядом с инсталлятором и запустите

# LINUX
./bg_installer.sh {имя файла с архивом}
# WIN
bg_installer.bat {имя файла с архивом}

Если инсталляция прошла успешно, будет выведено сообщение (например):

Module dialup version 3.5 was successful installed!

Для установления обновления того же модуля (версии пакетов совпадают) необходимо выполнить:

#LINUX
./bg_installer.sh {имя файла с архивом}!
#WIN
bg_installer.bat {имя файла с архивом}!

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

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

При подключении установите в окошке логина галочку загружать обновления с этого сервера. Либо произведите вход на сервер а после вызовите пункт меню Сервис=>Принудительное обновление клиента.

Если все прошло успешно, будет выведено окошко с сообщением.

Данное сообщение означает, что код клиентской части, необходимый для работы с модулем, скопирован с сервера. Иначе говоря, уже есть код модуля, но нет обособленной единицы (экземпляра) модуля со своими данными. Для того чтобы её создать, следует запустить Модули=>Редактор модулей и услуг.

Слева расположена таблица созданных экземпляров модулей: код экземпляра, его произвольное название и базовый модуль. Базовый модуль - ни что иное, как программный код, осуществляющий поддержку функционала модуля. А сам экземпляр - это совокупность данных в базе с уникальным кодом.

От одного базового модуля можно породить неограниченное количество экземпляров модулей. Например, можно сделать два экземпляра от базового модуля DialUp (Коммутируемые соединения): DialUp и VPN.

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

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

Для создания нового экземпляра модуля нажмите кнопку Новый элемент на общей панели инструментов, для редактирования - кнопка Редактировать либо двойной клик по строке таблицы. Изменить можно только название экземпляра.

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

Внимание

Удаляя модуль, вы удалите и все связанные с ним данные.

Справа расположены услуги, существующие в модуле.

Услуга - это способ разделения наработки а так же возможность активации тех или иных сервисов в некоторых модуля путём добавления Разрешённых услуг договора. Каждой услуге также соответствует уникальный код и он также часто используется в конфигурациях как Код услуги.

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

После создания экземпляра модуля созданные экземпляры должны появиться в меню Модули.

При открытии соответствующего модулю пункта подменю открывается вкладка с настройками модуля. Для каждого модуля набор вкладок разный. Однако в большинстве модулей присутствует вкладка Конфигурация модуля, её редактирование аналогично Конфигурации сервера биллинга.

Здесь задаются настройки специфичные для данного модуля и его агентов (например, RADIUS сервера модуля DialUp). Конфигурация сохраняется в БД и поэтому доступна всем серверным компонентам биллинговой системы.

Существуют три точки "выхода" модуля в графическом интерфейсе клиента:

1. Пункт меню Модули, описан выше

2. Договор абонента, узел дерева Модули и вкладка Отчёты

Для примера создадим договор (New Contract) с шаблоном по-умолчанию (более подробно о договорах, их свойствах и шаблонах см. далее). Для этого нажмём кнопку Новый договор.. на панели инструментов (самая левая кнопка), далее выберем шаблон По умолчанию и текущую дату.

Должен открыться созданный договор New contract.

В дальнейшем, если вы его случайно закроете, вы можете найти его нажав вторую кнопку на панели инструментов Открыть договор.. и нажав в ней кнопку >>>. Более подробно о поиске договоров также написано далее.

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

В результате в дереве появится ветка со свойствами модуля для конкретного договора. При её открытии откроется специфичный для модуля редактор. На снимке экрана это редактор логинов DialUp модуля.

Вкладка Разрешённые услуги присутствует не для всех модулей, её назначение различно и описывается в документации конкретного модуля.

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

Аналогично в договор можно добавить другие модули.

11. Плагины

Установка плагинов не отличается от установки модулей, также используется утилита bg_installer (см. предыдущую секцию документации). После инсталляции плагина перезапустите сервер биллинга и зайдите в клиенте в меню Сервис=>Настройка плагинов.

Для активации плагина необходимо дважды кликнуть по строке таблицы, поставить в редакторе галочку включён и нажать OK.Здесь же вносится конфигурация плагина, конкретные ключи и значения необходимо смотреть в документации конкретного плагина. После активации плагина сервер начинает проверять лицензию на него, в случае отсутствия либо просроченной лицензии плагин необходимо отключить.

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

Например, плагин CRM добавляет пункт меню Сервис=>CRM и вкладку в договоре CRM.

12. Установка обновлений биллинга

По мере обнаружения ошибок в текущей версии программы выпускаются обновления в виде новых билдов (сборок). Каждый новый билд модуля сопровождается комментарием к сделанным исправлениям. Комментарии доступны на странице загрузки продукта. Также ведётся RSS лента обновлений.

Периодически следует сверять текущие установленные билды модулей и плагинов с доступными на сайте. Для получения информации по версиям и билдам компонентов биллинга воспользуйтесь меню Справка=>О программе.

В верхней области отображаются версии и билды клиента и сервера. Обновление клиента и сервера доступны на сайте единым пакетом. Ниже перечислены установленные в системе модули и плагины, их версии и билды. По мере обнаружения новых билдов модулей на сайте загружайте их и устанавливайте с помощью утилиты bg_installer.sh (.bat).

./bg_installer.sh <имя_файла_с_модулем>!

Для LINUX платформы.

bg_installer.bat <имя_файла_с_модулем>!

Для Win платформы.

Обратите внимание на символ ! после имени zip файла с модулем, он информирует инсталлятор о необходимости отключения проверки факта установки модуля данной версии. При установке обновлений следует останавливать процесс сервера биллинга, планировщика и загрузчика логов и запускать их после установки пакетов.

Начиная с версии 4.4 поддерживается автоматическое обновление с FTP сервера ftp://bgbilling.ru. Для обновления системы остановите сервер биллинга, планировщик и загрузчик логов а затем выполните команду:

./bg_installer.sh update

Для LINUX платформы.

bg_installer.bat update

Для Win платформы.

Инсталлятор проверит наличие обновлений и предложит их установить выбрав нажав клавишу y.

[bill@bill-reg BGBillingServer]$ ./bg_installer.sh update
Update starting..
Update from ftp://bgbilling.ru/pub/bgbilling
Server version is 4.4
Changing dir to /pub/bgbilling/4.4
Checking updates for ru.bitel.bgbilling.plugins.crm..
Found update for crm build 50 packet crm_4.4_52.zip updating to build 52
Checking updates for ru.bitel.bgbilling.plugins.documents..
Checking updates for card..
Checking updates for dialup..
Checking updates for email..
Checking updates for ipn..
Checking updates for npay..
Checking updates for reports..
Checking updates for voiceip..
Checking updates for bill..
Checking updates for gorod..
Checking updates for server..
Found update for BGBillingServer build 102 packet update_4.4.zip updating to build 104
Checking updates for client..
Install 2 updates (y/n):

Возможно установить только все обновления сразу.

Внимание

Не забывайте делать резервную копию каталога BGBillingServer при установке обновлений. Обновление перетирает все XSLT шаблоны и многие другие файлы, заменяя их стандартными из пакета.

Если при обновлении была произведена установка пакета update то как минимум нужно восстановить файл style.css со стилями Web статистики.

При обновлении модуля card потребуется восстановление конфигурации дилерского веб интерфейса (файл webroot/id/conf.txt)

При обновлении модуля bill перетираются стандартные шаблоны счетов и фактур bill_pdf.xsl и invoice_pdf.xsl.

Если вы корректировали файлы в каталоге BGBillingServer/actions, восстановите их также.

Для предотвращения перетирания файла вы можете перед его модификацией создать копию с именем <file_name>.orig (например, style.css.orig). При установке пакета инсталлятор будет проверять перед записью каждого файла наличие файла с таким же именем в текущей установке. Если файл существует, но отличается от того, что в пакете, предпринимается попытка найти файл <file_name>.orig .

Если оригинальный файл существует и не отличается от файла из пакета, то он не будет перезаписан, система сообщит: File doesn't changed <filePath>. Если и оригинальный файл не совпадает со вновь предлагаемым, файл будет записан.

Перечень перезаписанных файлов сообщается после завершения процедуры установки либо обновления после фразы REPLACED FILES:. Вы должны вновь внести в данные файлы требуемые корректировки и снова создать .orig копию файла.

Обновление клиента происходит автоматически при последующем подключении к серверу биллинга и установленной опции Загружать обновления с данного сервера.

При выходе новых версий биллинга предоставляется инструкция по переходу на новую версию ПО, далее в пределах версии обновление производится по описанному выше алгоритму.

Начиная с версии 4.6 в системе обновления биллинга работает механизм предотвращения повторного выполнения SQL-запросов обновления базы данных, что значительно ускоряет обновление системы. Выполненные SQL-запросы кэшируются и хранятся в базе данных биллинга. В случае, если по какой-либо причине необходимо повторное выполнение SQL-запросов при обновлении модуля (или ядра), то необходимо запустить bg_installer

./bg_installer.sh killhash <module_id>

для LINUX или

bg_installer.bat killhash <module_id>

для Windows, где <module_ID> - код модуля, для которого необходимо уничтожить кэш SQL-запросов (для ядра = 0; для плагина или модуля в целом - код модуля\плагина из таблицы installed_modules; для конкретного установленного модуля = m<mid>, где <mid> - код модуля из таблицы module, напримoер, m12).

13. Установка лицензии биллинга

Для корректной работы BGBilling необходимо наличии лицензии . Лицензия представляет собой файл lic.properties с набором текстовых строк, который выдаётся при покупке BGBilling. Лицензия включает в себя описание разрешенных к использованию модулей и плагинов, количества договоров и период действия.

Полученную лицензию необходимо поместить в каталог BGBillingServer/data заменив существующий lic.properties, после чего перезапустить сервер биллинга. Загруженный с сайта биллинг содержит тестовую лицензию. Текущую лицензию можно просмотреть в индикаторе лицензии.

Замечание

До 4.5 версии включительно информация о лицензии размещалась в файле data.properties. Для сохранения обратной совместимости, данный файл также просматривается, если не был обнаружен lic.properties.

14. Настройка SSL между сервером и клиентом

По умолчанию обмен между клиентом и сервером биллинга, а также между web браузером клиента и сервером биллинга производится по протоколу HTTP. В дополнение к нему вы можете настроить HTTPS режим соединений, позволяющий безопасно подключаться к серверу биллинга из-за пределов вашей сети клиентом, либо получать безопасный доступ к статистике вашим абонентам.

Замечание

Вы можете пропустить эту главу при первичном знакомстве с биллингом

Для работы по HTTPS требуется серверный сертификат - пара private key и public key, public key обернут сертификатом. Сертификат и private key должны находится в хранилище сертификатов - .keystore.

Работа сертификатов основывается на паре асинхронных ключей. Необходимо создать их:

keytool -keystore .keystore -alias bgbilling -genkey -keyalg RSA -dname "cn=bill.provider.ru, email=email@provider.ru,ou=Provider Billing, o=Provider, c=RU" -validity 1001

Параметр -validity указывает сколько дней будет действителен сертификат.

Утилита попросит ввести пароль для хранилища и пароль для закрытого ключа (private key).

Оба пароля должны совпадать и быть прописаны в конфиге сервера (по умолчанию биллинг пытается использовать значение 'bgbilling'):

keystore.password=bgbilling

cn - common name - имя сервера. Пользователь заходит на https://bill.provider.ru/, сервер возращает сертификат, браузер проверяет имя на совпадение - если не совпадает, то выводится предупреждение.

ou - organization unit, o - organization, c - country

После выполнения утилиты появится файл .keystore, в нем в алиасе bgbilling - закрытый ключ и сертификат. Закрытый ключ нельзя передавать никому.

Просмотреть хранилище можно командой:

keytool -keystore .keystore -list -rfc

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

keytool -keystore .keystore -alias bgbilling -exportcert -file bgbilling.cer

В данный момент хранилище уже готово для работы, но текущий сертификат подписан самим собой, т.е. не подписан доверенным сертификатом - таким образом, когда клиент зайдет на https://bill.provider.ru/ - ему выведется предупреждение, например, "К сертификату нет доверия, так как он является самоподписанным." и предложат уйти с сайта, продолжить работать или добавить сертификат в доверенные и продолжить работать.

Если вы хотите, чтобы браузер сразу доверял сертификату, необходимо его подписать одним из Certification Authority (CA), например VeriSign, Inc. Для этого создаем запрос на подпись сертификата - Certificate Signing Request (CSR).

keytool -keystore .keystore -alias bgbilling -certreq -file bgbilling.csr

Созданный запрос нужно отправить CA, в ответ вы получите серфтикат, подписанный им (или цепь сертификатов).

Сначала необходимо импортировать сертификат CA в доверенные (или верхний из цепи сертификатов, например ROOT), т.к. при импорте ответа проверяется, что ответ подписан доверенным сертификатом.

keytool -keystore .keystore -alias verisign -importcert -file verisign.cer

Далее импортируем ответ, он заменит наш самоподписанный сертификат:

keytool -keystore .keystore -alias bgbilling -importcert -trustcacerts -file response.cer

Более подробную информацию о работе keytool можно получить здесь: http://java.sun.com/javase/6/docs/technotes/tools/windows/keytool.html

Скопируйте файл .keystore в каталог BGBillingServer. В файле data.properties сервера укажите:

port.https=8443

и перезапустите его.

В результате сервер начинает слушать на 2х портах. Не стоит убирать http.port, т.к. сервер должен обращаться к самому себе за некоторыми ресурсами (XSL файлы) по этому протоколу.

При этом клиенты для просмотра Web статистики также могут использовать 2 вида протоколов HTTP и HTTPS. Для обращения через безопасное соединение необходимо набирать https://<IP адрес сервера биллинга>:8443/bgbilling/webexecuter.

Редактируем файл client.properties в клиенте

db.server.0.url=http://127.0.0.1:8080/bgbilling/executer 

меняем на

db.server.0.url=https://bill.provider.ru:8443/bgbilling/executer 

15. Настройка планировщика

Специально для выполнения периодических процессов (снятие абонплат, очистка таблиц) в системе BGBilling предусмотрен планировщик задач, выполняющий какие-либо задачи в заданные интервалы времени.

В UNIX для запуска планировщика используются скрипты scheduler_start.sh, scheduler_stop.sh, scheduler_reload.sh, расположенные в каталоге сервера. Желательно создать скрипт запуска службы планировщика в init.d.

В Windows необходимо запустить скрипт scheduler_install.bat, при этом обязательно должны быть установлены переменные окружения BGBILLING_SERVER_DIR и JAVA_HOME (подробнее про них в инструкции по установке сервера биллинга). После этого можете запускать и останавливать службу BGScheduler через список служб.

Для добавления новой задачи зайдите в Сервис=>Планировщик задач, нажмите кнопку Новый элемент, выберите тип задачи и когда её запускать.

Максимальная частота запуска заданий планировщиком - один раз в минуту. Данная частота устанавливается если во всех полях Время запуска будет поставлена *. Т.е. следует читать как: "любая минута,любой час, любой день месяца...".

Если столь высокая частота не требуется, можно уточнить параметры. Например, запуск задачи один раз месяц можно задать установкой Дни месяца в 1, Часы в 0, Минуты в 10. При необходимости несколько значений временных фильтров можно указывать через запятую.

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

Каждая задача может иметь специфические Параметры запуска, которые должны быть введены в поле Параметры запуска в виде <ключ>=<значение>, каждая пара на новой строке. Параметры к каждой отдельной задаче и рекомендации по частоте её запуска даны далее в руководстве к ядру системы и её модулям.

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

Планировщик автоматически перезагружает список периодических заданий при их редактировании в клиенте биллинга.

Кроме плановых заданий планировщик заданий также исполняет все "тяжёлые" задачи биллинга. Например, начисление абонплат, перерасчёты. Это позволяет более оптимально использовать ОЗУ, выделяя большой объем памяти только планировщику. Также можно разгрузить сервер биллинга, вынося планировщик на отдельную машину. Количество "тяжёлых" задач, стоящих в очереди на обработку также отображается в окне управления планировщиком, в верхней его области.

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

Перенос планировщика на другую машину может быть произведен копированием каталога BGBillingServer на другую машину и перенастройкой data.properties с указанием URL к MySQL БД на другой машине. Если планировщик перенесен на другую машину при каждом обновлении биллинга необходимо копирование папки lib на планировщик и перезапуск его.

16. Стандартные задачи планировщика

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

Восстановление лимитов - возвращение к исходному значению временно изменённых лимитов. Периодичность запуска - 1 раз в день, в 0 часов, 0 минут. Данная задача восстанавливает лимиты после их временного понижения, более подробно о временном понижении лимитов читайте здесь. Задача может быть настроена сразу, параметров не содержит. Также задача восстанавливает лимиты договоров после просроченных "обещанных платежей" - временных понижений лимитов абонентами провайдера.

Удаление старых договоров - очистка базы биллинга от ненужных договоров с помещением их в архив. Периодичность запуска - любая, оптимально - несколько раз в сутки. Данная задача выполняет чистку базы от старых договоров по правилам, указанным в Менеджере договоров. О настройке Менеджера договоров и параметрах запуска задачи описано далее.

Пользовательские рассылки - рассылка клиентам информации о балансе, сессиях и т.п. Подробнее можете почитать здесь. Периодичность запуска - 1 раз в день. Оптимально запускать задачу ночью или рано утром, в период минимальной загрузки сервера биллинга, например в 8 часов 0 минут. Задача может быть настроена сразу, параметров не содержит.

Рассыльщик почты - это разовые клиентам какой-либо информации, осуществляемые администраторами системы. Подробнее о системе рассылок и параметрах запуска задачи здесь. Задача может быть настроена сразу, рекомендуемая частота запуска - один раз в час, при этом желательно чтобы операторы биллинга, проводящие рассылки пользователям, знали время отправки добавляемых рассылок.

Генератор заданий на загрузку логов - запускается раз в час и помещает в базу данных задания для загрузки логов с источников за предыдущий час. Данная задача необходима если вы установили модуль Телефонии, хотя возможен и более удобен режим автоматической загрузки логов с вызовом скрипта dataloader с параметрами по мере подготовки логов. Данная задача не обязательна.

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

#тема письма
email.subject=Напоминание о задолженности
#Код параметра договора типа E-Mail, содержащего E-Mail на который отсылается письмо
email.pid=<число>

Данная рассылка должна проводится раз в сутки, оптимальное время запуска - середина дня, для предоставления возможности пользователям пополнения баланса. Текст, содержащийся в письме варьируется в XSL шаблоне debt_mail.xsl.

Установка статусов договоров - задача должна запускаться раз в сутки в 0 часов 0 минут и изменять актуальные статусы договоров в соответствии с заданиями.

Валидатор - задача должна запускаться раз в период минимальной загрузки системы (например, 3 часа ночи 0 минут). Выполняет проверку базы биллинга на корректность данных, диагностируя ошибки случайных сбоев. Оповещает о наличии ошибок в журналах, которые не были исправлены. В параметрах задачи должно быть указано:

email=<EMail для отправки отчета>

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

17. Справочники

Система справочников необходима для настройки биллинга. В справочниках задаются значения, которые могут принимать различные параметры договоров. Для редактирования справочников выберите пункт меню Справочники=>Другие.

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

17.1. Типы платежей

Типы платежей необходимы для разделения потока платежей клиентов по видам. Далее по ним может быть построена аналитика. Примеры типов платежей: "Наличный", "Через банк", "Дилер Х", "Платёж за подключение" и т.п..

Для добавления нового типа либо подгруппы нужно выбрать группу для добавления (группа Все группы существует изначально) и нажать Новый элемент на панели инструментов.

В справочник можно добавить как группу платежей (см. снимок выше) так и непосредственно платёж выбирая галочку Группа либо Элемент группы. Группы типов платежей предназначены исключительно для визуально более лёгкого восприятия перечня типов платежей в справочнике. Нигде больше они в данный момент не используются. На следующем снимке изображено дерево после добавленной группу типов платежей и платежа в нем.

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

Параметр Не редактируемый элемент показывает, что данный тип платежа нельзя заносить и редактировать через редактор платежей в договоре. Для того чтобы добавлять платежи договорам в справочнике должен быть хотя бы один Редактируемый тип платежа. Создайте его сразу.

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

Следует обратить внимание на столбец ID - это код типа платежа. Во всех конфигурациях где необходимо указание типа платежа указывается именно этот код.

17.2. Типы расходов

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

Редактирование справочника аналогично справочнику типов платежей.

17.3. Параметры договоров

В дополнение к стандартному набору параметров договор может иметь набор пользовательских атрибутов. Для этого их надо перечислить и указать их тип.

Существуют следующие типы параметров договоров:

Текстовое поле - простой текстовый параметр, например Фамилия
Список - значение параметра может быть выбрано из определённого перечня, перечень значений определяется в справочнике Значения списков (см. далее)
Адрес - структурированный адресный параметр, ссылается на справочники Городов, Улиц, Районов и Домов
Флаг - параметр имеющий только два значение (да/нет)
E-Mail - в значении данного параметра договора могут быть введены E-Mail адреса и рассылки на которые они подписаны
Договор - параметр договора, ссылающийся на другой договор (необходим для реализации агентских договоров)
Дата - параметр типа дата
Телефон - в значении данного параметра можно указать до 5 телефонов. Подробнее см. здесь.

В текстовом параметре договора может быть указан скрипт валидации, пример скрипта можно найти WiKi. В остальных параметрах его введение не будет иметь эффекта.

Также существует возможность включить ведение истории параметров договоров каждого договора. Для того, чтобы включить ведение истории нужного параметра, двойным щелчком откройте редактор параметра и установите галочку в поле "История". Нажмите "ОК".

О просмотре истории параметра подробнее см. здесь.

17.4. Группы параметров и Привязка параметров

Иногда для разных групп договоров существуют параметры, которые не совпадают друг с другом. Так, для договора на частное лицо параметр "Юр. адрес" не имеет смысла. Чтобы при редактировании договора отображались только нужные параметры, следует создать группу параметров и в привязке параметров указать необходимый набор атрибутов.

Группа параметров привязывается к договору определяя какими параметрами он обладает.

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

Привязка параметров определяет какие параметры есть у договоров группы.

17.5. Города, кварталы, улицы, дома

Данные справочники позволяют вам осуществлять удобный поиск договоров с привязкой к домам, кварталам. Города, кварталы, районы и улицы - это обычные перечисления, которые используются в справочнике домов. Города, кварталы, районы и улицы привязаны к городам.

Каждый дом вводится с привязкой к кварталу, улице, городу. При выборе города, для выбора доступны районы, кварталы и улицы только для данного города. Для дома можно задать диапазоны подъездов в формате "X-Y:N" отделённых друг от друга ";". X - номер первой квартиры в подъезде, Y - номер последней квартиры в подъезде, N - ёмкость подъезда.

17.6. Обслуживание договора

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

17.7. Значения списков

В данном справочнике указываются допустимые значения для списковых параметров.

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

17.8. Фирмы

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

17.9. Виды рассылок

Перечень почтовых рассылок, об их использовании описано далее.

17.10. Группы договоров

Группы необходимы для логического объединения договоров одного типа, поиска. Например: "Телефония", "Интернет" и т.п.. У одного договора может быть установлено сразу несколько групп, они сохраняются битовой маской.

Для того чтобы убрать группу у всех договоров необходимо в справочнике групп выбрать группу, нажать правой кнопкой мыши и в появившемся меню активировать пункт Удалить у всех договоров. Признак Группа используется определяет видимость группы в редакторе в договоре и во всех фильтрах поиска.

17.11. Типы времени

Справочник предназначен для создания глобальных категорий времени и использования их в дальнейшем в тарифных планах в узлах типа Ограничение по типу времени.

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

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

Далее задаются несколько правил. Каждое правило устанавливает маски на часы, дни недели, дни месяца, месяцы. Месяцы могут принимать значения от 1 до 12, часы от 0 до 23, дни недели от 1 до 7, месяцы от 1 до 12. Маски в пределах правила соединяются условием И. Т.е., например, часы от 0 до 8 И дни недели 6-7. Правила внутри типа времени соединяются условием ИЛИ. Совпадение хотя бы с одним правилом времени даёт основание отнести его к данному типу.

Несколько особенностей поведения типов времени:

пустая дата начала или оконачания периода означает бесконечность;
при пустом списке периодов в типе времени любое время относится к данному типу;
пустой набор правил периода также "включает" в себя любое время, попавшее в данный период.

17.12. Скрипты поведения

Перечень скриптов поведения, которые могут быть назначены договору. Скрипт поведения определяет реакцию на определённые события относящиеся к договору, более подробно о скриптах BGBS описано далее.

17.13. Шаблоны комментариев договоров

Зачастую приходится вводить однотипные комментарии в имени договора, которые совпадают с какими-либо его параметрами (Ф.И.О., электронный адрес и прочее). Для автоматизации этого процесса можно использовать шаблоны комментариев. Для редактирования справочника шаблонов комментариев выберите пункт меню Справочники->Другие и затем Шаблоны комментариев в панели слева.

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

Для создания нового шаблона необходимо ввести Название шаблона, а также саму строку-шаблон. Строка-шаблон - это произвольная строка, в которой возможна подстановка конкретных значений из параметров договора. Для того, чтобы указать, что в данное место строки необходимо подставить значение, например, некоторого текстового параметра с идентификатором 4, нужно указать макрос ${param_4}, как на примере выше. В таком случае, если, например, для некоторого договора у указанного текстового параметра значение "Иванов Иван Иванович", то в комментарий попадет значение "ФИО - Иванов Иван Иванович". Подробнее об установке шаблона комментария см. ниже.

18. Договор

18.1. Общие сведения, создание договора

Договор - основная рабочая единица системы BGBilling. В терминах BGBilling договор - это отдельный баланс (кошелёк) и набор параметров. К договору подключаются установленные в системе модули, посредством добавления услуг этих модулей, что позволяет абоненту использовать свой баланс на различные виды услуг, предоставляемых модулями.

Создание договора производится выбором пункта меню Договор=>Новый договор либо кнопки Новый договор на стандартной панели инструментов. При создании договора открывается диалог следующего вида:

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

18.2. Обзор карточки договора

Карточка вновь созданного договора выглядит следующим образом.

Числом 1 отмечен номер договора. Номер может содержать любые буквы и цифры и для вновь созданного договора по шаблону По умолчанию устанавливается в New contract. После номера в скобках указывается комментарий договора, для нового договора он пуст. Числом 2 отмечен уникальный идентификатор договора.

Рекомендуется присваивать договорам единообразную буквенно-цифровую нумерацию вида B5555-07 (пример), при этом префикс можно использовать для обозначения типа договора (телефония, интернет, IP телефония и т.п.) а порядковый номер - для последовательной нумерации. В комментарии можно указывать название организации либо Ф.И.О. частного лица. Для изменения номера и комментария кликните на них. В появившемся диалоге введите требуемые значения.

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

Кнопка Восстановить возвращает поля редактора номера в исходное состояние.

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

В левой области карточки договора расположено дерево навигации (5). Оно позволяет переключать вкладки редактирования характеристик договора.

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

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

18.3. Параметры договора

Набор параметров договора состоит из фиксированных и настраиваемых параметров. К фиксированным относятся:

Фирма - организация, которой принадлежит данный договор в случае если биллинг эксплуатируют несколько организаций. Перечень фирм задаётся в справочнике Справочники=>Другие=>Фирмы.
Лицо - Физическое либо Юридическое, параметр обозначает тип контрагента по договору
Группа параметров - определяет набор настраиваемых параметров договора, которые будут использованы в данном договоре, перечень групп настраивается в справочнике Справочники=>Другие=>Группы параметров.

Более подробно о создании параметров договоров, их привязке к группам описано ранее.

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

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

Для редактирования параметра типа Флаг достаточно изменить его нажатием мыши.

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

Для редактирования параметра типа E-Mail двойным кликом вызовите редактор, указав адреса каждый с новой строки и рассылки на которые они подписаны. Более подробно о системе рассылок описано далее.

Для редактирования параметра типа Адрес вызывается редактор двойным кликом мыши по строке.

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

Установкой опции конфигурации сервера address.create=1 можно разрешить добавление недостающего дома непосредственно при редактировании параметра. Если дом не будет найден, система предложит запустить редактор дома, где необходимо выбрать все необходимые параметры.

При изменении адресного параметра строка адреса в параметре форматируется в соответствии параметру addrs.format из конфигурации сервера биллинга. При редактировании справочников Города, Улицы, Дома, Районы, Квартала все адресные строки, ссылающиеся на изменённые значения переформатируются.

Это свойство можно использовать при изменении формата адреса в конфигурации. Простое пересохранение названия города в справочнике городов переформатирует все адреса, относящиеся к этому городу.

При установке параметра конфигурации сервера address.unique.check=1 система будет выводить предупреждения если в других договорах есть аналогичный адрес.

Для редактирования спискового параметра вызовите редактор двойным кликом по строке.

Выбор -- не указано -- очистит значение параметра.

Редактировать параметр типа Телефон можно вызвав редактор двойным щелчком мыши по строке.

Один параметр договора Телефон может содержать до пяти номеров телефонов. Формат результирующей строки (отображается в списке параметров договоров), "названия" (префиксы) телефонов, формат номера и формат комментария задаются в конфигурации сервера (по желанию), либо используются значения всех форматов по умолчанию.

Формат результирующей строки задается в конфигурации параметром phones.format для всех параметров типа Телефон (если не указано иного), phones.format.<pid> - для конкретного параметра типа Телефон, где <pid> - номер параметра. Значение этого параметра - REGEXP выражение, в котором используются соответствующие "переменные". Пример:

phones.format=(${pref1} ${phone1} [${comm1}])(; ${pref2} ${phone2} [${comm2}])(; ${pref3} ${phone3} [${comm3}])(; ${pref4} ${phone4} [${comm4}])(; ${pref5} ${phone5} [${comm5}])

где ${prefN} - имя префикса для N-ого телефона (задается отдельно, по умолчанию - пусто); ${phoneN} - номер N-ого телефона (который, в свою очередь, тоже может быть отформатирован. По умолчанию: одиннадцать неразделенных цифр номера, например 84951112233) ; ${commN} - комментарий к N-ому телефону (также может быть отформатирован, по умолчанию: вставляется как есть).

Префиксы для телефонов задаются в конфигурации параметрами phones.prefix.N - для N-ых телефонов всех параметров типа Телефон (если не указано иного) или phones.prefix.<pid>.N - для N-ого телефона параметра, где <pid> - номер параметра. Например:

phones.prefix.1=Рабочий
phones.prefix.2=Домашний
phones.prefix.3=Мобильный
phones.prefix.5=Дополнительный

#префикс первого телефона для параметра с кодом 25,
phones.prefix.25.1=Основной

Т.е. для параметра с кодом 25 (для данного примера) префиксы будут, соответственно, - "Основной", "Домашний", "Мобильный", <пусто>, "Дополнительный". Эти же префиксы отображаются в самом редакторе параметра Телефон.

Формат вывода номера телефона задается в конфигурации параметрами phones.numberformat для всех параметров типа Телефон (если не указано иного) или phones.numberformat.<pid> - для конкретного параметра типа Телефон, где <pid> - номер параметра. Например:

phones.numberformat=+X(XXX)XXX-XX-XX

Также существует возможность указания особого формата для телефонов с различными количествами цифр в коде страны и\или города.

phones.numberformat.<pid>.f13=+X(XXX)XXX-XX-XX
phones.numberformat.f24=+XX(XXXX)X-XX-XX

В данном примере указываем формат отдельно для номера, у которого одна цифра на код страны и три цифры на код города (отсюда и ключ: f13), а также отдельно для номера, у которого две цифры на код страны и четыре цифры на код города (ключ: f24). Определение же формата телефона происходит при его редактировании. Если в поле, отведенное под код страны, записана 1 цифра, а в поле, отведенное под код города (окруженное скобками), записано 0 цифр, то получаем формат f10.

В общем случае последовательность определения подходящего формата следующая:

  • для данного параметра типа "Телефон" (например, 5) и для данного конкретного формата конкретного номера (скажем, f23) ищется строка в конфигурации: phones.numberformat.5.f23 = <шаблон>

  • если такая строка не найдена, то ищем phones.numberformat.5= <шаблон>

  • если такая строка не найдена, то ищем phones.numberformat.f23 = <шаблон>

  • если такая строка не найдена, то ищем phones.numberformat = <шаблон>

  • если и такая строка не найдена, то используется шаблон по умолчанию: XXXXXXXXXXX

Формат вывода комментария к телефону задается в конфигурации через phones.comment для комментариев всех параметров типа Телефон (если не указано иного), через phones.comment.N - для N-ого номера всех параметров типа Телефон (если не указано иного), через phones.comment.<pid> - для конкретного параметра с номером <pid> или через phones.comment.<pid>.N - для N-ого комментария конкретного параметра с номером <pid>. Например:

phones.comment=[${comment}]

В результирующую строку в таком случае попадет комментарий вида [некоторый комментарий].

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

phones.comment.25=" , ${comment}"

Тогда, если результирующая строка параметра с номером 25 задана шаблоном типа ${phone1}${comm1}; ..., то произойдет подстановка следующего вида: 8(123)4567890 , некоторый комментарий; ... . Это удобно тем, что, в случае отсутствия комментария для некоторого номера, не будет "лишнего" пробела перед точкой с запятой.

Для просмотра истории параметров для данного договора необходимо щелкнуть по иконке с лупой (наличие знака "плюс" на иконке означает, что история для данного параметра в текущий момент веремни ведется; отсутствие - не ведется) напротив интересующего параметра. В открывшемся окне отобразится история выбранного параметра. При необходимости ее можно очистить нажав на кнопку Очистить историю.

18.4. Группы договоров

Группа - признак, несущий смысловую нагрузку, установленный в договоре. Например: Оператор, Телефония, VIP. Группы устанавливаются битовой маской, в одном договоре могут быть установлены несколько групп. Всего групп 62. Именование и активация групп производится в справочнике Справочники=>Другие=>Группы договоров, см. ранее. Доступны к редактированию в договоре только группы, отмеченные как используемые.

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

Группы - основной инструмент деления договоров, доступный в качестве фильтра в большинстве мест, где требуется выбрать несколько договоров.

18.5. Поиск договоров

Поиск договоров осуществляется вызовом меню Договор=>Открыть договор либо нажатием аналогичной кнопки на панели инструментов. После этого открывается окно поиска.

Поиск можно осуществлять по названию и комментарию с фильтром по группам и типу лица, либо по параметрам договора. При поиске по названию договора либо комментарию следует набрать маску поиска и нажать >>>. Маска поиска - подстрока, входящая в искомое значение. Кнопка X - отмена поиска, сброс значения. >>> - запуск поиска.

Поиск по параметрам осуществляется выбором фильтруемых параметров и далее в зависимости от типа параметра.

Для спискового параметра выбирается параметр и проставляются галочками удовлетворяющие условию значения.

Для параметра типа E-Mail вводится подстрока адреса и галочками отмечается перечень параметров в которых анализируется данная подстрока.

Для параметра типа Текст выбирается подстрока и перечень параметров в которых она ищется.

Для параметра типа Адрес выбираются город, улица, номер дома (дробь), квартира, комната и подъезд, выбираются параметры в которых будет произведён поиск.

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

Для поиска по параметру Телефон необходимо указать номер телефона, а также сам параметр типа Телефон, по которому будет производится поиск.

Для поиска по идентификатору договора (ID договора) необходимо указать интересующий ID и нажать на кнопку >>>.

Пометка Учитывать скрытые позволяет включить в результаты поиска скрытые договоры. После получения списка договоров выберите интересующие вас и нажмите OK. Возможно открытие нескольких договоров, выделив их с помощью кнопок Shift, Ctrl и мыши.

18.6. Баланс

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

  1. входящим остатком - остатком денежных средств с конца предыдущего месяца

  2. наработкой - наработкой по различным услугам которые потреблял клиент, наработку начисляют модули

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

  4. расходом - списанием денежных средств за разовые услуги со счета клиента

  5. исходящим остатком - вычисляемое значение Исх.ост. = Вх.ост. - Расход + Приход - Наработка, исходящий остаток переходит на входящий остаток следующего месяца

Для просмотра баланса договора за месяц нажмите кнопку Баланс.

В верхней области можно выбрать текущий период с точностью до месяца.

Режим, выбираемый кнопкой М - просматривается баланс выбранного кнопкой месяца. Режим П - позволяет просмотреть балас за определенный период, путем нажатия на одну из кнопок:

"Договор" - весь период действия договора;
"Месяц" - период равный текущему месяцу ;
"Квартал" - период равный от начала текущего квартала до текущего месяца;
"Год" - период равный от начала текущего года до текущего месяца;
"3 Мес." - период равный последним 3-м месяцам;
"6 Мес" - период равный последним 6-м месяцам;
"12 Мес" - период равный последним 12-м месяцам.

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

Кнопки Приход и Расход отображают платежи и списания по договору за месяц. В отличие от наработки, которая ведётся помесячно платежи и расходы ведутся с указанием даты.

Для добавления платежа нажмите в режиме просмотра платежей Новый элемент на стандартной панели инструментов биллинга. Аналогично вносится расход. При внесение платежей/расходов в списке типов платежей/расходов отображаются только редактируемые типы.

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

Замечание

Внесение и удаление фиктивного платежа или расхода можно использовать для корректировки сбоев в балансе (когда сумма отображаемая на вкладке Баланс не соответсвуют суммам платежей/расходов или наработки)

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

Режим Баланс дет. доступен с 4.4 версии и отображает сводную таблицу балансу договора за период с остатками, приходами, расходами и наработкой.

18.7. Лимит договора, режимы договора, управление лимитом

Лимит - это минимальный остаток счета договора при котором он может еще работать. Для редактирования лимита перейдите на вкладку, изображенную на снимке ниже.

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

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

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

Если лимит нужно просто установить, второе поле ввода оставляется пустым. В текстовой области перед кнопкой Ок можно ввести комментарий, объясняющий изменение лимита.

Если при установке постоянного лимита на текущий момент у договора присутствуют задания на автоматическое изменение лимита, то пользователь будет уведомлен об этом в дополнительном диалоговом окне. Ему будет предложено подтвердить свое решение или же отказаться от него. Более того, возможен запрет на установление постоянно лимита в таких случаях, так как это может привести к нежелательным последствиям (например, к ненужному завышению или занижению реального лимита, которое может произойти после отработки задачи восстановление прежде измененных лимитов). Для этого укажите в конфигурации флаг:

reject.limit.change=1

Это позволит предотвратить возможные нежелательные последствия. Отсутствие этой записи или же установка флага в 0 возвращают поведение в данной ситуации по умолчанию (подтверждение постоянного изменение лимита).

Клиенту можно предоставить возможность самому временно понижать лимит через страницу Web статистики (только в режиме Дебет). Как это сделать описано далее.

18.8. Режимы баланса договора

В системе существуют два режима работы договора: дебет и кредит. Их отличие - в способе работы с должниками.

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

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

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

18.9. Статус договора

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

  1. Активен

  2. В отключении

  3. Отключен

  4. Закрыт

  5. Приостановлен

  6. В подключении

Активен - это нормальное состояние договора с работающими сервисами.

Отключен - это состояние договора, когда его отключили за неуплату долгов . При этом все модули не должны предоставлять свои услуги клиенту (Dialup/Vpn — не пускает клиента, IPN - закрывает шлюз, VoiceIP — не пускает клиента, абонплата продолжает сниматься.

В отключении — промежуточный статус, возникает при обработке события перевода договора в отключенное состояние скриптом BGBS. В статус Отключен договор переводится при выполнении работ по фактическому отключению услуг, которые не могут быть закрыты средствами биллинга (телефония). Например, скрипт может создавать CRM задачу по отключению номера.

Закрыт - состояние договора с принудительно приостановленным обслуживанием. Например, после месяца нахождения в отключенном состоянии. При этом блокируется доступ к блокируемым услугам (DialUP, VPN, VoiceIP, IPN), абонплата не снимается.

Приостановлен — состояние договора с добровольно приостановленным обслуживанием. При этом блокируется доступ к блокируемым услугам (DialUP, VPN, VoiceIP, IPN), абонплата не снимается.

В подключении — промежуточный статус, возникает при обработке события перевода договора во включенное состояние скриптом. В статус активен договор переводится по выполнению работ по фактическому подключению услуг, которые не могут быть поключены средствами биллинга (телефония). Скрипт может создать задачу CRM на подключению номера.

Текущий статус договора отображается отдельным узлом в дереве карточки договора в виде: Статус <значение>. При выборе узла дерева в таблице отображается статусы договора.

Снизу мы можем наблюдать историю изменения статусов:

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

Вновь установленный статус перетирает все статусы с пересекающимися периодами. В один день возможен только один статус договора. Далее приведено несколько снимков экрана, помогающих понять логику перетирания статусов. Снимки приведены попарно. Сначала идет снимок с историей статусов и установленными параметрами смены статуса, а затем вид истории после нажатия кнопки Выполнить.

Возможны следующие модификации статусов:

Подключить - переведение статуса в Активен
Отключить - переведение статуса в Отключен
Закрыть - переведение статуса в Закрыт
Приостановить - переведенение статуса в Приостановленный

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

18.9.1. Роль статуса в дебетовых договорах

Для договоров в режиме Дебет статусы договора устанавливаются только администратором, отключение либо приостановка договора через статус переводит шлюзы IPN в состояние заблокирован, RADIUS сервера запрещают авторизацию соединения. Поступление денег на счет ситуацию не меняет.

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

18.9.2. Роль статуса в кредитовых договорах

Для кредитовых договоров статус тесно завязан с системой работы с кредитовыми должниками. Он может изменятся в результате оплаты договора. В состоянии Активен работает аналогичная дебетовым договорам аварийная блокировка/разблокировка сервисов в модулях по лимиту договора.

18.9.3. Система работы с кредитовыми должниками

Основная рабочая область оператора для отключения должников вкладка Сервис=>Монитор статуса. Перед началом работы необходимо сделать срез балансов, нажав соответствующую кнопку. Все описанные далее алгоритмы применимы только к кредитовым договорам.

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

Все фильтры соединяются по условию И. Возможна фильтрация по:

1. группе договора + исключение определенных групп договоров
2. минимальному объему наработки по указанным услугам за прошлый и текущий месяц
3. режим договора: кредит/дебет
4. статусу договора
5. периоду который договор был в данном состоянии в днях или месяцах
6. сумме сальдо (указывается диапазон от и до)
7. соотношению текущего баланса или баланса на начало месяца с лимитом
8. размеру превышения модуля отрицательного сальдо начала месяца над наработкой какого-то количества предыдущих месяцев

Изменения статусов договоров производится идентично смене статуса одного договора (см. выше), необходимые договоры выбираются в таблице с использованием клавиш Ctrl и Shift. Двойной клик по строке таблицы открывает договор.

В определенный момент времени оператор выбирает все договоры с отрицательным сальдо, находящиеся в статусе Активен и выбрав строки таблицы переводит их в состояние Отключен. При этом скрипт обработки события перевода может установить их в состоянии В отключении, если отключение только средствами биллинга невозможно. В состояние Отключен такие договоры перейдут после фактического отключения например номера.

В состоянии Отключен абонент может:

1) Позвонить и поообещать оплату. В этом случае оператор находит его в списке должников по номеру договора и переводит его в статус Активен на несколько дней (добавляется в договор статус Активен с периодом). При этом период статуса Отключен в договоре не закрывается и по истечению нескольких дней если не пройдет оплата договор снова будет считаться отключенным.

Если на договор при подобной временной активации производится платеж и сальдо становится положительным - система изменяет все грядущие статусы Отключен на Активен.

2) Оплатить. Если сальдо после оплаты становится неотрицательным - договор более не является должником, система автоматически переводит его в статус Активен.

Если абонент ничего не предпринял, то он остается в состоянии Отключен. При проведении платежа проводится проверка его сальдо и если оно неотрицательно то он переводится в состояние Активен.

Далее при определенном периоде нахождения в состоянии Отключен абонент может быть переведет в состояние Закрыт, при этом прекращается снятие абонплаты. Данный статус означает то, что договор закрыт именно за неуплату и при получении платежа действия системы аналогичны отключенному состоянию - проверяется сальдо и если оно неотрицательно, то договор переводится в состояние Активен.

Замечание

Если по каким-либо причинам такое поведение статусов нежелательно, то можно отключить автоматическую активацию договора при изменении сальдо на положительное. Для этого в концигурации сервера необходимо указать флаг:

do.not.open.contract.on.payment=1

Отсутствие этой записи или установка флага в 0 оставит поведение по умолчанию.

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

18.10. Тариф и группа тарифов

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

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

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

Более подробно о тарифных планах можно узнать здесь.

Группа тарифов нужна исключительно для ограничения тех тарифов на которые клиент может переключиться через Web-интерфейс. Более подробно об этом описано в главе Группы тарифных планов

18.11. Примечания

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

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

18.12. Дополнительные действия

Дополнительные действия в договоре - это возможность непосредственного вызова скрипта BGBS для данного договора через АРМ оператора биллинга либо из Web статистики. Список дополнительных действий формируется скриптом по событию Получение списка доп. действий для договора либо Получение списка доп. действий для Web, пример в WiKi.

Далее оператор биллинга либо клиент на Web статистике вызывает действие, снова вызывая скрипт, но уже с событием Обработка доп. действия для договора. Скрипт выполняет какие-то действия с договором, возвращая сообщения.

С версии 4.5 сообщения о выполненых действиях возможно создавать в виде html, при этом создержимое должно быть валидным xml фрагментом, а корневым элементом должен быть элемент <html>:

event.addReport( "<html><table cellspacing=\"1\"><thead><tr><td>Отчет</td></tr></thead><tbody>"
  + "<tr><td class=\"comment\">Привет, анлим активирован!!!</td></tr></tbody></table></html>" );

18.13. Подключение модулей и их услуг к договору

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

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

Внимание

При удалении модулей из договора сохранность выделенных сущностей, оказанных услуг и прочей информации данного модуля, связанной с данными договором, НЕ ГАРАНТИРУЕТСЯ.

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

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

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

18.14. Карты регистрации договора

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

18.14.1. FOP-карточки.

Вид карточки:

Карточки генерируются по XSLT:FO шаблону, указанному в основном конфиге:

contractcard.1=card_inet.xsl:Карта регистрации
contractcard.2=card_inet.xsl:Вторая карта регистрации

Возможно указание групп договоров, для которых отображается данная карта. Группы указываются после указания карты в конфигурации, через двоеточие:

contractcard.2=card_inet.xsl:Вторая карта регистрации:0,4,5

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

Примечание: XLST card_inet.xsl шаблон необходимо отредактировать под ваш набор модулей.

Возможно создание собственных карточек: при генерации карточки в xml документ собирается информация по договору, затем документ трансформируется по выбранному шаблону. Формат xml документа можно посмотреть, если нажать на кнопку XML:

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

18.14.2. Полная карта договора

Карта имеет следующий вид:

Карточка генерируется по XSLT:html шаблону contract.xsl. При генерации карточки в xml документ собирается информация по договору, затем документ трансформируется в html. Формат xml документа можно посмотреть если нажать на кнопку XML:

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

18.15. Шаблоны договоров

Шаблоны договоров созданы для двух целей:

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

2) для автоматического создания договоров. Например, при первом звонке клиента с интернет-картой, ему создается договор по шаблону, который указан для этой карты. Для создания или редактирования шаблонов зайдите в Договор=>Шаблоны.

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

Необходимо установить следующие параметры:

  • лицо (юридическое и физическое) - тип договора;

  • режим (дебет и кредит) - режим обсчета;

  • лимит - минимальный остаток на счете;

  • модули - потребляемые договором модули;

  • тарифный план (либо несколько тарифных планов с указанием их позиций) и группа тарифов из которой можно устанавливать план для договора, пустая группа тарифов - разрешен любой тарифный план, но смена через Web не поддерживается;

  • группы - группы, в которые будет входить договор;

  • скрипт поведения - скрипт который будет установлен договору при создании;

  • группа параметров - группа параметров договора, см. выше;

  • фирма - выбор фирмы, которой принадлежит договор (параметр используется если биллинг обслуживает базы нескольких организаций и в данный момент несет только информативную функцию);

  • время жизни - количество дней, в течении которых будет существовать договор. При этом 0 означает неограниченный срок ( пока не будет закрыт вручную ). Договор будет создан с указанной датой закрытия. Данный параметр можно использовать для создания карт с ограниченным сроком действия. Т.к. после активации карточки создается договор, он будет создан с проставленной датой закрытия.

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

Начиная с 4.6 версии на вкладке Модули возможно указать типовые действия по настройке модулей, выполняемые сразу после создания договоров. Каждый модуль представлен отдельной вкладкой с галочкой Выполнить. В данный момент после создания договора могут быть выполнены следующие действия:

  1. Создан логин Voip определенного типа с набором RADIUS атрибутов

  2. Создан логин DialUP с набором RADIUS атрибутов и ограничениями

  3. Установлены типы выставляемых документов модуля Бухгалтерия

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

В шаблоне договора можно указать шаблон имени договора. При пустом поле Шаблон имени сразу после создания договор называется New contract.

Шаблон имени может включать буквы, символы и следующие подстановки:

  • ${NX} - порядковый номер договора, X - цифра. Подстановка будет заменена порядковым номером договоров такого типа дополненным слева нулями до длины X;

  • ${Y2} - две последние цифры года создания договора;

  • ${Y4} - четыре последние цифры года создания договора;

  • ${time:<format>} - время создания договора, вместо <format> может быть строка макроса с yy - две последние цифры года, yyyy - четыре цифры года, MM - месяц, dd - день месяца. Полное описание допустимых макросов доступно здесь.;

  • ${NRX} - относительный порядковый номер договора, где Х - число разрядов в номере (аналогично ${NX}-подстановке). Относительный порядковый номер формируется следующим образом: сначала выполняются все прочие подстановки (например, текущая дата), затем находится договор в базе с таким "шаблоном" имени договора, берется последний относительный номер среди подобных договоров и увеличивается на единицу, после чего подставляется непосредственно в имя текущего создаваемого договора. Например, если шаблон имени определен как "D${Y4}${time:MM}${time:dd}-{NR4}", то при создании за текущие сутки (например, 01.01.2009) двух договор получим номера, соответственно, D20090101-0001 и D20090101-0002, а при создании нового договора по этому же шаблону на следующие сутки получим номер D20090102-0001.

Для модуля карт (создание договора по карте) доступны следующие макросы:

  • ${card:00000} - логин карты, количество нулей может быть любым и задает дополнение логина нулями слева до определенной длины;

  • ${card_series:00000} - серийный номер карты карты, количество нулей может быть любым и задает дополнение логина нулями слева до определенной длины.

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

Для создания нового договора выберите пункт меню Договор=>Новый договор. В появившемся окошке выберите базовый шаблон и дату заключения договора.

При выборе некоторого шаблона договора можно вручную изменить шаблон его имени, отметив поле "Вручную". Причем вводить можно не только конкретное имя нового договора, но и изменять текущие макроподстановки (фактически создавать новый шаблон имени). Это удобно в том случае, если имя договора не генерируется системой, а по тем или иным причинам заранее известно, однако необходимо сохранить внутренние настройки шаблона договора.

Также договор можно сразу создать как субдоговор для какого-либо супердоговора. Для этого следует отметить поле "Создать договор как СУБДОГОВОР для ..."

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

18.16. Переоформление договоров

Типовая операция, подразумевающая закрытие старого договора определенной датой с переносом всех его свойств на новый договор следующим днем от той даты. При этом в новом договоре указывается новое название организации, реквизиты.

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

После нажатия Ok старый договор будет закрыт, новый открыт и на него будут перенесены все опции старого с новой даты. Как то: логины, адреса, услуги, абонплаты и пр.

19. Тарифные планы

Тарифный план задает стоимость услуги в какой-либо момент времени. Тарифный план представляет собой дерево, в котором определяются одно или несколько модульных поддеревьев, задающих правила тарификации в модулях.

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

Например, если у вас в системе есть линейка DialUP тарифов с разной абонплатой и стоимостью часа, вы можете объединить модульные поддеревья DialUP и NPay модулей, указывая в договоре только один тариф. Но в то же время те же договоры могут быть подписаны на разные Voip тарифы, для которых целесообразно создать отдельную линейку и указывать в договоре 2 тарифа: DialUP+Абонплата и VOIP.

Тарифные планы могут быть глобальные(созданы в справочнике тарифных планов и могут использоваться всеми договорами) и персональные(созданы в конкретном договоре) .

Для того, чтобы создать глобальный тарифный план, зайдите в меню Справочники=>Тарифные планы. Нажмите кнопку Новый элемент.

Новый тарифный план создается с пустым деревом. Во вкладке Основные настройки находятся основные параметры тарифа. Для изменения названия тарифного плана введите новое имя в поле сверху и нажмите Переименовать.Так же есть галочка, обозначающая используется тариф или нет . С помощью выпадающего списка над тарифными планами можно фильтровать их по признаку используемости.

Фильтр по договору используется при добавлении тарифного плана для некоторого договора (см. здесь). Тариф будет отображаться в списке возможных для добавления тарифов к данном договору только в том случае, если удовлетворяет выбранному фильтру. Лицо - тариф будет доступен, соответственно, для любых договоров, только для физических лиц или только для юридических лиц. Маска - тариф будет доступен, только если имя договора удовлетворяет заданной маске договора. Группы - тариф будет доступен, если договор входит в хотя бы одну из выбранных групп.

Для добавления в тариф возможности тарификации услуг определенных модулей необходимо добавить модульные поддеревья, перейдя на вкладку Дерево -> Управление поддеревьями.

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

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

Для добавления в узел дерева дочерних элементов нажмите по нему правой клавишей мышки, выберите Добавить и нужный тип узла. На рисунке показано, как в модуль DialUp добавляется узел Услуга.

А вот вид дерева после добавления узла:

Для того, чтобы редактировать узел нажмите правой кнопкой и выберите в меню Редактировать. Для узла отобразится специфичный для него редактор. Ниже изображен редактор для узла Услуга.

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

В договоре могут быть определены собственные (персональные) тарифные планы.

В момент тарификации поиск тарифного плана производится по следующему алгоритму:

1) выбирается список1 - персональные тарифные планы договора, активные на данный момент и содержащие тарифное поддерево для данного модуля;

2) выбирается список2 - глобальные тарифные планы договора, активные на данный момент и содержащие тарифное поддерево для данного модуля;

3) берется первый тариф из списка1 если он пуст - то из списка2.

Т.е. персональные тарифы рассматриваются в первую очередь. Для большинства модулей в один день для одного договора может действовать только один тариф для данного модуля.

Исключение составляют голосовые модули (Voip, Phone), в которых производится поочередный просмотр всех тарифов для данного модуля сначала персональных затем глобальных в договоре в порядке позиций до нахождения цены звонка.

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

Далее для редактирования дерева тарифа строку с тарифом нужно выбрать в таблице персональных тарифов и нажать кнопку Открыть дерево в нижнем правом углу. Правила редактирования дерева персонального тарифа не отличаются от редактирования дерева глобального тарифа.

Для примера предположим, нам нужно чтобы данный клиент звонил в Афганистан дешевле чем все, для этого создадим ему собственный тариф модуля VOIP расширив глобальный тариф VOIP, изображенный ниже.

В редакторе пользовательского тарифа выбираем модуль Voip и справа выбираем тариф для расширения - VOIP.

Нажав кнопку Расширить мы создаем поддерево - потомок, добавив пользовательскую цену после цены из стандартного тарифа мы перекрываем цену для данного договора, т.к. узлы дерева - потомка отрабатывают всегда после узлов дерева - предка. Обход дерева происходит так же как оно отображается. Теперь дерево выглядит так:

Для закрытия дерева - кнопка в правом нижнем углу.

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

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

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

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

19.1. Стандартные узлы тарифных планов

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

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

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

Ниже перечислены основные типы узлов, встречающиеся во всех модулях:

19.1.1. Услуга

Редактор узла и узел в тарифе выглядят так:

Узел выступает фильтром по услуге и передает запрос каждому из потомков только если услуга из тарифного запроса совпадает с указанной в узле.

19.1.2. Мульти услуга

Редактор узла и узел в тарифе выглядят так:

Узел выступает фильтром по услуге и передает запрос каждому из потомков только если услуга из тарифного запроса совпадает с одной из указанных в узле. Действие узла полностью идентично узлу Услуга за исключением возможности указания нескольких услуг в одном узле. Эта возможность может быть удобна при необходимости указания одинаковой цены на несколько услуг либо выдачи единой квоты по трафику (IPN, DialUP модули).

19.1.3. Период

Редактор узла и узел в тарифе выглядят так:

Параметр "время" из тарифного запроса попадает в указанный период. Если одна из дат не указана, то она берется бесконечной (в прошлое или будущее). Узел период с неуказанными обеими датами просматривает дочерние узлы в любом случае.

Основное назначение узла - изменение стоимости в тарифном плане с какой-либо даты. Ниже приведен пример, как изменить стоимость услуги Dial-Up(время) с 1 сентября 2009 года.

В период можно помещать также секции тарифного дерева, регулируя, когда отрабатывает тот или иной блок. В приведенном ниже примере с 1 сентября увеличивается объем предоплаченного трафика в тарифе модуля DialUp.

19.1.4. Фильтр по времени

Редактор узла и узел в тарифе выглядят так:

Для редактирования условия нужно вызвать редактор сделав двойной клик по строке условия в редакторе , либо нажав кнопку Добавить. Набор масок дней, часов, дней недели и месяцев, перечисленных в условии должен выполнятся весь, т.е. чтоб сработало условие, нужно совпадение всех масок. При вводе масок условия часы могут принимать значения от 0 до 23, дни недели от 1 до 7, дни месяца от 1 до 31, месяцы от 1 - 12. При вводе можно использовать символы - ( интервал со входящими концами ) и , ( перечисление ). Для удобства ввода можно использовать записи * ( будут выведены все значения ), а также */n (n - целое число, все что делится на n, например */2 - 0, 2, 4, 6... ), либо *\n ( n - целое число, все что не делится на n).

Узел выступает фильтром тарифного запроса, запрос пропускается к обработке в узлах-потомках только если параметр "время" в запросе совпадает хотя бы с одним набором условий узла. Фильтр позволяет определять в тарифах различную стоимость услуги по времени суток, дням недели, месяца. Пустой набор ограничений означает отсутствие фильтра по времени. Узел пропускает в себя запрос, только если перед ним в том же узле-предке не стоял другой фильтр по времени либо Фильтр по типу времени уже пропустивший запрос в себя (принявший запрос). Данный принцип позволяет делать наборы ограничений по-умолчанию. Например, так можно определить стоимость в будние дни и праздники для модуля DialUp.

В приведенном выше примере во втором наборе ограничений не указаны явно дни с 1 по 5, узел обрабатывает запросы, не попавшие в первый набор ограничений. Для данного случая метод не дает ощутимой выгоды, однако при необходимости указывать многочисленные праздничные дни он удобен. Обратите внимание, что следующий пример уже не будет работать аналогичным образом. Т.к. у узлов разный предок.

Во втором примере все запросы будет принимать второй пустой набор ограничений. Т.к. у узлов разный узел-предок. Данную ситуацию (желание задать цены на будние дни с периодом) корректно было бы разрешить так:

19.1.5. Фильтр по типу времени

Редактор узла и узел в тарифе выглядят так:

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

Либо так:

При этом в типе времени Рабочие дни не указываются никакие маски.

19.1.6. Параметры тарификации

Редактор узла и узел в тарифе выглядят так:

Узел передает в ответной части тарифного запроса параметры тарификации:

  • максимальную длительность бесплатного звонка в секундах;

  • количество десятичных знаков после запятой в стоимость звонка (не имеет смысл устанавливать более, чем разрядность поля таблицы БД);

  • правила откругления длительности звонка.

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

Звонки до 10 секунд включительно считаются нулевой длительности. Стоимость звонка округляется до пятого знака, т.е., например 4.32344.

Параметр Учитывать округление при автор. действует только для Voip модуля и позволяет выдавать клиенту длительность разговора с учетом округления длительности в большую сторону. Т.е. если сессии от 20 до 120 секунд округляются кратно 20 а человеку хватает денег на 83 секунды то после авторизации RADIUS вышлет 80 секунд разрешенного времени.

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

19.1.7. Использовать карту зон

Редактор узла и узел в тарифе выглядят так:

Узел получает вызываемый номер из тарифного запроса, определяет по нему направление и зону и помещает их в тарифный запрос.

19.1.8. Зона

Редактор узла и узел в тарифе выглядят так:

Узел пропускает запрос внутрь только если установленная в запросе зона равна указанной в узле. Поле ввода текста в правой части и кнопка "+" позволяют быстро добавить отсутствующую зону в справочник. В запрос зона устанавливается узлом Использовать карту зон.

19.1.9. Часть префикса и Диапазон префиксов

Редактор узла и узел Часть префикса в тарифе выглядят так:

либо так для Диапазона префиксов:

Отличие двух узлов - в способе задания маски номера.

В Части префикса задается REGEXP выражение, которое должно совпасть с начальной частью "остатка" номера.

В Диапазоне префиксов задается выражение вида <общий префикс>|<диапазоны>. Например в указанный выше диапазон можно переписать в виде: 34|72-73, где 34 будет являться общим префиксом. Общий префикс может быть и не указан. Если он указан, то как бы подразумевается для всех диапазонов после него. Начальная часть остатка номеров должна попасть в один из указанных диапазонов. При этом все диапазоны префиксов в узле должны быть одной длины.

Оба узела работают с параметром "номер", переданным в тарифном запросе. При этом разбор номер идет по частям, начиная с начальных символов. Каждый узел, в который попадает телефон, сравнивает начало номера с шаблоном в узле.

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

У каждого узла может быть установлен направление и зона. Если в совпавшем узле указано направление либо зона, они подставляются в ответ тарифного запроса.

Рассмотрим для примера, как происходит разбор телефона 73472555555 в указанном ниже тарифе. В нем используется комбинация этих двух узлов, т.к. они являются взаимозаменяемыми.

1) Ветка 7 Россия - начало совпадает с 7 => 7 отбрасывается и далее передается 3472555555

2) аналогично ветки 3 и 4

3) в ветке 72 определяется направление звонка

4) в ветке Минута исходящего - цена минуты разговора.

Ветки 3 и 4 просто прописывают данные в проходящий через них тарифный запрос.

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

Таким образом достигается высокая эффективность обработки запросов.

Рассмотрим еще один пример использования узлов:

В приведенном выше примере префиксы 73472-73474 и 73476 будут отнесены к Уфе, а префиксы 7351-7353 к Челябинску.

19.1.10. Стоимость минуты

Редактор узла и узел Стоимость минуты в дереве выглядят так:

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

19.1.11. Множитель цены

Редактор узла и узел Множитель цены в дереве выглядят так:

Узел используется для умножения цены, установленной узлом Стоимость минуты на определенный коэффициент. Например, используя данный узел, можно быстро создать тариф с НДС для физ. лиц, расширив базовый тариф и добавив в конце дерева узел с умножением.

20. Субдоговоры

Биллинг позволяет выстраивать договоры в иерархии. При этом в вершине иерархии устанавливается супердоговор, а подчиненными к нему - субдоговоры. Каждый субдоговор является полноценным договором во всех остальных отношениях: к нему могут быть подключены модули, назначен тарифный план, установлены параметры.

Субдоговора различаются на два типа: с зависимым балансом (зависимые субдоговора) и независимым балансом (независимые субдоговора). Выбор режима субдоговора производится при его подключении к супердоговору.

20.1. Добавление субдоговоров

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

При этом вкладка Иерархия договоров меняется следующим образом для супердоговора и субдоговора. Обратите внимание, что тип зависимости указывается буквой рядом с именем субдоговора в списке субдоговоров супердоговора и в дереве субдоговора строкой з.субдог или н.субдог.

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

20.2. Зависимые субдоговора

Все зависимые субдоговора супердоговора имеют единый баланс со своим супердоговором.

В балансе субдоговора входящий остаток на начало месяца всегда равен нулю. Приход единого баланса супердоговора и субдоговоров равен сумме приходов супердоговора и его субдоговоров. Расход единого баланса равен сумме расходов супердоговора и его субдоговоров. Наработка единого баланса равна сумме наработок супердоговора и всех субдоговоров.

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

20.3. Независимые субдоговора

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

В зависимости от режима баланса супердоговора и независимых субдоговоров при оценке задолженности берется либо баланс либо сальдо. Распределение наработки может быть произведено и после занесения прихода оператором биллинга путем нажатия кнопки Перенос средств в любой из панелей баланса договора.

После выбора распределения средств между супердоговором и субдоговорами на в супердоговор заносится расход а в субдоговора - приходы. Типы расхода и прихода должны быть определены в справочниках как нередактируемые и указаны в конфигурации сервера следующим образом:

transfer.payment.type=<код типа платежа, используемого для переноса средств>
transfer.charge.type=<код типа расхода, используемого для переноса средств>

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

В модуле телефонии (Phone) субдоговора с независимым балансом несут дополнительную функцию организации тарификации по агентской схеме, когда звонки и наработка по одному и тому же поинту, добавленному в супердоговор, относятся либо к супердоговору либо к одному из его независимых субдоговоров.

21. Объекты

Понятие объекта введено в систему для упрощения учета сложных мультисервисных договоров. Объекты никак не влияют на обсчет договоров. Объект представляет из себя именованную сущность с набором параметров и привязанных сущностей из различных модулей. Например, возможно заведение в договоре нескольких точек подключений, к каждой из которых будет привязан свой диапазон адресов из IPN модуля, установлен собственный адрес и тип точки. Использованию объектов предшествует заполнение справочников (меню Справочники=>Объекты). Параметры объектов могут быть следующих типов: Адрес, Текст, Список, Дата.

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

В типах объектов определяются существующие в системе типы объектов и макрос их именования. В макросе именования могут быть подставлены следующие значения: ${text:<код параметры>} ${address:<код параметра>} ${list:<код параметра>} ${date:<код параметра>}.

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

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

Для добавления объекта в договор перейдите на вкладку Параметры=>Объекты в договоре.

Для добавления объекта выберите "Добавить" в верхней панели инструментов. Далее выбирается тип объекта и открывается его редактор.

После чего откроется редактор для занесения параметров объекта.

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

Привязку сущности модуля к объекту можно осуществить двумя способами:

1) Для сопоставления объекту сущностей модуля в каждом модуле предусмотрено доп. поле.

2) В редакторе объекта доступны редакторы сущностей модулей, перечень которых указан в свойствах объекта

Каждая добавленная на закладке сущность модуля будет автоматически отнесена к выбранному объекту.

На вкладке Сводная отображается сводная таблица по всем подключенным к объекту сущностям модулей.

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

Внимание

В текущей версии при переносе объекта производится перенос только самого объекта и его параметров. Сущности модулей отвязываются от объекта, перенос наработки также не производится. В последующем функционал будет дореализован.

Поиск договора может осуществляться по параметрам привязанным к нему объектов.

22. Удаление договоров, архив договоров

Для удаления договора следует его открыть и нажать на кнопку Удалить договор. После чего нужно ответить на вопрос: удалять его безвозвратно или в архив.

После удаления в архив договор будет сериализован в формат XML, сжат в архив ZIP и выложен в папку ..BGBillingServer/archive. После чего данные из базы будут удалены.

Для автоматического удаления договоров зайдите в Сервис=>Менеджер договоров и на вкладке Правила для удаления укажите правила, по которым будет удаляться договор. Правила делятся на два типа:

  • по времени - устанавливается параметр срок - период в месяцах, прошедший с момента закрытия договора. Также можно установить фильтр по группам.

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

Очень желательно поделить все ваши договоры по группам: например Карточки, Организации и т.д. Это позволит вам более гибко устанавливать правила удаления, не рискуя удалить не те договоры.

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

Рекомендуется ставить эту задачу на ночное время, чтобы днем не загружать БД. В параметрах задачи укажите значения:

max_balance=20
max_closed=10
email=bill@bill.ru
#подкаталог для архивирования
#folder=card

Значение параметров max_balance - максимальное количество договоров, удаляемое за один раз по правилам по сумме, max_closed - по времени, email - адрес на который будет послан отчет с перечнем удаленных договоров если таковые имелись.

Тема приходящего письма: "These contracts were deleted!".

Для того чтобы планировщик смог отсылать письма не забудьте указать в настройках сервера параметры EMail. Все, автоматически удаляемые, договора помещаются в архив договоров. Для просмотра архива используйте вкладку Сервис=>Менеджер договоров=>Управление архивом.

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

23. Web-интерфейс пользователя

Web страница пользователя предоставляет клиентам полную информацию о состоянии счета, детальные отчеты по всем модулям договора. Через персональный кабинет пользователь может также изменять пароли, получать и выставлять себе счета, производить оплату через WebMoney и т.п. в зависимости от состава установленных модулей и плагинов.

По-умолчанию страница статистики доступна по адресу:

URL страницы статистики: http://<адрес сервера биллинга>:8080/bgbilling/webexecuter. При входе клиента на эту страницу происходит его перенаправление на страницу авторизации.

По ссылке Забыли пароль? пользователь может произвести отправку пароля на E-Mail.

В поле Номер договора пользователь должен ввести номер своего договора, а в поле Email почтовый адрес, который должен совпасть со значением текстового параметра договора, содержащим E-Mail адрес для восстановления пароля. Код этого параметра указывается в конфигурации сервера биллинга contract.password.forgot.email.param.id=<числовой код параметра>.

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

Страницы Web интерфейса пользователя собираются из XML документа с использованием XSLT шаблона. Каждый модуль и плагин помещает свои XSLT шаблоны в каталог BGBIllingServer/webroot/xsl. Модифицируя их, вы можете настраивать оформление страницы пользователя.

Web интерфейс может работать в двух режимах: xml и html. Режим задается переменной web.mode конфигурации сервера биллинга. В xml режиме клиент получает XML документ со ссылкой на XSLT шаблон преобразования и его браузер самостоятельно собирает страницу. В режиме html клиенту отдается собранная биллингом XHTML страница.

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

В html режиме после окончания модификации всех XSLT шаблонов установите переменну xslt.cache=1 в конфигурации сервера.

Внимание

Опция влияет на кэширование всех XSLT шаблонов, необходимо отключать кэширование при необходимости правок шаблонов.

Параметр web.xslt конфигурации сервера URL папки, где будут лежать ваши XSLT шаблоны. При использовании режима xml адрес 127.0.0.1 следует заменить на адрес машины с сервером биллинга, доступный пользователям из внешней сети.

23.1. Настройка доступа к статистике

По-умолчанию клиентам разрешена авторизация по номеру договора и паролю статистики, пароль статистики изменяется на вкладке Web=>Пароль статистики договора. Для смены пароля наберите его в текстовой области либо установите галочку авто и нажмите ОК.

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

Текущий пароль статистики, установленный после создания договора, можно посмотреть в полной карте договора (вкладка Карточки=>Полная карта в договоре).

Минимальная и максимальная длина пароля доступа к статистике задаются параметрами конфигурации сервера password.length.min и password.length.max, допустимые в пароле символы задается в конфигурации сервера переменной password.chars.

По умолчанию отображается примерно следующая страница пользователя. Содержимое меню может пополняться по мере подключения модулей и плагинов к системе.

Режим авториазации на странице статистики задается в конфигурации сервера биллинга.

web.auth.modes=0:1

Данное значение стоит по умолчанию и обозначает что разрешена авториазация на странице статистики по номеру договора + паролю (вкладка Пароль в карточке договора).

Страница авторизации пользователя формируется шаблоном login.xsl. В стандартной поставке шаблон содержит только форму авторизации по номеру договора и паролю.

Клиент работает на странице статистики до нажатия пункта меню Выйти либо до истечения таймаута. При выходе со страницы статистики клиент перенаправляется на страницу задаваемую опцией.

web.exit.redirect=about:blank

По умолчанию это пустая страница, но вы можете разместить здесть URL страницы провайдера.

Сервер определяет тип авторизации по передаваемому в форме авторизации параметру midAuth=<коду модуля>. Если параметр отсутствует - авторизация идет по номеру договора + паролю доступа к статистике.

Пример 1.3. Пример авторизации по логину

Предположим что в системе существует модуль DialUP с кодом 21. Для того чтобы разрешить авторизацию через его логины с паролями добавить опцию.

web.auth.modes=0:1;21:1

Теперь раскомменировать вторую форму авторизации в login.xsl.

<form method="post" action="webexecuter">
<input type="hidden" name="midAuth" value="21"/>
 <table align="center" width="300px" class="filter" style="margin-top:20px;">
  <tr>
   <th align="left">Логин DialUP:</th>
   <td><input class="logon" type="text" name="user" SIZE="15"/></td>
  </tr>
  <tr>
   <th align="left">Пароль DialUP:</th>
   <td><input class="logon" type="password" name="pswd" SIZE="15"/></td>
  </tr>
  <tr>
   <td></td>
   <td><input type="submit" value="Вход" style="width: 100%; border: 1px solid #404040;"/></td>
  </tr>
 </table>
</form>

Теперь клиенту будет предлагаться два режима авторизации.

Аналогично можно добавить авторизацию по логину и паролю VOIP модуля. Возможно в midAuth параметре формы передавать несколько модулей через запятую, 0 - код модуля ядра. При этом будет осуществлен последовательный поиск в указанных модулях. Модуль должен быть разрешен в web.auth.modes.

При ошибки авторизации отображается страница, задаваемая шаблоном error.xsl. Скорректируйте в данном шабоне номер телефона вашей техподдержки. Если вы используете дополнительные режимы авторизации кроме договора - скорректируйте выводимый текст.

Внимание

Шаблон перетирается при установке обновлении сервера и клиента биллинга

Если пользователь несколько раз в течении короткого времени введет неверный пароль - доступ временно блокируется с указанием времени до которого вход запрещен. Это мера безопасности от подбора пароля Web статистики.

Временные характеристики защиты могут быть настроены в конфигурации сервера. Переменная logon.counter.max задает максимальное количество неудачных попыток авторизации для договора подряд. После каждой попытки может быть установлен таймаут, базовый размер которого определяется переменной logon.timeout.period. После первой неудачи таймаут равен периоду, после второй - двум периодам, затем трем и т.п. Алгоритм увеличения периода задается переменной logon.timeout.action. После исчерпания logon.counter.max попыток авторизации договор блокируется на время logon.timeout.lock секунд.

Оператору биллинга на вкладке Web договора доступны функции мониторинга доступа к Web статистике.

На вкладке Входы отображаются входы на Web статистику. На закладке Ошибки - ошибки авторизации с отображением введенных логина и пароля. Кнопка Разблокировать позволяет досрочно открыть закрытый из-за превышения количества неудачных попыток доступ к статистике.

Счетчик обращений и лимит обращений - это защита от автоматизации пользователями получения информации о балансе (написание различных скриптов, запрашивающих статистику, что ведет к сильной загрузке сервера) возможно установление лимита на количество обращений к статистике (HTTP) запросов параметром web.max.day.request.count в конфигурации сервера биллинга.

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

Обращением считается каждая перегрузка страницы статистики (переход по ссылке в меню, вывод данных отчета). При превышение количества обращений пользователь будет перенаправлен на страницу, формируемую шаблоном limit_error.xsl.

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

23.2. Настройка внешнего вида страницы статистики

Для смены логотипа следует заменить файл BGBillingServer/webroot/img/logo.gif нужным логотипом. По умолчанию в дистрибутиве идет логотип оператора Synterra в качестве примера. Цветовую гамму Web интерфейса можно поменять в стилевой таблице style.css.

Отображаемый в браузере интерфейс может быть легко изменён с помощью шаблонов XSLT, расположенных в каталоге BGBillingServer/webroot/xsl. Можно добавить символику фирмы, рекламу и т.д. Каждый модуль добавляет свой шаблон в каталог при инсталляции. Главный шаблон - main.xsl.

Внимание

При каждом обновлении модуля и ядра XSLT шаблоны устанавливаются на стандартные, перетирая ваши изменения, XSLT файлы следует восстанавливать из резервной копии BGBillingServer.

Название пунктов меню в каждом модуле задаются в его конфигурации, например:

web.menuItem1=Счета
web.menuItem2=Счета-фактуры

Перечень пунктов вы можете найти в документациях к модулям. Если название пункта меню не указано, берётся значение по-умолчанию. Для того чтобы заблокировать пункт меню нужно поставить его название none. Например:

web.menuItem1=none

Внимание

Установите опцию xslt.cache=1 в конфигурации сервера биллинга до окончания правок шаблонов.

XSLT процессор получает XML данные от сервера и на основании шаблонов создаёт XML страницу. Чтобы просмотреть XML документ, на основании которого создаётся страница установите режим работы Web статистики в xml либо добавьте к URL в браузере строку &ct=xml, далее вызовите страницу и сделайте просмотр её исходного кода.

Возможно добавление в XML документ дополнительных данных по договору установкой опции в конфигурации сервера.

web.add.contract=1

Это создаёт дополнительную нагрузку на сервер биллинга, но позволяет разместить на странице пользователя дополнительную информацию, отсутствующую в стандартном дереве.

Таким образом на странице статистики можно разместить, например, некоторые параметры договора.

23.3. Новости

Отображаются на первой странице кабинета пользователя.

Для редактирования новостей зайдите в Сервис=>Редактор новостей. Нажмите кнопку Новый элемент, введите тему и текст новости. При неустановленном фильтре групп, новость будет отображена всем пользователям, иначе только выбранным группам.

Чтобы работали html теги необходимо заключить новость в xml теги <data></data>. В этом случае содержащаяся внутри информация должна быть правильным xml документом, т.е все теги должны быть закрыты, все атрибуты должны быть в ""

<data>
Поздравляем всех с <b>ПРАЗДНИКОМ</b>!!!<br/>
Желаем счастья и т.д и т.п
</data>

После того как клиент зайдёт на свою страницу статистики он увидит справа от меню вашу новость.

23.4. Смена пароля на доступ к статистике

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

23.5. Просмотр баланса, истории платежей, расходов и наработки

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

23.6. Временное понижение лимита

Данная функция появилась в версии 4.1 биллинга и аналогична функции "Обещанного платежа" других биллинговых систем. Для активации необходимо добавить в конфигурацию биллинга (меню Сервис=>Настройки).

Замечание

Управление лимитом доступно только договорам с режимом Дебет

#коды групп договоров для которых действует данная настройка, через ',' (чтобы узнать код группы нажмите Ctrl+i в справочнике 
#групп при выбранной строке таблицы)
contract.limit.1.groups=
#максимальное количество не оплаченных(не возвратившихся) понижений
#при котором клиенту будет доступно понижение, при 0 клиент не сможет выполнять
#понижение до тех пор пока будет хотя бы одно не оплаченное
contract.limit.1.maxnotpayoffed=
максимальное количество частично оплаченных понижений
#при котором клиенту будет доступно понижение (0-1, частично оплаченное понижение
#может быть только одно)
contract.limit.1.maxpartialpayoffed=
#количество просроченных платежей после последней разблокировки
#после которых доступ к понижению будет заблокирован
contract.limit.1.maxexpiredforblock=
#дни от до
contract.limit.1.mindays=
contract.limit.1.maxdays=
#сумма от до
contract.limit.1.minsumm=
contract.limit.1.maxsumm=
#нижний порог лимита при понижении клиентом (по умолчанию -100)
#т.е ниже этого порога клиент понизить не сможет
contract.limit.1.minlimit=

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

В случае если договор не входит хотя бы в одну из групп, указанных в конфигурации, для которых доступно понижение лимита или если режим договора не Дебет, меню Управление лимитом не отображается.

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

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

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

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

Понижение лимита доступно только при следующих условиях:

  • количество уже сделанных не погашенных понижений меньше либо равно переменной contract.limit.1.maxnotpayoffed конфигурации сервера

  • количество просроченных понижений меньше или равно переменной contract.limit.1.maxexpiredforblock конфигурации сервера

  • количество частично оплаченных платежей меньше или равно переменной contract.limit.1.maxpartialpayoffed конфигурации сервера

В случае если понижение недоступно, пользователь увидит страницу следующего вида.

В момент понижения система также контролирует следующие условия:

  • количество дней на которое понижается лимит должно быть от contract.limit.1.mindays до contract.limit.1.maxdays

  • сумма понижения должна быть от contract.limit.1.minsumm до contract.limit.1.maxsumm

  • в результате понижения лимит не должен стать менее чем contract.limit.1.minlimit

Оператор биллинга может индивидуально управлять доступом договора к сервису временного понижения лимита через вкладку Web=>Управление лимитом договора.

На вкладке Управление возможно включение/отключение данной возможности для конкретного договора. По умолчанию возможность включается для всех групп договоров, указанных в конфигурации (см. выше).

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

23.7. Пользовательские рассылки

Позволяют вашим клиентам самостоятельно через Web-интерфейс подписывать себя на различные рассылки. Пункт меню Подписка на рассылки.

Далее кнопка Добавить переводит вас в редактирование свойств рассылки, тип которой был выбран в выпадающем списке. У каждой рассылки собственные свойства, общими являются перечень адресов и активность/неактивность рассылки.

Рассылки добавляются по мере установки модулей/плагинов. В ядре системы присутствует только Рассылка баланса.

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

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

  • момент отправки рассылки попадает в период действия договора;

  • договор не помечен как "скрытый";

  • остаток баланса договора не ниже лимита.

Пользовательские рассылки рассылает задача планировщика Пользовательские рассылки. Рассылка будет приходить каждый рас при запуске этой задачи, поэтому рекомендуется ставить запуск на 1 - 2 раза в день не чаще.

23.8. Смена тарифных планов пользователем

Биллинг поддерживает возможность смены тарифов пользователями через Web интерфейс пользователя.

Процесс смены тарифа может быть изменён с штатной логики на любую другую путём обработки событий Смена тарифа по заданию пользователя и Запрос дат, с которых разрешена смена тарифа через Web. Примеры обработки данных событий вы можете посмотреть в WiKi.

Для предоставлению пользователю смены тарифов необходимо установить для договора группу(группы) тарифных планов. Если хотя бы группа тарифных планов не указана, то смена их через Web интерфейс невозможна. Группа определяет набор взаимозаменяемых тарифов доk