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


Содержание

1. Описание основной части программы BGBilling
1. Как построено данное руководство
2. Логическая структура биллинга
3. Программная структура биллинга
4. Особенности установки под различные платформы
4.1. Linux
4.2. Windows
5. Установка вспомогательного ПО
5.1. MySQL-сервер
5.2. JDK
5.3. ActiveMQ-сервер
6. Установка сервера биллинга
7. Установка и первый запуск клиента биллинга
8. Описание интерфейса клиента биллинга
9. Настройка подсистем биллинга
9.1. Конфигурации
9.2. Логирование
9.3. RADIUS-протокол
10. Настройка сервера биллинга
10.1. Конфигурация
10.2. Почтовая подсистема
10.3. Система оповещения
10.4. Закрытый период
11. Модули
12. Плагины
13. Установка обновлений биллинга
14. Установка лицензии биллинга
15. Настройка SSL между сервером и клиентом
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. Типы времени
18. Договор
18.1. Общие сведения, создание договора
18.2. Обзор карточки договора
18.3. Параметры договора
18.3.1. Общие сведения
18.3.2. Копирование параметров
18.3.3. Параметры типа "Текст", "Флаг", "Дата", "E-Mail"
18.3.4. Параметр типа "Адрес"
18.3.5. Параметр типа "Список"
18.3.6. Параметр типа "Телефон"
18.3.7. История изменения параметра
18.4. Группы договоров
18.5. Поиск договоров
18.6. Баланс
18.7. Лимит договора, режимы договора, управление лимитом
18.8. Режимы баланса договора
18.9. Статус договора
18.10. Тариф и группа тарифов
18.11. Примечания
18.12. Дополнительные действия
18.13. Подключение модулей и их услуг к договору
18.14. Карты регистрации договора
18.14.1. FOP-карточки
18.14.2. Полная карта договора
18.15. Шаблоны договоров
18.15.1. Шаблон имени
18.15.2. Лимит, лицо, режим, время жизни, статус
18.15.3. Модули
18.15.4. Прочие параметры
18.15.5. Создание договора по шаблону
18.16. Субдоговоры
18.16.1. Добавление субдоговоров
18.16.2. Зависимые субдоговоры
18.16.3. Независимые субдоговора
18.17. Переоформление договоров
18.18. Удаление договоров, архив договоров
19. Тарифные планы
19.1. Общие сведения
19.2. Редактирование тарифного поддерева
19.3. Расширение тарифных планов
19.4. Персональные тарифные планы
19.5. Порядок просмотра тарифных планов
19.6. Стандартные узлы тарифных планов
19.6.1. Услуга
19.6.2. Мультиуслуга
19.6.3. Период
19.6.4. Фильтр по времени
19.6.5. Фильтр по типу времени
19.6.6. Параметры тарификации
19.6.7. Использовать карту зон
19.6.8. Зона
19.6.9. Часть префикса и Диапазон префиксов
19.6.10. Стоимость минуты
19.6.11. Множитель цены
19.7. Тарифные опции
20. Объекты
21. Web-интерфейс пользователя
21.1. Общие сведения
21.2. Настройка доступа к статистике
21.3. Настройка страницы статистики
21.4. Новости
21.5. Просмотр баланса, истории платежей, расходов и наработки
21.6. Смена пароля на доступ к статистике
21.7. Смена тарифных планов
21.8. Тарифные опции
21.9. Карточки
21.10. Управление лимитом
21.11. Управление статусом
21.12. Дополнительные действия
21.13. Параметры договора
21.14. Примечания
22. Разграничение прав доступа
22.1. Пользователи, группы, права
22.2. Настройка дерева действий
22.3. Доступность пунктов меню в клиенте BGBillingClient
23. Сервис
23.1. Общие сведения
23.2. Журналы
23.2.1. Ошибки обработки логов
23.2.2. Ошибки периодических процессов
23.2.3. Журнал запросов
23.2.4. Журнал Web-запросов
23.3. Загрузка платежей и расходов из файла
23.3.1. Автоматическая загрузка реестров платежей
23.4. Групповые операции над договорами
23.4.1. Общие сведения
23.4.2. Операция "Изменение статуса"
23.4.3. Операция "Добавление группы тарифов"
23.4.4. Операция "Открытие тарифных планов"
23.4.5. Операция "Закрытие тарифных планов"
23.4.6. Операция "Добавление (Удаление) модулей"
23.4.7. Операция "Добавление разрешённых услуг"
23.4.8. Операция "Удаление(Прерывание на период) разрешённых услуг"
23.4.9. Операция "Смена тарифа"
23.4.10. Операция "Добавление скрипта"
23.4.11. Операция "Установка шаблона комментария договору"
23.5. Сообщения пользователям
23.6. Индикатор лицензии
23.7. SQL Редактор
24. Администрирование и оптимизация
24.1. Конфигурация базы данных, память
24.2. Поддержка репликации
24.3. "Мусорные" базы данных
24.4. Настройка типа хранения помесячных и подневных таблиц в MySQL
24.5. Параметры запуска клиента.
2. Расширение функциональности BGBilling
1. Назначение
2. Управление динамическим кодом
3. Скрипты поведения
3.. Общие сведения
3.2. Создание скрипта поведения
3.3. Привязка динамически загружаемых Java-классов к скриптам поведения
3.4. Написание функций скрипта поведения на языке BGBS
3.5. Привязка скриптов поведения к договору
4. Скрипты поведения глобальных событий
5. Глобальные скрипты
5.1. Глобальные скрипты с использованием динамических классов Java
5.2. Глобальные скрипты на языке BGBS
5.3. Периодическое выполнение глобальных скриптов
6. Резервные копии.
7. Скрипты предобработки RADIUS запросов
3. Модуль Card
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. Сверка платежей
4. Модуль Enaza
1. Назначение модуля
2. Базовые понятия и алгоритм работы модуля
3. Установка и настройка модуля
4. Инструкции по активации услуг компании Enaza
5. Клиентская часть
5. Модуль Gorod
1. Назначение модуля
2. Настройка модуля
3. Работа с реестрами
4. Использование модуля
6. Модуль RentSoft
1. Назначение модуля
2. Базовые понятия и алгоритм работы модуля
3. Установка и настройка модуля
4. Инструкции по активации услуг компании Рентсофт
5. Клиентская часть
6. Работа с юридическими лицами
7. Web интерфейс
7. Модуль TrayInfo
1. Назначение модуля
2. Конфигурация модуля
3. Создание типов логинов
4. Активация TrayInfo клиентом
5. Настройка утилиты TrayInfo
6. Отображение в утилите произвольной информации вместо баланса
8. Модуль Assist
1. Назначение модуля
2. Настройка модуля
3. Оплата через систему Assist
4. Мониторинг и администрирование платежей
5. Настройка автоматической установки статусов платежей
6. Настройка сети, фаервола и т.д.
7. Важные замечания
9. Модуль Bill
1. Назначение модуля
2. Краткий алгоритм работы модуля
3. Настройка модуля
3.1. Настройка позиций
3.1.1. Экстакторы
3.1.2. Детализация по тарифу
3.2. Номерной пул
3.3. Типы документов
3.4. Настройка банков
4. Настройка параметров договора
5. Выставление счетов и счетов-фактур администратором
6. Работа со счетами
6.1. Первичная подготовка для курьерской службы
7. Работа со счетами-фактурами
8. Панель просмотра документов
9. Генерация печатных форм
10. Отчёты договора модуля
11. Web-интерфейс пользователя
12. Тонкости интеграции с внешними (1С) системами
13. Групповые операции над договорами
13.1. Операция "Добавление ( Удаление ) типов документов"
10. Модуль Buyemoney (beta-версия)
1. Назначение модуля
2. Структура и настройка модуля
3. Настройка gpg-подписи для Yandex.Деньги
4. Настройка WebMoney
5. Использование модуля
11. Модуль BVCom
1. Назначение модуля
2. Настройка модуля
3. Оплата через систему BVCom
4. Мониторинг платежей
5. Возврат платежей
12. Модуль CerberCrypt
1. Назначение модуля
2. Настройка модуля
2.1. CerberCrypt
2.2. Pisys Irdeto
2.3. NordE/CTI
2.4. Conax
2.5. Тестовый
2.6. Настройка каналов/пакетов
3. Настройка клиентов
4. Дополнительные возможности для Irdeto Pisys, CTI/NordE итд
5. Типы оборудования
6. «Мультирум»
7. Настройка задач планировщика
7.1. Сопоставление договоров картам
7.2. Установка актуальных статусов пакетов в картах договоров
7.3. Начисление CerberCrypt
7.4. Блокировка должников
7.5. Обновление подписок
7.6. Постепенное продление подписок
7.7. Контроль синхронизации
8. Настройка тарифных планов
9. Возможности Web-интерфейса модуля
10. Создание договоров пользователем через Web
11. Виртуальный кинозал
12. Лог синхронизаций
13. Модуль DBA
1. Назначение модуля
2. Установка и настройка модуля
3. Использование модуля
14. Модуль DialUp
1. Назначение модуля
2. Базовые понятия и алгоритм работы модуля
2.1. SNMP и NetFlow
2.2. Режимы работы RADIUS сервера
2.3. Статус соединения
2.4. Работа с соединением
2.5. Порядок тарификации
2.6. RADIUS атрибуты
3. Настройка модуля
4. REALMы
5. Наборы атрибутов
6. Выдача атрибутов соединения и выделение IP адресов
7. Настройка NASов
7.1. Скрипт предобработки запроса
7.2. Пересылка RADIUS Accounting
8. Настройка RADIUS-сервера для DialUp
8.1. Установка BGRadiusDialup на Linux-платформу
8.2. Установка BGRadiusDialup на Windows платформу
8.3. Настройка radius.properties
8.4. Администрирование BGRadiusDialup
8.4.1. Управление BGRadiusDialup
8.4.2. Расширение словаря RADIUS
8.4.3. Антиспам
8.4.4. Поведение BGRadiusDialup при критических нагрузках
8.4.5. Оптимизация работы с базой данных
8.4.6. Reject-To-Accept
9. Настройка встроенного коллектора
9.1. Переобработка NetFlow трафиков
10. Настройка клиентов
10.1. Вкладка "IP-адрес"
10.2. Вкладка "Атрибуты RADIUS"
10.3. Вкладка "Ограничения"
10.4. Вкладка "Логи"
10.5. Вкладка "Пароль"
10.6. Перенос логинов
11. Настройка тарифных планов
11.1. Простейший тариф
11.2. Разделение стоимости по времени суток
11.3. Учётные периоды
11.4. Зависимость стоимости от объема
11.5. Комбинированные зависимости
11.6. Детализация по тарифу
11.7. Использование узла "Мультиуслуга"
11.8. Указание в тарифе свойств соединения
11.9. Уровни
11.10. Тарифные опции
11.11. Тарифы с переоценкой всего потребленного трафика
11.12. Ограничение по NASам
11.13. Узел "Конфигурация тарифа"
11.13.1. Блокировка отправки атрибутов REALMа
11.13.2. Фильтр по RADIUS-атрибутам пакета авторизации
12. Переобсчёт соединений
13. Монитор соединений
14. Интеграция с модулем "Карточки"
15. Отчёты
15.1. Отчёт по сессиям, детализация
15.1.1. Детализация трафика за сессию
15.1.2. Детализация трафика за месяц
15.2. Отчёт по наработке логинов
16. Web-интерфейс
17. Начисление наработки за максимальные трафики
18. Динамическое управление DNS-сервером
18.1. Пример настройки DNS сервера
18.2. Пример настройки модуля
18.3. Пример настройки логина
19. Настройка автозакрытия соединений
20. Поддержка CallBack
21. Настройка RADIUS-сервера с различными шлюзами CISCO
22. Настройка WiFi-агента для работы с модулем Dialup
22.1. Описание WiFi-агента
22.2. Установка, настройка и запуск
22.3. Связь WiFi-агента с модулем "Карточки".
22.4. Защита WiFi-сети от ARP-спуффинга
22.5. Настройка ограничения скорости (шейпинг) для трафика WiFi-сети.
22.6. Настройка REALMов
22.7. Web-интерфейс
15. Модуль DrWeb
1. Назначение модуля
2. Базовые понятия и алгоритм работы модуля
3. Установка и настройка модуля
4. Управление подписками
5. Web-интерфейс
6. Настройка тарифных планов
16. Модуль E-Mail
1. Назначение модуля
2. Установка и настройка модуля
2.1. Домены
2.2. Настройка конфигурации
2.3. Хранилище почтовых аккаунтов
2.3.1. LDAP база
2.3.2. SQL база
2.4. Настройка планировщика
3. Использование модуля
17. Модуль Inet
1. Назначение модуля
2. Базовые сведения о модуле
3. Настройка модуля
4. Трафики
5. Ресурсы
5.1. IP ресурсы
5.2. VLAN-ресурсы
5.3. Ресурсы интерфейсов.
6. Типы устройств
6.1. Обработчик активации сервисов
6.2. Обработчик процессора протокола
6.3. Обработчик управления устройством
7. Устройства
7.1. Корневые устройства
7.2. Интерфейсы
8. Опции
9. Типы сервисов
10. Сервисы
10.1. Шаблоны договоров
10.2. Дочерние сервисы
10.3. Поиск сервиса.
11. Тарифные планы
12. Сессии
13. Общий алгоритм модуля, установка и принципы настройки серверов
13.1. Установка серверов.
13.1.1. Установка Access-сервера.
13.1.2. Установка Accounting-сервера.
13.2. Общая часть конфигурации
13.3. Слушатель InetRadiusListener
13.3.1. Процессор ru.bitel.bgbilling.modules.inet.radius.InetRadiusProcessor
13.3.1.1. Посервисный аккаунтинг
13.3.1.2. Пример конфигурации устройства-NAS'а
13.4. Слушатель InetDhcpListener
13.4.1. Процессор ru.bitel.bgbilling.modules.inet.dhcp.InetDhcpProcessor
13.4.2. Процессор ru.bitel.bgbilling.modules.inet.dhcp.InetDhcpHelperProcessor
13.5. Слушатель InetFlowListener
13.6. Настройка BGInetAccess сервера
13.7. Настройка BGInetAccounting сервера
13.8. Общий алгоритм настройки
13.8.1. Пример настройка VPN доступа(PPPoE/PPPtp).
13.8.2. Пример настройки IPoE, управление доступом.
13.8.. Сбор netlow.
14. Монитор соединений.
15. Личный кабинет (web-статистика)
16. Интеграция с модулем Card
17. Переобработка логов.
18. Переобсчет.
19. Отчеты модуля Inet.
20. Коды ошибок авторизации
21. Настройка WiFi-агента для работы с модулем Inet
21.1. Описание WiFi-агента
21.2. Установка, настройка и запуск
21.3. Связь WiFi-агента с модулем "Карточки".
21.4. Защита WiFi-сети от ARP-спуффинга
21.5. Настройка ограничения скорости (шейпинг) для трафика WiFi-сети
21.6. Настройка REALM'ов
21.7. Web-интерфейс
18. Модуль IPN
1. Назначение модуля
2. Настройка модуля
3. Базовые понятия и алгоритм работы модуля
4. Привязки услуг (категории трафика)
5. Создание источников и интерфейсов
6. Управление ресурсами IP-адресов
7. Добавление адресов абонентам
7.1. Настройка выделения адресов в шаблоне договора
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. Установка типа правила в тарифе.
12. Настройка шлюзов
12.1. Настройка типов шлюзов
12.2. Настройка шлюза
12.3. Типы правил
12.4. Добавление шлюза в договор.
12.5. Выделение ресурса VLAN на шлюз.
12.6. Настройка портов шлюза.
12.7. Настройка шлюзов типа Manad
12.7.1. Спецификация Manad
12.7.2. Обработка команд Manad.
12.7.3. Настройка шлюзов типа Manad под FreeBSD
12.7.4. Настройка шлюза типа Manad под Linux
12.8. Настройка шлюзов типа Switch
12.9. Настройка шлюза BGRadiusIPN
12.10. Настройка шлюза CISCO
12.11. Настройка шлюза DLINK 35xx, 38xx
12.11.1. Настройка в связке с DHCP шлюзом.
12.12. Настройка сервера/шлюза DHCP
12.13. Настройка шлюза Mikrotik RouterOS
12.14. Настройка шлюза Cisco2 c коммутаторами
12.14.1. Настройка шлюза Cisco2
12.14.2. Настройка шлюза коммутатора Zyxel
12.14.3. Настройка шлюза DHCP в связке с Cisco2.
12.15. Реализация шлюза на языке BeanShell
13. Отчёты модуля, детализация
13.1. Детализация трафика за час
13.2. Детализация трафика за период
14. Web-интерфейс модуля
19. Модуль MOBI.Деньги
1. Назначение модуля
2. Настройка модуля
3. Проведение платежей
4. Мониторинг платежей
20. Модуль MPS
1. Назначение модуля
2. Настройка модуля
2.1. ОСМП, Empay, Pegas, Rapida, Comepay
2.2. CyberPlat
2.3. XPlat
2.4. Eport
2.5. SFOUR PayBox Alternative
2.6. ОПТИМА plus
2.7. Elecsnet
2.8. Юникасса
2.9. Quickpay
2.10. Sberbank
2.11. Сбербанк (sbrf)
2.12. Bisys
3. Сертификаты
4. Менеджер платежей
5. Сверка платежей
6. Web-интерфейс
21. Модуль MTSBank (шлюз МТСБанк)
1. Назначение модуля
2. Настройка модуля
22. Модуль NPay
1. Назначение модуля
2. Настройка модуля
3. Привязка абонплат к клиентам
4. Алгоритм начисления, примеры тарифов
4.1. Абонплаты, не зависящие от других модулей
4.2. Абонплаты, зависящие от наработки по объёму в других модулях
4.3. Абонплаты, зависящие от денежной наработки в других модулях
4.4. Абонплаты, пропорциональные количеству телефонов, логинов и сервисов
4.5. Абонплаты, зависящие от тарифных опций
5. Методики построения тарифных планов
6. Начисление
7. Дебетовые абонплаты
8. Групповые операции
8.1. Групповая операция "Добавление/прерывание абонплат"
23. Модуль Paylinks
1. Назначение модуля
2. Настройка модуля
3. Использование модуля
24. Модуль Paymaster
1. Назначение модуля
2. Настройка модуля
3. Оплата через систему Paymaster
4. Мониторинг платежей
25. Модуль PayOnline
1. Назначение модуля
2. Настройка модуля
3. Оплата через систему PayOnline
3.1. Простой платеж
3.2. Автоплатеж
4. Мониторинг платежей
5. Сверка платежей
26. Модуль Payture
1. Назначение модуля
2. Настройка модуля
3. Проведение платежей
4. Мониторинг платежей
5. Возврат платежей
27. Модуль Phone
1. Назначение модуля
2. Настройка модуля
3. Подготовка логов
4. Настройка загрузки и обработки логов
5. Географические коды, карты зон и цен
5.1. Карта зон
5.2. Карта цен
6. Управление ресурсами номеров
6.1. Добавление ресурсов
6.2. Слежение за ресурсами
7. Учёт абонентского трафика
7.1. Тарифы на местную связь
7.2. Тарифы на МГМН-связь
7.2.1. Тарификация по префиксам
7.2.2. Тарификация по зонам
7.2.3. Тарификация по карте цен
7.2.4. Тарификация с несколькими МГМН-операторами
7.2.5. Импорт и экспорт тарифных планов голосовых модулей
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. Транзитные операторы
8.4. Операторские отчеты
8.4.1. Общие сведения
8.4.2. Совинтел (ВымпелКом)
8.4.3. МТТ
8.4.4. Комстар
9. Тарификация при работе по агентской схеме
9.1. Составление тарифов при агентской схеме
9.2. Отчетность
10. Отключение абонентов.
11. Web-интерфейс
12. Черно-белые списки.
28. Модуль Qiwi
1. Назначение модуля
2. Настройка модуля
3. Оплата через кошелек Qiwi
4. Мониторинг платежей
29. Модуль RBK.Money
1. Назначение модуля
2. Настройка модуля
3. Оплата через систему PayOnline
4. Простой платеж
5. Мониторинг платежей
30. Модуль Reports
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. Табличные отчёты.
31. Модуль RSCM
1. Назначение
2. Установка и настройка модуля
3. Использование модуля
4. События модуля
32. Модуль Subscription (Подписки)
1. Назначение модуля
2. Настройка модуля
3. Привязка подписок к клиентам
4. Примеры тарифных планов модуля
5. Групповые операции
33. Модуль TV
1. Назначение модуля
2. Базовые сведения о модуле
3. Настройка модуля
4. Продукты, Сервисы, Каналы
4.1. Продукты
4.2. Сервисы
4.3. Каналы
5. Типы аккаунтов
6. Типы устройств
7. Устройства
8. Аккаунты
9. Тарифы
10. Переобсчет
11. Интеграция
11.1. IPTV Портал (iptvportal.ru)
11.2. FrontStage Middleware (TelecomTV, BCC)
11.3. Middleware Stalker (infomir)
11.4. CTI TVEngine
11.5. Модуль Inet
34. Модуль Vidimax
1. Назначение модуля
2. Настройка модуля
3. Принцип работы модуля
4. Мониторинг платежей
35. Модуль 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. Модификация стоимости звонка
10.6. Импорт/экспорт тарифов
11. Работа с операторами
11.1. Старая схема
11.2. Новая схема
11.3. Оценка операторов
12. Отчёты
13. Web-интерфейс
14. Переобсчёт сессий
15. Создание договоров пользователем через Web
36. Модуль WebMoney
1. Назначение модуля
2. Настройка модуля
3. Оплата через Merchant WebMoney Transfer
4. Безопасность
5. Слежение за платежами
6. Коды ошибок
37. Модуль Yandex.Деньги
1. Назначение модуля
2. Настройка модуля
3. Оплата через Yandex.Деньги
4. Слежение за платежами
38. Плагин 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. Настройка внешнего вида чеков (скрипты)
3.3. Настройка внешнего вида чеков (динамический код)
3.4. Разделение по отделам в ККМ
4. Использование плагина
4.1. Очередь печати
4.2. Лог распечатанных платежей
4.3. Выбор принтера, отчёты, сервис
4.4. Печать чека
4.5. Настройка галочки в диалоге прихода платежа
39. Плагин КЛАДР
1. Назначение плагина
2. Установка и настройка плагина
3. Использование плагина
40. Плагин CRM
1. Введение
2. Настройка плагина
3. Справочники
4. Журнал звонков
5. Журнал проблем
6. Журнал задач
7. Журнал работ.
41. Плагин Dispatch
1. Назначение плагина
2. Настройка плагина
3. Использование плагина
3.1. Общий обзор
3.2. Типы контактов
3.3. Методы отправки
3.4. Создание и редактирование рассылки
3.5. Подписка на рассылки
3.5.1. Контакты
3.5.2. Рассылки
3.5.3. Автоматизация подписки на рассылки с помощью групповой операции
3.6. Создание и редактирование сообщений
3.6.1. Модуль Inet
3.6.2. Модуль VoiceIp
3.6.3. Модуль DialUp
3.7. Условия отправки
3.7.1. Отправка по событию
3.7.2. Отправка по балансу
3.7.3. Ограничение частоты отправки
3.7.4. Ограничение по группе договора
3.7.5. Ограничение по адресу подписчика
3.7.6. Указание сервиса модуля Inet
3.7.7. Указание логина модуля VoiceIP
3.7.8. Указание логина модуля DialUp
3.8. Пользовательские классы сообщений
3.9. Web-интерфейс
3.9.1. Мои контакты
3.9.2. Мои рассылки
3.10. Конвертирование рассылок с версии 5.1
42. Плагин Documents
1. Назначение плагина
2. Установка и настройка плагина
3. Использование плагина
4. Шаблоны документов
5. Web-Интерфейс
43. Плагин HelpDesk
1. Назначение плагина
2. Алгоритм работы
3. Установка и настройка плагина
4. Работа с сообщениями
5. Работа с пакетами обращений
6. Web-интерфейс клиента
44. Плагин Organizer
1. Назначение плагина
2. Настройка плагина
3. Использование плагина
3.1. Общий обзор
3.2. Добавление задания
3.3. Просмотр текущих заданий
3.4. Поиск заданий
3.5. Выполнение заданий
3.6. Журнал
45. Плагин sbpilot
1. Назначение плагина
2. Структура и настройка плагина
3. Настройка утилиты sb_pilot
3.1. Донастройка в Linux
3.2. Донастройка в windows
4. Использование плагина
46. Плагин Bonus
1. Назначение плагина
2. Бонусные приходы
3. Бонусные расходы
4. Бонусный баланс
5. Бонусные программы
5.1. Операционная программа
5.2. Динамические программы
6. Настройка плагина
7. Web-интерфейс клиента
8. Шаблоны договоров
9. Групповые операции

Глава 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 браузер клиента) - позволяет пользователям просматривать и модифицировать свои параметры, а также получать оперативные отчёты по модулям (просмотр сессий, звонков и т.д.);
Сервер ActiveMQ - сервер для обмена событиями между серверными приложениями биллинга;
База данных MySQL - единое хранилище и связующее звено компонентов биллинговой системы.

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

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

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

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

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

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

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

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

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

4. Особенности установки под различные платформы

4.1. Linux

Установка всего серверного ПО производится под пользователем root.

В различных дистрибутивах Linux существуют разные схемы автоматического запуска служб при старте сервера. Со всеми серверными приложениями биллинга в каталоге scripts поставляются скрипты запуска с командами start и stop. Для простоты работа со службами везде описана применительно к системе sysvinit. Эта система самая старая и простая и поддерживается большинством дистрибутивов.

Все поставляемые скрипты ориентированы на командный интерпретатор Bash, либо совместимый (проверена работа с Dash), ссылка на который должна располагаться в файле /bin/sh. В случае, если у вас используется другой интерпретатор, либо отсутствует ссылка - поправьте скрипты

Рассмотрим способ добавления службы bgbilling.

1) Выполните команду runlevel, чтобы узнать уровень запуска.

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

2) Cкопируйте скрипт службы в /etc/init.d, установите права на выполнение.

chmod 755 /etc/init.d/bgbilling

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

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

Для запуска/остановки службы используйте /etc/init.d/bgbilling start (stop). Префикс ссылки S99 задаёт порядок старта сервиса.

4.1.1. Стандартные действия при установке

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

1) Установите права исполнения .sh файлов и удалите Windows скрипты.

rm -f *.bat && rm -f *.exe && rm -f *.ini && chmod 744 *.sh

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

dos2unix *.sh

4.2. Windows

Внимание

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

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

Некоторые конфигурационные или шаблонные файлы компонентов системы (например, настройки BGCashCheckServer) используют кодировку UTF-8. Следует учесть, что, по традиции, в операционной системе Windows свои подходы к любой технологии и поэтому сохранённое, например, в "блокноте" не является валидным UTF-8, обратите на это внимание. Пользуйтесь текстовыми редакторами, сохраняющими правильно.

Установка всего серверного ПО производится под пользователем, обладающим администраторскими привилегиями на машине.

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

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

Все серверные приложения устанавливаются в данной ОС как службы и доступны через меню Пуск=>Настройка=>Панель управления=>Администрирование=>Службы. Следует учитывать, что ОС Windows не позволяет настроить порядок запуска служб, предоставляя взамен механизм зависимостей. Поэтому все службы по умолчанию помечены зависимыми от MySQL и ActiveMQ. В случае, если данные службы устанавливаются на отдельных машинах, необходимо удалить зависимость в .ini файле службы перед её инсталляцией (например server.ini, scheduler.ini).

4.2.1. Стандартные действия при установке

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

del /F *.sh

5. Установка вспомогательного ПО

5.1. MySQL-сервер

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

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

После установки MySQL-сервера (см. далее) произведите его настройку в соответствии требованиями и рекомендациями по настройке MySQL-сервера с нашего WiKi.

Подключение к MySQL для каждого приложения настраивается в .properties файле, например 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 определяют имя пользователя и пароль, под которыми приложение будет подключаться к базе данных. Возможна настройка отдельного пользователя MySQL для каждого серверного приложения биллинга, это позволит сразу видеть источник запроса на MySQL-сервере.

Пользователь bill с паролем bgbilling создаётся при начальном создании БД при установке сервера биллинга (скрипт dump.sql).

5.1.1. *NIX

Для установки MySQL-сервера на *NIX-машине воспользуйтесь предусмотренным системой способом установки. Например, для Linux с пакетным менеджером yum:

yum install mysql, mysql-server

Служба сервера обычно устанавливается и стартует автоматически. Обратите внимание, что для заливки дампа базы помимо сервера MySQL вам понадобится клиентское приложение mysql.

5.1.2. Windows

Для установки MySQL-сервера на Windows-машине загрузите последнюю версию с сайта http://dev.mysql.com/downloads/mysql/. Рекомендуем устанвить MySQL Server в корень диска, например в папку C:\MySQL.

Служба сервера обычно устанавливается и стартует автоматически. Обратите внимание, что для заливки дампа базы помимо сервера MySQL вам понадобится клиентское приложение mysql.

5.2. JDK

Java - язык, на котором написан биллинг, является интерпретируемым и запускается с помощью специальной программы - Java-машины. Для нормальной работы необходимо JDK версии 1.6.0, либо выше. Последнюю версию для вашей платформы можно найти по адресу http://www.oracle.com/technetwork/java/javase/downloads. Необходимо загрузить именно Java SE JDK(Java-машина + средства разработки), а не JRE (только Java-машина), т.к. биллинг использует динамическую компиляцию кода, кроме того, средства разработки могут быть полезны при расследовании нештатных ситуаций в системе.

Обратите внимание, что для нормальной работы приложений биллинга необходима JDK производства Oracle. Соответственно, приложения биллинга, в общем случае, могут быть запущены на любой платформе, для которой выпускается JDK. Это Windows, Linux, Solaris. В официальной поставке включены скрипты запуска только для Linux (Bash скрипты, скрипты сервисов для RPM-дистрибутивов) и Windows (Batch).

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

5.2.1. Linux

Загрузите .bin файл (например jdk-6u2-linux-i586.bin), скопируйте его в директорию /opt/java (создайте, если её нет), перейдите в неё, дайте права на исполнение файла и запустите. Программа проинсталлируется в текущий каталог, создав подкаталог, например jdk1.6.0_02. Путь /opt/java/jdk1.6.0_02 является JAVA_HOME - путём к Java-машине. Для более удобного обновления Java в дальнейшем рекомендуем перейти в папку /opt/java и создать символическую ссылку /opt/java/jdk.

ln -s jdk1.6.0_02 jdk

В скриптах в качестве переменной JAVA_HOME указывать /opt/java/jdk.

Замечание

При использовании Gentoo Linux обнаружена проблема с некорректным определением java текущей временной зоны. Данная ошибка связана с тем? что Oracle 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, либо в любом другом логе.

5.2.2. Windows

Загрузите установочный .exe файл (например jdk-6u25-windows-i586.exe) и запустите его установку. Рекомендуем устанавливать ближе к корню диска, например C:\Java\Jdk-1.6.0. Иначе при установке в Program Files путь будет содержать пробелы, что неудобно при использовании в batch-файлах и командной строке.

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

Проверьте, что системная переменная JAVA_HOME указывает на каталог установки JDK, а также на наличие в переменной PATH пути до исполнимого файла java.exe. Команда java -version в консоли должна возвращать правильную версию Java-машины.

5.3. ActiveMQ-сервер

MQ (Message Queue)-сервер необходим для передачи сообщений между различными приложениями - компонентами системы. Он также важен для работы, как и сервер базы данных. В качестве MQ-сервера используется Apache ActiveMQ. Загрузите настроенную версию с нашего FTP ftp://ftp.bgbilling.ru/pub/bgbilling/. Загружать версию из каталога linux или win в зависимости от вашей ОС.

Главный конфигурационный файл ActiveMQ, использующийся по умолчанию, находится в conf/activemq.xml. Логины и пароли расположены в файле credentials.properties.

Обратите внимание на закомментированный фрагмент, в этом отрывке настраивается сеть серверов MQ - можно запустить несколько MQ-серверов, объединенных в одну сеть. При этом указывается имя сети (default).

<!--
       <networkConnectors>
            <networkConnector uri="multicast://default" dynamicOnly="true" 
                networkTTL="3" prefetchSize="1" decreaseNetworkConsumerPriority="true" />
        </networkConnectors>
-->

В ветке plugins указан параметр, при котором все сообщения, у которых истек timeToLive будут удаляться (по умолчанию они переносятся в очередь ActiveMQ.DLQ):

            <!-- drop messages that have been sent to the DLQ -->                                                                                                                                                                            
            <discardingDLQBrokerPlugin dropAll="true"/>  

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

        <systemUsage>
            <systemUsage>
                <memoryUsage>
                    <memoryUsage limit="128 mb"/>
                </memoryUsage>
                <storeUsage>
                    <storeUsage limit="10 gb"/>
                </storeUsage>
                <tempUsage>
                    <tempUsage limit="1 gb"/>
                </tempUsage>
            </systemUsage>
        </systemUsage>

В этом отрывке указывается тип коннектора для работы с сервером, интерфейс и порт:

        <transportConnectors>
            <transportConnector name="nio" uri="nio://127.0.0.1:61616" discoveryUri="multicast://default"/>
        </transportConnectors>

К этому порту будут подключаться к серверу MQ приложения биллинговой системы. Если все компоненты биллинга установлены на одном сервере, то можно оставить значение uri=nio://127.0.0.1:61616. Иначе нужно указать ip интерфейса, на который будут идти подключения или установить uri=nio://0.0.0.0:61616, чтобы порт был открыт на всех интерфейсах.

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

mq.url=failover:(nio://127.0.0.1:61616)
mq.user=bill
mq.pswd=bgbilling

Для локальной машины mq.url=failover:(nio://127.0.0.1:61616), для нескольких серверов (должна быть настроена поддержка сети серверов в каждом из MQ-серверов):

mq.url=failover:(nio://mq1.core.provider.org:61616,nio://mq1.core.provider.org:61616)

В последнем случае подключение будет к случайному из списка, если подключение невозможно - идет попытка подключения к следующему указанному серверу MQ, и так пока не установится подключение. Если второй сервер играет роль "запасного" - например, он установлен на слабой машине и должен принять работу только, если прервется работа первого сервера, то можно указать, чтобы подключение не устанавливалось к случайному, а попытки шли в указанном порядке:

mq.url=failover:(nio://mq1.core.provider.org:61616,nio://mq1.core.provider.org:61616)?randomize=false

5.3.1. Linux

Внимание

Убедитесь, что имя сервера с ActiveMQ указано в файле /etc/hosts. Имя сервера можно получить командой uname -n.

Пример установки ActiveMQ версии 5.4.2 в каталог /opt.

1) Перенесите каталог с ActiveMQ в /opt (/opt/apache-activemq-5.4.2);

2) Создайте символическую ссылку

ln -s /opt/apache-activemq-5.4.2/bin/linux-x86-32 /opt/apache-activemq-5.4.2/bin/linux

либо, если у вас 64х разрядная ОС

ln -s /opt/apache-activemq-5.4.2/bin/linux-x86-64 /opt/apache-activemq-5.4.2/bin/linux

3) Укажите в скрипте запуска /opt/apache-activemq-5.4.2/bin/linux/wrapper.conf переменную wrapper.java.command. Например:

# Java Application                                                                                                                                                                                                                                          
wrapper.java.command=/opt/java/jdk/bin/java 

4) Создайте ссылку на службу.

ln -s /opt/apache-activemq-5.4.2/bin/linux/activemq /etc/init.d/activemq

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

Логи выполнения хранятся в data/activemq.log и data/wrapper.log, по ним можно проследить безаварийный старт сервиса.

5.3.2. Windows

Настройте системную переменную ACTIVEMQ_HOME, указывающую на каталог установки ActiveMQ.

Перейдите в директорию ACTIVEMQ_HOME/bin/win32. Выполните InstallService.bat. После выполнения в списке служб Windows должна появится служба ActiveMQ.

Логи выполнения хранятся в data/activemq.log и data/wrapper.log, по ним можно проследить безаварийный старт сервиса.

6. Установка сервера биллинга

Для работы сервера биллинга необходима установка и запуск MySQL и ActiveMQ-сервера.

Извлеките из архива BGBillingServer_X.X_Y.zip файл dump.sql и BGBillingServer (X.X - номер версии, Y - билда) в каталог установки. Стандартный каталог установки для Linux /usr/local, для Windows - C:\.

Перенесите файл dump.sql на машину с MySQL-севером, если это отдельная машина. Перейдите в каталог в dump.sql, запустите

mysql --default-character-set=cp1251 < dump.sql

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

При необходимости скорректируйте параметры подключения к БД и ActiveMQ в data/data.properties. Там же можно скорректировать прослушиваемый порт, адрес, порт управления.

При успешном запуске (см.далее) в папке 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

6.1. Linux

Выполните стандартные действия, предшествующие установке приложения на Linux.

Установите переменную JAVA_HOME в файле setenv.sh.

JAVA_HOME=/opt/java/jdk

Замечание

Служба загрузчика логов (dataloader) используется только в модуле Phone. Если вы не используете этот модуль, можете её не устанавливать.

Создайте службы сервера, планировщика и загрузчика логов. Для этого используйте скрипты из BGBillingServer/script. Скрипт bgcommonrc таже необходимо перенести в /etc/init.d, он содержит общие переменные для скриптов сервера, планировщика и загрузчика логов.

Запустите сервер, планировщик задач и загрузчик логов.

/etc/init.d/bgbilling start
/etc/init.d/bgscheduler start
/etc/init.d/bgdataloader start

6.2. Windows

Выполните cтандартные действия, предшествующие установке приложения на Windows.

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

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

Замечание

Служба загрузчика логов (BGDataLoader) используется только в модуле Phone. Если вы не используете этот модуль, можете её не устанавливать.

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

Зайдите в управление службами и запустите службы BGBillingServer, BGScheduler, BGDataLoader.

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

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

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

2) Выполните стандартные действия для Linux, либо стандартные действия для Windows;

3) Для Linux пропишите переменную JAVA_HOME в начале .sh скриптов:

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

JAVA_HOME=/opt/java/jre

4) В каталоге 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

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

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

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

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

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

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

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

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

Замечание

Вы можете изменить файл, в котором сохраняются пароли и дополнительные соединения установив опцию -Dlocal.setting.file.name=<имя отличное от config> в скрипте запуска клиента, например так:

start javaw -Dupdate.folder=lib.update -Djavax.net.ssl.trustStore=.keystore -Dsun.net.client.defaultConnectTimeout=1000 -Xmx256m -Duser.language=ru -Duser.region=RU -Dlocal.setting.file.name=config_v.4.5 -cp %CLASSPATH% bitel.billing.ShellFrame

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

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

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

mysql -ubill -pbgbilling bgbilling

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.1. Горячие клавиши

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

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

На снимках экрана ниже пример идентификаторов (кодов) типов платежей и тарифного плана (получен нажатием Ctrl + i в редакторе тарифных планов).

8.2. Редактирование даты

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

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

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

Также можно редактировать дату при выделенном поле даты (т.е. имеющим фокус), но не нажатом, без открытого календаря. В этом случае Ctrl+стрелка вверх/Ctrl+стрелка вниз изменяют месяц, Ctrl+стрелка влево/Ctrl+стрелка вправо - дату, Ctrl+Insert - устанавливает текущее число, Ctrl+Delete - очищают значение.

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

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

8.3. Выпадающие списки

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

8.4. Таблицы

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

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

8.5. Постраничный вывод

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

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

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

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

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

8.6. Выбор договора

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

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

8.7. Отключение фонового рисунка

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

bg.enable=0

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

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

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

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

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

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

# определение значения
howYou=how you
# использование подстановки
some.kind.of.config.record=Thats {@howYou} should use macro!

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

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

Для быстрого комментирования отдельных строк и блоков: ctrl+shift+C.

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

Замечание

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

По умолчанию логи серверов сохраняются в папке log приложения. В качестве подсистемы логирования используется библиотека log4j. Конфигурирование логирования заключается в правке файла data/log4j.xml (log4j-radius.xml - для RADIUS-сервера, 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}${log.prefix}.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="${log.prefix}" />
  </filter>
 </appender>

 <appender name="MQ" class="org.apache.log4j.RollingFileAppender">
  <param name="File" value="${log.dir.path}${log.prefix}.mq.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="mq" />
  </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>
  <priority value="DEBUG" />
  <appender-ref ref="ASYNC" />
 </root>

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

<param name="Threshold" value="ERROR" />
 <appender name="MQ" class="org.apache.log4j.RollingFileAppender">
  <param name="Threshold" value="ERROR" />
  <param name="File" value="${log.dir.path}${log.prefix}.mq.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="mq" />
  </filter>
 </appender>

9.3. RADIUS-протокол

Замечание

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

RADIUS - протокол авторизации и аккаунтинга (передачи информации о соединении). В качестве транспорта используется UDP. Протокол бинарный, определяет формат передачи пакетов нескольких типов, в каждом из которых могут быть определены пары "атрибут-значение". NAS (Network Access Server) - сервер, через который происходит выход клиента с RADIUS-авторизацией.

Типы пакетов могут быть следующими:

1. AUTHENTICATION_REQUEST

Запрос авторизации, отправляется NASом RADIUS-серверу и содержит помимо идентификационной информации соединения, указанной выше, информацию о логине и пароле пользователя. Логин передаётся в открытом виде, пароль шифруется.

2. AUTHENTICATION_REJECT

Отказ в авторизации, может содержать атрибут с кодом ошибки.

3. AUTHENTICATION_ACCEPT

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

4. ACCOUNTING_REQUEST

Запросы аккаунтинга могут быть трёх типов: Start, Stop, Update. Различаются они атрибутом Acct-Status-Type который равен 1, 2 или 3 соответственно. Данный тип запросов передаёт на RADIUS-сервер информацию о ходе соединения (соединение началось, завершилось или текущее состояние соединения).

5. ACCOUNTING_RESPONSE

Ответ RADIUS-сервера о том, что он получил запрос аккаунтинга. Ответ не содержит никаких атрибутов. Исключение составляет ответ MPD-серверу, который может содержать атрибут, информирующий NAS о необходимости разрыва соединения.

Посредством RADIUS-атрибутов передаётся вся информация пакета. Все используемые атрибуты должны быть описаны в файле dictionary.xml. Фактически файл определяет соотнесение кодов атрибутов их строковым обозначениям и типам. Он необходим при разборе RADIUS-пакета и при его создании, для выяснения кода атрибута по его имени.

Замечание

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

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

Рассмотрим формат описания атрибута в словаре.

<attribute name="cisco-Fax-Connect-Speed" type="string" add="yes" code="8"/>

Где:

code - числовой код атрибута;
name - строковое обозначение, отображается в логах, указыается в конфигурации;
type - тип атрибута, возможные типы далее;
add - при установке в yes в пакете имя строкового атрибута дублируется в поле со значением, это особенность CISCO устройств.

Возможные типы атрибутов:

octets - последовательность байт;
string - текстовая строка;
integer - беззнаковое целое число, 4 байта;
ipaddr - IP-адрес, 4 байта;
abinary - текстовая строка с бинарными кодами.

Значения атрибутов в текстовых конфигурациях указываются в виде: <NAME>=<VALUE>, например: Framed-IP-Address=192.168.168.2. Для текстовой строки с бинарными кодами бинарный код указывается как \0x<code>, где <code> - код в 16-ичной системе счисления. Например: cisco-SSG-Command-Code=\0xC SERVICE А.

Тегированные атрибуты указываются в виде: <NAME>:<TAG>=<VALUE>, например: ERX-Activate-Service:2=testtest. Тегированный атрибут в словаре должен быть помечен атрибутом tag, который определяет логику для разных типов атрибутов.

Таблица 1.1. Логика тегирования

Тип тегирования/Тип атрибутаintegerstring
1Тег - первый байт значения, значение от 0x01 до 0x1F, если тегирования нет - его значение 0. Оставшиеся три байта - само число.Тег - первый байт значения, значение от 0x01 до 0x1F, если тегирования нет - его значение 0. Оставшиеся байты - значение строки.
2Не поддерживается.Если значение первого байта от 0x01 до 0x1F, то это тeг, иначе - первый байт - это начало значения, тэгирования нет.

При необходимости указания нескольких атрибутов они разделяются точкой с запятой, например: Framed-IP-Address=192.168.168.2;Service-Type=1;ERX-Activate-Service:2=testtest. Для указания точки с запятой в теле атрибута нужно писать её парно. Например: Framed-IP-Address=192.168.168.2;cisco-SSG-Service-Info=QU;;1024000;;512000;;D;;1024000;;512000.

Строковые представления для некоторых перечислимых числовых RADIUSатрибутов в данный момент не поддерживаются. Например, значению 1 атрибута Service-Type соответствует Login.

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

10.1. Конфигурация

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

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

#--------------------------------------
# Системные настройки сервера
#--------------------------------------
# Путь к временному каталогу, используется обработчиком логов для загрузки логов по FTP и сервером биллинга для хранения промежуточных файлов.
# Если не указан, то используется каталог BGBillingServer/tmp 
#temp.dir.path=
#
#-----------------------------------------
# Настройки интерфейса BGBillingClient
#-----------------------------------------
# Порядок элементов в дереве договора клиента
client.gui.contract.tree.order=parameters objects hierarchy status limit mode face 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
#
#--------------------------------------
# XSLT
#--------------------------------------
# Кэширование XSLT-шаблонов памяти: 1 - включить 
# Необходимо отключать опцию на момент модификации любых XSLT-шаблонов
xslt.cache=0

# XSLT-шаблоны для печати, отправки на e-mail, сохранения детализированного баланса и баланса в виде html и csv
#обычный баланс на e-mail и html
contract.balance.xslt=contract_balance_print.xsl
#обычный баланс при сохранении в csv
contract.balance.csv.xslt=contract_balance_print_csv.xsl
#Детализированный баланс на e-mail и html
contract.xslt=contract_balance_detail_print.xsl
#Детализированный баланс при сохранении в csv
contract.csv.xslt=contract_balance_detail_print_csv.xsl

# Заголовок и адрес к шаблону карточки (доступны в свойствах договора)
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
#
#--------------------------------------
#Копирование параметров договора - шаблоны
#--------------------------------------
# Шаблоны
contract.param.pattern.keys=bank,firm
# Название шаблона
contract.param.pattern.bank.title=Банк (реквизиты)
contract.param.pattern.firm.title=Организация (название, руководство, ИНН/КПП)
# Коды параметров договора, которые будут выделяться 
contract.param.pattern.bank.pids=12,34
contract.param.pattern.firm.pids=1,23,8,4,25
#
#--------------------------------------
# Параметр типа "Адрес"
#--------------------------------------
# проверка уникальности адреса договора при вводе - 1, 0 - не проверять
address.unique.check=1
# Формат адреса (доступен также параметр ${comment} - комментарий параметра)
addrs.format=(${index})(, ${city})(, ${area})(, ${quarter})(, ${street})(, д. ${house})(${frac})(, кв. ${flat})( ${room})(, ${pod} под.)(, ${floor} эт.)
# Разрешение создавать дома в редакторе адреса параметров договоров и объектов
#address.create=1
#
#--------------------------------------
# Параметры сущностей адресного справочника
#--------------------------------------
# Для каждой сущности можно завести неограниченное число параметров. Типы параметров могут быть числовые(int), строковые(string), дата(date)
## для страны
address.country=countPeople,test
address.country.countPeople.title=Население страны
address.country.countPeople.type=int
address.country.test.title=Тестовый параметр
address.country.test.type=string
# для города аналогично, но вместо country будет city
# для района аналогично, но вместо country будет area
# для квартала аналогично, но вместо country будет quarter
# для улицы аналогично, но вместо country будет street
# определение почтового индекса по номеру дома
address.street.boxIndexRange.title=Почтовый индекс
address.street.boxIndexRange.type=string
# для дома
address.house=dateConnecting, test, floorRange, entranceRange
address.house.dateConnecting.title=Дата подключения
address.house.dateConnecting.type=date
address.house.test.title=Тестовый параметр
address.house.test.type=string
# определение подъезда по квартире
address.house.entranceRange.title=Диапазон подъездов
address.house.entranceRange.type=string
# определение этажа по квартире
address.house.floorRange.title=Диапазон этажей
address.house.floorRange.type = string
#
#--------------------------------------
# Поведение 
#--------------------------------------
# Запрет ввода уже существующего на договоре тарифа с пересекающейся датой, 1 - включен
check.double.tariff=0
# Разрешение платежей и расходов будущим числом
allow.future.payment=0
allow.future.charge=0
# Разрешение платежей и расходов для закрытых договоров
allow.closed.payment=0
allow.closed.charge=0
# Что выводить в поле "сальдо" монитора статуса, 1 - сальдо, 2 - исх. остаток
contract.status.monitor.saldo.show.mode=1
# Запрет установки договору лимита без указания периода в случае наличия заданий на автоматическое изменение лимита, 1 - включение запрета
reject.limit.update=0
#
#-------------------------------------
# Статусы договора
#-------------------------------------
# Статусы договора, коды и обозначения
contract.status.list=0:Активен;1:В отключении;2:Отключен;3:Закрыт;4:Приостановлен;5:В подключении
# Статусы договора, запрещённые к ручной установке
contract.status.no.manual.set=1,5
# Не используемые статусы договора (не будут отображаться в списках, но останутся в логах изменений)
contract.status.deprected=
# При смене статуса договора смена статусов его независимых субдоговоров, 1 - включение
independ.subcontract.status.change=0
#
#--------------------------------------
# Статусы договора, кредитовые договора
#--------------------------------------
# Статус договора, при котором кредитовый договор считается активным
credit.contract.active.status=0
# Cтатусы договора, из которых кредитовый договор может быть переведён в активный статус по платежу
# в случае, если сальдо станет положительным
credit.contract.open.by.payment.status=2,3
# Cтатусы договора, которые перекрываются в будущем активным статусом, при открытии кредитового договора
credit.contract.override.future.to.active.status=2
# Не переводить статус договора в активный по платежу, тоже что пустой список credit.contract.open.by.payment.status
#do.not.open.contract.on.payment=1
# Перечень кодов групп договоров через запятую, которые не активируются по платежу
#do.not.open.groups.on.payment=
# 
#-------------------------------------
# Проверки закрытого периода 
#-------------------------------------
# Проверка закрытого периода при операциях, 1 - включить
closed.date.enabled=1
# Перечисления кодов групп пользователей, для  который проверка закрытого периода отключена
#closed.date.groups.id=1,2,3
# Выборочное отключение проверки закрытого периода
# (договор) удаление расхода 
#closed.date.disabled.ActionDeleteContractCharge=1
# (договор) удаление платежа
#closed.date.disabled.ActionDeleteContractPayment=1
# (договор) удаление Услуги
#closed.date.disabled.ActionDeleteContractService=1
# (договор) удаление группы тарифов
#closed.date.disabled.ActionDeleteContractTariffGroup=1
# (договор) удаление тарифного плана
#closed.date.disabled.ActionDeleteContractTariffPlan=1
# (договор) изменение расхода 
#closed.date.disabled.ActionUpdateContractCharge=1
# (договор) изменение Даты открытия
#closed.date.disabled.ActionUpdateContractDate1=1
# (договор) изменение Даты закрытия
#closed.date.disabled.ActionUpdateContractDate2=1
# (договор) изменение платежа
#closed.date.disabled.ActionUpdateContractPayment=1
# (договор) изменение Услуги
#closed.date.disabled.ActionUpdateContractService=1
# (договор) изменение группы тарифов
#closed.date.disabled.ActionUpdateContractTariffGroup=1
# (договор) изменение тарифного плана
#closed.date.disabled.ActionUpdateContractTariffPlan=1
# (договор) изменение периода обьектов
#closed.date.disabled.ActionObjectUpdate=1
# (договор) изменение статуса договора
#closed.date.disabled.ActionContractStatusChange=1
#
#----------------------------------------
# Планировщик заданий 
#----------------------------------------
# Количество одновременных потоков для выполнения периодических заданий по расписанию
scheduler.periodic.thread.count=5
# Количество одновременных потоков для выполнения асинхронных задач (переобсчёты)
scheduler.nonperiodic.thread.count=5
#
#--------------------------------------
# Загрузчик логов
#--------------------------------------
# Автоматическая генерация заданий на обработку логов
loader.add.process=1
#
#----------------------------------------
# Расширение функциональности 
#----------------------------------------
# Логирование вызовов функций скриптов поведения в договорах (1-логировать, 0-нет).
# Логируются выводы print, error и ошибки; после установки перезапустить BGBillingServer
log.function.process=1
#
#----------------------------------------
# Расширение функциональности - динамический код 
#----------------------------------------
# Кодировка файлов динамического кода
dynamic.src.encoding=UTF-8
# Каталог размещения динамического кода относительно BGBillingServer
dynamic.src.dir=dyn
#
#----------------------------------------
# BGSecure 
#----------------------------------------
# Проверка прав, 0 - не проверять
bgsecure.check=1
# Логирование действий в журнале событий, 0 - не логировать
bgsecure.log=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-авторизации
#mail.smtp.user=
#mail.smtp.pswd=
#
#----------------------------------------
# Система алармов - экстренных оповещений 
#----------------------------------------
# На какой адрес высылать оповещения, указать обязательно!
alarm.mail=
#
#----------------------------------------
# Web-интерфейс клиента 
#----------------------------------------
# Режим выдачи страниц: xml, либо html - сборка страниц браузером, либо на сервере
web.mode=html
# Разграничение доступа в личный кабинет:
# 1 - вошедший через логин субдоговора видит всю иерархию договоров (по умолчанию)
# 2 - вошедший через логин субдоговора видит только свой договор
#web.sub.contract.auth.mode=1
# Сохранять все ошибки входа (даже если не идентифицирован договор)
#web.error.all=1
# В режиме xml по этому пути браузер будет получать xsl
# Адрес должен быть доступен отовсюду
web.xslt=http://127.0.0.1:8080/bgbilling/xsl/
# В режиме xml при обращении через порт https по этому пути браузер будет получать xsl
# Адрес должен быть доступен отовсюду
web.xslt.https=https://127.0.0.1:8443/bgbilling/xsl/
# Добавление в XML на странице статистике детальной информации по договору - 1
web.add.contract=0
# Страница куда пересылать при выходе с Web-статистики
web.exit.redirect=about:blank
# Логирование Web-запросов пользователя (Web-интерфейс)
webquery.log=0
# Максимальный размер в байтах прикрепляемого файла в Web 
multipart.max.post.size=1048576
# Настройка страниц ошибок сервера по ошибкам (можно указывать различные коды ошибок)
server.error.404=/error/error404.html
server.error.403=/error/error403.html
#
#----------------------------------------
# Web-интерфейс, доступ 
#----------------------------------------
# MD5-хэш универсального пароля к Web-статистике, хэш можно получить в "Утилиты => Вычисление Digest"
#web.admin.password=21232F297A57A5A743894A0E4A801FC3
# Режим авторизации для доступа к Web-статистике код модуля:режим;код модуля 1:режим 
# модуль 0 - ядро
# режим 0 - не разрешена, 1 - по номеру договора, 2 - по текстовому параметру договора
web.auth.modes=0:1
# Максимально количество запросов для договора на сервер статистики в день, 0 - не ограничено
web.max.day.request.count=0
# Длина пароля договора для доступа к статистике
password.length.min=5
password.length.max=10
# Длина автоматически генерируемого пароля
password.length.auto=6
# Допустимые в пароле символы
password.chars=1234567890
#
#----------------------------------------
# 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
#
#-----------------------------------------
# Web-интерфейс, временное понижение лимита 
#-----------------------------------------
# сообщения при изменении лимита
limit.max.current.msg=Вы не можете в данный момент понизить лимит. Превышено максимально количество не погашенных и/или частично погашенных понижений
limit.max.nopayed.msg=Превышено максимально количество просроченных понижений. Возможность понижения лимита заблокирована
#

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

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

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

Внимание

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

10.2. Почтовая подсистема

Необходимо обязательно настроить опции почты:

# Настройки почты
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
# Имя хоста, отправляемое в команде EHLOW SMTP-серверу, если необходимо отличное от имени хоста, где запущено приложение биллинга.
# Параметр общий для для всех приложений биллинга, отправляющих почту, он может быть также указан в скрипте запуска приложения ключём -Dmail.smtp.localhost=<host>
# либо в .properties файле приложения
#mail.smtp.localhost=<имя хоста>
# Включение отладки 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

10.3. Система оповещения

В опции 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

Для каждого типа оповещения определен минимальный интервал между отправками писем. Интервал существует для избежания большого потока писем одного содержания. Он может быть изменён установкой опции конфигурации сервера биллинга alarm.min.interval.<key>=<seconds>, где:

<key> - идентификатор события, например db.master.connection.limit.over;
<seconds> - минимальное время в секундах между отправками писем по этому типу события.

Например:

alarm.min.interval.db.slave.connect.error=240

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

# Алармы, которые надо игнорировать. Ключи через запятую.
alarm.disabled=bad.java

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

#Алармы, которые направляются в log. Необходимо указать список ключей через запятую или символ "*", чтобы ВСЕ алармы писались в лог.
alarm.send.to.log=<keys>

Log-файл располагается в стандартном каталоге логов сервера и называется *.alarm.log. Также стоит отметить следующее: если ключ аларма указан и в опции alarm.disabled, и в alarm.send.to.log, то на почту оповещение не придет, но в лог запишется; если ключ указан только в alarm.send.to.log, то оповещение придет и на почту, и в log-файл; если же ключ указан в alarm.disabled, но его нет в alarm.send.to.log, то оповещение будет полностью проигнорировано.

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

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

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

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

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

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

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

  • если дата сущности лежит внутри закрытого периода, то невозможно любое изменение этой сущности;

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

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

  • если дата сущности лежит внутри закрытого периода, то удаление ее невозможно;

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

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

closed.date.types=<id1>:<title1>;<id2>:<title2>..

Где:

<idN> - уникальный код периода, целое число больше 1;
<titleN> - название периода.

Например:

closed.date.types=2:Период для платежей;3:Период для расходов

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

closed.date.type.<key>=<typeId>

Где:

<key> - ключ проверки, тот же, что используется для её отключения;
<typeId> - код периода.

Например, привязка проверки периодов при правке платежей и расходов к периоду с кодом 2:

closed.date.type.ActionUpdateContractPayment=2
closed.date.type.ActionDeleteContractPayment=2

11. Модули

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

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

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

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

Module dialup version 3.5 was successfull installed!

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

2. Договор абонента, узел дерева Модули;

3. Вкладка Отчёты.

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

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

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

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

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

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

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

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

12. Плагины

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

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

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

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

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

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

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

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

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

Для Linux.

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

Для Windows.

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

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

Для установки обновления пакет модуля, либо плагина необходимо установить повторно. Поддерживается автоматическое обновление с 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-шаблоны и многие другие файлы, заменяя их стандартными из пакета.

Для Linux также есть скрипт update.sh, который самостоятельно останавливает службы, запускает процесс обновления и стартует службы после. Кроме того, он сохраняет лог процесса обновления в файл.

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

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

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

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

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

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

./bg_installer.sh killhash <entity_id>

для Linux или

bg_installer.bat killhash <entity_id>

для Windows,

где <entity_id> - код сущности, для которой необходимо уничтожить кэш SQL-запросов (для ядра = 0; для плагина = код плагина из Плагины => Настройки плагинов; для экземпляра модуля = m<mid>, где <mid> - код экземпляра модуля из Модули => Редактор модулей и услуг).

Например:

./bg_installer.sh killhash m10

13.1. Обновление других серверных приложений

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

[root@bgb BGInetAccounting]# ./update.sh
Starting libraries updating. Requesting to BGBillingServer lib info.
 05-19/18:47:40  INFO [main] DefaultServerSetup - Binding javax.jms.ConnectionFactory[org.apache.activemq.ActiveMQConnectionFactory@1e3118a] to java:comp/env/mq/connectionFactory
mq 05-19/18:47:40  INFO [EventProcessor-init] EventProcessor - Init EventProcessor MQ connection factory...
May 19, 2011 6:47:40 PM org.apache.activemq.transport.failover.FailoverTransport doReconnect
INFO: Successfully connected to tcp://localhost:61616
mq 05-19/18:47:41 DEBUG [main] EventProcessor - Request, timeout 2000 : Event[bitel.billing.server.installer.event.GetLibrariesInfoEvent] timestamp: -1; moduleId: -1; pluginId: -1; cid: -1; scid: -1; userId: -1
Taking inet.jar...
mq 05-19/18:47:41 DEBUG [main] EventProcessor - Request, timeout 0 : Event[bitel.billing.server.installer.event.GetLibraryEvent] timestamp: -1; moduleId: -1; pluginId: -1; cid: -1; scid: -1; userId: -1
OK. Saving to lib.app.update.
Taking kernel.jar...
mq 05-19/18:47:41 DEBUG [main] EventProcessor - Request, timeout 0 : Event[bitel.billing.server.installer.event.GetLibraryEvent] timestamp: -1; moduleId: -1; pluginId: -1; cid: -1; scid: -1; userId: -1
OK. Saving to lib.app.update.
Update finished. Restart application.
05-19/18:47:45  INFO [Thread-3] EventProcessor - Shutdown EventProcessor...

После обновления новые библиотеки сохраняются в каталог lib.app.update и применяются только при перезапуске приложения.

Следите, чтобы все ваши серверные приложения были обновлены!

Замечание

Данная схема распространяется только на серверные приложения, связанные с ядром через JMS. Изолированные приложения обновляются отдельно. Такие приложения не содержат конфигурации доступа к MQ-серверу в конфигурационном файле, у них нет скрипта update и каталога lib.app.update. К таким приложениям относятся, например, DHCP-сервер модуля IPN, CashCheck-сервер.

13.2. Снапшоты

Замечание

В данный момент есть версия скрипта только для ОС Linux! Для Windows выполняйте требования по резервному копированию перед обновлением!

Для сохранения текущего состояния библиотек биллинга, каталога webroot, данных по установленным модулям и плагинам в БД с BGBilling поставляется скрипт snapshot.sh. Для создания снапшота вызовите перед обновлением:

./snapshot.sh create

Снапшоты сохраняются архивами в каталог BGBillingServer/snapshots. Для восстановления снапшота команда:

./shapshot.sh restore <FILE>

, где <FILE> - имя файла со снапшотом.

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

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

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

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

Замечание

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

Для того, чтобы получать оповещения о том, что лицензии скоро заканчиваются, в конфигурации сервера можно настроить такие параметры:

# 1- проверка лицензий включена, 0 - выключена(по умолчанию) 
need.lic.alarm=1
# Предупреждать, если  свободных лицензий осталоась меньше, чем X
lic.alarm.contract.limit=X
# Предупреждать, если  дней до конца действия лицензии осталось меньше, чем Y
lic.alarm.days.limit=Y
# Какие модули проверять. Если опция не указана , то проверяются все модули. 
lic.alarm.modules=ipn,dilaup

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

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

Замечание

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

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

Работа сертификатов основывается на паре асинхронных ключей. Необходимо создать их, для этого воспользуемся утилитой keytool, которая идет вместе с JRE/JDK:

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 сервера укажите:

connector.https=*:8443

и перезапустите его. Если нужно поднять биллинг на конкретном ip (интерфейсе) , то вместо "*" можно указать его, например "81.30.30.30: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 

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

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

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

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

Если столь высокая частота не требуется, можно уточнить параметры. Например, запуск задачи один раз месяц можно задать установкой Дни месяца в 1, Часы в 0, Минуты в 10. При необходимости несколько значений временных фильтров можно указывать через запятую. Для кратных количеств можно указывать строки вида */n, где n - кратность. Например, */8 для часов установит часы в строку вида 0,8,16. Также можно указывать диапазоны чисел через '-': 8-16.

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

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

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

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

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

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

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

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

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

Параметры работы планировщика настраиваются в конфигурации сервера.

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

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

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

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

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

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

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

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

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

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

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

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

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

flag=<флаг таймера>
cid=<список id договоров, для которых нужно выполнить скрипт>
gid=<список id групп, для договоров которых нужно выполнить скрипт>

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

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

17.1. Общие сведения

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

17.2. Адрес - страны, города, районы, кварталы, улицы, дома

Внимание

Используйте новый справочник адресов. Начиная с версии 5.3 старый справочник адресов будет убран.

Адресный справочник необходим для правки параметров договоров и объектов типа "Адрес". Основная сущность справочника - дом. Страны, города, кварталы, районы и улицы - это обычные перечисления, которые используются в справочнике домов. Города привязаны к странам. Кварталы, районы и улицы привязаны к городам. Дома привязаны к улицам. Адресный справочник доступен в меню Справочники=>Адреса или при нажатии комбинации клавиш Alt+A.

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

  1. подстрока - искомая сущность должна содержать введеную подстроку;

  2. начинается - искомая сущность должна начинаться с введенной подстроки;

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

  4. равна - искомая сущность должна совпадать с введенной подстрокой.

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

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

Редактор домов обладает большей функциональностью. В нем можно привязать дом к району, кварталу. Также можно указать индекс дома и кол-во квартир в нем.

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

Пример 1.3. Примеры заполнения параметра boxIndexRange

Заполнение параметра boxIndexRange.

Пример 1. Все дома на улице с одинаковым индексом

450000:*

Пример 2. Несколько диапазонов с разными индексами

450001:1-10,31-34;450002:11-30;45000:*

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

450023:7,3,5/a,1;450001:1-10,31-;450002:11-30

Для дома можно завести специальные параметры диапазонов, по которым будет автоматически рассчитываться подъезд и этаж указанной квартиры. Это параметры floorRange - для определения этажа по квартире , entranceRange - для определения подъезда по квартире. Они также заводятся в конфигурации сервера.

Пример 1.4. Примеры заполнения параметров floorRange и entranceRange

Заполнение параметра entranceRange.

Пример 1. Заполнение параметра для простого 9 этажного панельного дома, в котором 3 подъезда, диапазон квартир 1-108, кол-во квартир 4 на этаже и соответственно в одном подъезде 36 квартир.

1-108/36/1,

где первый параметр - диапазон квартир в доме/нескольких подъездах, второй параметр - количество квартир в подъезде, третий параметр - с какого подъезда начинается данный диапазон квартир.

Пример 2. Заполнение параметра для сложного дома.

1-72/36/1;73-132/60/3;133-168/36/4;169-187/19/5

Из примера видно, что в данном доме первые 2 подъезда стандартные по 36 квартир в подъезде, в 3 подъезде 60 квартир, в 4 - опять 36 квартир, а в 5 - 19 квартир. Соответственно ";" разделяются диапазоны квартир в нескольких подъездах.

Заполнение парметра floorRange.

Пример 1. Заполнение параметра для простого 9 этажного панельного дома, в котором 3 подъезда, диапазон квартир 1-108, кол-во квартир 4 на этаже и соответственно в одном подъезде 36 квартир.

1-108/4/1/9,

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

Пример 2. Заполнение параметра для сложного дома.

1-72/4/1/9;73-132/4/1/15;133-168/4/1/9;169-183/3/1/5;184-187/2/6/7.

Из примера видно, что в данном доме первый диапазон стандартный по 4 квартиры на этаже с 1 по 9й этаж (соответствует первым 2 подъездам в доме), второй диапазон 15 этажей и по 4 квартиры на этаже (соответсвует 3 подъезду в доме), третий диапазон 9 этажей по 4 квартиры на этаже (соответствует 4 подъезду в доме), четвертый диапазон с 1 по 5 этажи по 3 квартиры на этаже, пятый диапазон с 6 по 7й этаж по 2 квартиры на этаже. Четвертый и пятый диапазоны соответствуют 5 подъезду в доме. Соответственно, ";" разрделяется диапазон квартир на нескольких этажах.

На квладке Новые адреса выводятся адреса, заведенные через интерфейс "Пользовательское значение адреса" в редакторе адресного параметра договора.

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

17.3. Договоры - параметры

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

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

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

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

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

17.4. Договоры - группы параметров

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

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

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

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

17.5. Договоры - группы

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

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

17.6. Договоры - шаблоны комментариев

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

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

В шаблоне указывается Название шаблона, а также сам Шаблон. Шаблон - это произвольная строка, в которой возможна подстановка значений из параметров договора, путём включения макросов ${param_<pid>}, где <pid> - код параметра договора. Например: ${param_4} - подстановка значения параметра договора с кодом 4. При изменении параметров договора комментарий автоматически изменяется с учётом новых значений параметров.

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

17.7. Договоры - значения списков

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

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

17.8. Договоры - обслуживание

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

17.9. Договоры - скрипты поведения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

18. Договор

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

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

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

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

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

contract.params.copy.<pattern_id>=1,2,19

где pattern_id - код шаблона, по которому создается договор, а значение этой переменной является список id параметров договора.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

18.3.1. Общие сведения

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

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

О создании настраиваемых параметров договоров, их привязке к группам описано в описании справочника "Договор - параметры".

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

18.3.2. Копирование параметров

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

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

18.3.3. Параметры типа "Текст", "Флаг", "Дата", "E-Mail"

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

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

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

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

18.3.4. Параметр типа "Адрес"

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

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

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

Кроме выбора улицы из выпадающего списка предусмотрен второй вариант. Можно набрать в поле "Улица" название улицы или ее часть и нажать Enter (не выбирая при этом из выпадающего списка). При этом в таблицу будут выведены все найденные улицы, содержащие введенную строку в качестве подстроки. Далее, двойным щелчком по строке таблицы выбирается нужная улица, после чего в таблицу загружаются дома, расположенные на этой улице. Описанный режим поиска улиц полезен, если требуемая улица отсутствует в выпадающем списке (ввиду ограничения в 25 записей).

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

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

Установкой опции конфигурации сервера address.create=yes можно разрешить добавление недостающего дома непосредственно при редактировании параметра. При этом пользователю будет доступна кнопка "Добавить новый дом..." в режиме поиска дома. При нажатии на нее редактор перейдет в режим создания нового дома.

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

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

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

Формат адреса настраивается с помощью параметра addrs.format.pattern.<ID>, где в качестве <ID> может выступать любой уникальный идентификатор: будь то строка или число. Есть также некоторые особенности: если в начале идентификатора указывается cp (ContractParameter - параметр договора типа Адрес) или ор (ObjectParameter - параметр объекта типа Адрес), то после такого идентификатора необходимо указывать pid (из меню Справочники->Другие->Договоры-параметры) того адресного параметра, которому необходимо задать формат.

Примеры:

addrs.format.pattern.1=(${index})(, ${city})(, ${area})(, ${quarter})(, ${street})(, д. ${house})(${frac})(, ${flat})( комната ${room})(, ${pod} подъезд)(, ${floor} этаж)(, [${comment}])
addrs.format.pattern.2=(${index})(, ${city})(, ${street})(, д. ${house})(${frac})(, ${flat})(, [${comment}])
addrs.format.pattern.3=(, ${city})(, ${street})(, д. ${house})(${frac})(, ${flat})(, [${comment}])
addrs.format.pattern.cp19=(, ${city})(${index})(, ${street})(, д. ${house})(${frac})(, ${flat})
addrs.format.pattern.op6=(улица ${street})(, дом ${house})(${frac})(, кв. ${flat})(, комн. ${room})
addrs.format.pattern.cp58=(улица ${street})(, дом ${house})(${frac})(, квартира ${flat})

Формат адреса - это REGEXP, в котором прописаны определенные переменные. В качестве переменных можно использовать: ${index} - индекс; ${city} - город; ${area} - район; ${quarter} - квартал; ${street} - улица; ${house} - дом; ${frac} - дробь; ${flat} - квартира; ${room} - комната; ${pod} - подъезд; ${floor} - этаж; ${comment} - комментарий параметра.

Для корректной работы форматов адресов необходимо указывать в конфигурации параметр addrs.format.list, в котором прописать порядок следования форматов друг за другом. В соответствии с этим списком будет заполнена таблица Формат адреса. Соответственно, некоторые форматы можно и не включать в список - тогда они не будут отображаться в таблице. Пример:

addrs.format.list=1;cp19;3;cp58;op6

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

Если параметр addrs.format.list не указывается в конфигурации, то в конфигурации ищется параметр addrs.format, если и он не будет найден, то в таблице будет только 1 формат по умолчанию. Примеры с использованием параметра addrs.format:

addrs.format=(${city})(, ${street})(, д. ${house})( , дробь ${frac})(, квартира ${flat})
addrs.format.cp58=( ${city})(, ${street})(, д. ${house})(${frac})(, ${flat})(, [${comment}])

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

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

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

18.3.5. Параметр типа "Список"

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

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

18.3.6. Параметр типа "Телефон"

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

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

Формат вывода номера телефона задается в конфигурации параметрами 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

В редакторе телефона разрешенная длина номера равна 11, но разрешенную длину можно дополнить своим значением. Для этого в конфигурации параметрами заведите параметр phones.customLengthNumber.

phones.customLengthNumber=12

С данным параметром в редакторе можно будет набрать номер состоящий из 11 и 12 цифр. Внимание! Максимальная длина номера, даже с этим параметром, не может превышать 14.

18.3.7. История изменения параметра

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

Если текстовый параметр содержит гиперссылку, то она выделится синим и подчеркнётся. Редактировать её можно как обычный текстовый параметр. Чтобы "кликнуть" по ней, как по гиперссылке, нужно зажать клавишу Ctrl - ссылка откроется в браузере по умолчанию. Для всех типов параметров вызвать соответствующий редактор можно как двойным кликом мышью, так и клавишей Enter.

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

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

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

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

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

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

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

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

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

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

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

Для параметра типа Адрес выбираются город, улица, номер дома (дробь), квартира и комната, в которых будет произведён поиск. Для того, чтобы искаль по городам, в поле улица нужно начинать вводить название города начиная с *(. Например: *(Уфа).

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

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

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

Также доступны следующие опции:

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

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

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

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

18.6. Баланс

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

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

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

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

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

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

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

Баланс отображается в табличном виде в формате : "Месяц, год - Входящий остаток - Приход - Наработка - Расход - Исходящий остаток".

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

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

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

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

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

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

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

Замечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

contract.status.list=0:Активен;1:В отключении;2:Отключен;3:Закрыт;4:Приостановлен;5:В подключении

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

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

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

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

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

Не все статусы доступны для ручной установки, перечень запрещённых задаётся переменной конфигурации сервера contract.status.no.manual.set. Данные статусы могут устанавливаться, например, скриптами.

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

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

При смене статуса супердоговора изменяются статусы его зависимых субдоговоров. Включить смену статусов независимых договоров можно опцией конфигурации сервера independ.subcontract.status.change=1.

18.9.1. Настройка активных статусов в модулях

Статусы экземпляра модуля, в которых сервис доступен, указываются в переменной конфигурации модуля contract.status.active.codes. Коды статусов указываются через запятую. Например.

contract.status.active.codes=0

Статусы, в которых сервис считается приостановленным указываются в переменной contract.status.suspend.codes. Например.

contract.status.suspend.codes=3,4

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

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

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

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

Для кредитовых договоров статус тесно завязан с системой работы с кредитовыми должниками. Он может изменятся в результате оплаты договора. Активный статус для кредитовых договоров задаётся переменной конфигурации сервера credit.contract.active.status. Например.

credit.contract.active.status=0

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

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

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

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

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

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

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

В случае, если отключенный статус попадает в перечень из переменной конфигурации credit.contract.open.by.payment.status, договор может быть возвращён в активный статус по приходу платежа, если сальдо станет положительным.

По звонку отключенного клиента с обещанием оплаты оператор может перевести его в активный статус на несколько дней. При этом период активного статуса указывается с датой открытия и закрытия. Если до окончания периода клиент не оплатит, отключенный статус станет действующим и клиента заблокирует. В случае оплаты вновь установленный активный статус перекроет будущий отключенный. При этом перекрытие производится только для статусов, которые указаны в переменной конфигурации credit.contract.override.future.to.active.status.

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

Если по каким-либо причинам такое поведение статусов нежелательно, то можно отключить автоматическую активацию договора при изменении сальдо на положительное. Для этого в концигурации сервера необходимо указать флаг do.not.open.contract.on.payment=1. Отсутствие этой записи или установка флага в 0 оставит поведение по умолчанию.

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

do.not.open.groups.on.payment=X,Y,Z,...

Где X, Y, и Z - это номера групп договоров, для которых стандартное поведение нежелательно.

18.9.4. Изменение стандартной логики перетирания статусов

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

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

Возможность включается установкой в конфигурации сервера флага

# Использовать ли событие Задание логики установки/перетирания статусов (иначе используется стандартное поведение)
use.event.set.status.logic=1

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

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

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

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

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

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

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

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

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

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

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

Cообщения о выполненых действиях возможно создавать в виде 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.

Замечание

XSLT-шаблон card_inet.xsl можно использовать как пример, поправив его под ваши модули. Шаблон необходимо переименовать, чтобы избежать его перетирания при обновлении.

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

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

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

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

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

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

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

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

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

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

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

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

18.15.1. Шаблон имени

Шаблон имени задает имя договора сразу после создания, при пустом поле сразу после создания договор называется 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.15.2. Лимит, лицо, режим, время жизни, статус

Второй ряд элементов управления позволяет установить параметры:

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

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

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

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

  • статус (подключен, отключен, закрыт, приостановлен) - выбор статуса при создании договра.

18.15.3. Модули

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

18.15.4. Прочие параметры

Прочие параметры, устанавливаемые на вкладках правее вкладки Модули:

18.15.5. Создание договора по шаблону

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При изменении статуса супердоговора изменяются статусы его зависимых субдоговоров.

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

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