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

Установка всего серверного ПО производится под пользователем 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 задаёт порядок старта сервиса.

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

dos2unix *.sh

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

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

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

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

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

del /F *.sh

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=UTF-8&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).

yum install mysql, mysql-server

SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'colla%';

[client]
default-character-set=utf8
[mysqld]
character-set-server=utf8
collation-server=utf8_unicode_ci
init_connect="SET collation_connection = utf8_unicode_ci;"

Java - язык, на котором написан биллинг, является интерпретируемым и запускается с помощью специальной программы - Java-машины. Для нормальной работы необходимо JDK версии 1.7.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.

ln -s jdk1.6.0_02 jdk

# 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

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

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

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

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

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

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

Конфигурации вводятся либо в текстовых 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.

По умолчанию логи серверов сохраняются в папке 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>

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"/>

Где:

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

Значения атрибутов в текстовых конфигурациях указываются в виде: <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, который определяет логику для разных типов атрибутов.

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

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

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

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

# Заголовок и адрес к шаблону карточки (доступны в свойствах договора)
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
# Отключение учёта при активации тарифной опции уже активированных опций
#tariffOption.dontCheckOnActivateAlreadyActivated=1
#
#-------------------------------------
# Статусы договора
#-------------------------------------
# Статусы договора, коды и обозначения
contract.status.list=0:Активен;1:В отключении;2:Отключен;3:Закрыт;4:Приостановлен;5:В подключении
# Статусы договора, запрещённые к ручной установке
contract.status.no.manual.set=1,5
# Не используемые статусы договора (не будут отображаться в списках, но останутся в логах изменений)
contract.status.deprecated=
# При смене статуса договора смена статусов его независимых субдоговоров, 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
#
#----------------------------------------
# Расширение функциональности - динамический код 
#----------------------------------------
# Кодировка файлов динамического кода (UTF-8 предпочтительно, по умолчанию)
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=UTF-8
# Параметры 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=Превышено максимально количество просроченных понижений. Возможность понижения лимита заблокирована
#

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

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

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

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

# Настройки почты
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=UTF-8
# Имя хоста, отправляемое в команде 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, либо UTF-8, либо 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

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

Например: "[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>, где:

Например:

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, то оповещение будет полностью проигнорировано.

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

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

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

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

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

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

Где:

Например:

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

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

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

Где:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Порядковый именованный параметр шаблона имени договора позволяет вставить номер в имя договора при создании из шаблона. Подробности о шаблонах имени. Он идентичен подстановке ${NX} но обладает следующими преимуществами:

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

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

При создании необходимо указать следующие данные:

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

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

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

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

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

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

Заменить - пользовательское значение заменится на значение из справочника.

Аналогично c Значения мультисписков и Пользовательские значения мультисписков

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для поиска по примечанию необходимо написать часть текста, содержащегося в примечании договора и нажать на кнопку >>> или клавишу Enter.

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

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

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

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

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

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

Для того чтобы включить влияние резервов на баланс договора, необходимо добавить параметр в конфигуратор сервера: contract.balance.reserve.influenceToBalance=true. А после перезапустить сервер. Если не включать, тогда резервы могут нести некий информационный характер.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

contract.status.active.codes=0

contract.status.suspend.codes=3,4

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

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

credit.contract.active.status=0

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

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

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

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

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 - это номера групп договоров, для которых стандартное поведение нежелательно.

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

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

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

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

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

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

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

Дополнительные действия в договоре - это возможность непосредственного вызова скрипта 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>" );

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

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

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

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

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

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

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

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

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

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

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

• ${NS_name} -именнованный порядковый номер договора, name - имя именованного параметра, предварительно вам необходимо его создать в справочнике. Подстановка будет заменена порядковым номером договора.

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

• ${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.3. Модули

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# При занесении расходов, показывать баланс, а не сальдо для кредитовых договоров
client.gui.payment.show.balance.for.credit.contract=1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1) По названию;

2) по используемости;

3) по модулям;

4) по меткам.

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

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

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

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

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

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

В разделе Метки можно назначить тарифу одну и более меток, по которым его в дальнейшем возможно отфильтровать.

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

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

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

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

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

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

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

Для удаления узла выберите Удалить узел в контекстном меню узла.

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

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

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

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

В оставшихся модулях считывание производится при первом обращении к дереву после его правки. Т.е. при правке дерева необходимо стараться уменьшить время, когда оно пребывает в неконсистентном состоянии. Отчасти проблема сглаживается тем, что для тарификации реального времени (DialUp-модуль) дерево кэшируется в момент авторизации соединения и далее не изменяется даже, если будет поправлено. Т.е. правка дерева может вызвать только временные проблемы с авторизацией соединений. Для периодической тарификации (IPN, RSCM и т.п.) дерево также загружается в момент начала обсчёта и далее используется. Т.е. проблема может возникнуть только, если на начало периодической тарификации дерево некорректно, повторый переобсчёт проблему устраняет.

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

Механизм расширения позволяет создать модульное поддерево на основании существующего поддерева аналогичного модуля из другого тарифа, добавив в него новые узлы. Например, с его помощью можно переопределять цены. Рассмотрим для примера "Тариф1" и "Тариф2", модульное поддерево экземпляра модуля "INET" которого получено путём расширения модульного поддерева первого тарифа.

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

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

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

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

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

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

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

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

Алгоритм 1:

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

Алгоритм 2:

Для каждой из тарифицируемых сущностей (услуга, тип трафика) ищется последовательно цена в списках 1 и 2. Как только находится тариф с ценой - поиск прекращается.

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

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

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

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

19.6.1. Услуга

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

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

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

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

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

19.6.3. Период

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

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

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

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

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

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

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

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

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

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

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

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

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

Либо так:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19.6.8. Зона

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19.6.12. Элемент каталога

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

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

Доступны в Справочники => Тарифные опции.

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

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

На второй - указываются режимы активации опции.

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

Режимы периода: часов - опция активируется с текущего момента на указанное количество часов; часов со следующего - c 00:00 следующего часа на указанное количество часов; часов с текущего - с 00:00 текущего часа на указанное количество часов; дней - с текущего момента на указанное количество дней; дней со следующего - с 00:00:00 следующего дня до (не включая) 00:00:00 через указанное количество дней; дней с текущего - с 00:00:00 текущего дня. Аналогично для месяцев и недель.

Если количество часов (дней/месяцев/недель) указано 0, то опцию можно будет деактивировать. Режимы деактивации: моментально - с момента отработки заброса; до конца дня - до (не включая) 00:00:00 следующего дня; до конца недели - до (не включая) 00:00:00 понедельника следующей недели; до конца месяца - до (не включая) 00:00:00 первого числа следующего месяца. В этом случае также можно указать возможность реактивации: если режим деактивации установлен не "моментально" и опция была деактивирована, а время окончания еще не наступило, то клиент сможет реактивировать тарифную опцию.

Если сумма в поле Снять расход больше нуля, то при активации опции проверяется, баланс - сумма >= лимита. Если средств не достаточно, опция не активируется, иначе - перед активацией снимается расход указанного типа.

На третьей закладке указываются зависимости редактируемой опции от других.

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

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

Периоды пересечений сравниваются с точностью до секунды.

В Web-интерфейсе клиент выбирает опцию и режим активации для нее.

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

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

По умолчанию страница статистики доступна по адресу: http://<адрес сервера биллинга>:8080/bgbilling/webexecuter. Путь контекста (/bgbilling) может быть исправлен в файле конфигурации BGBillingServer/data/data.properties переменная context.path, в т.ч. установлен пустым (context.path=/).

При входе клиента на эту страницу происходит его перенаправление на страницу авторизации.

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

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

Текущий пароль статистики, установленный после создания договора, можно посмотреть в полной карте договора (вкладка Карточки=>Полная карта в договоре).

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

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

web.auth.modes=0:1

Данное значение стоит по умолчанию и обозначает, что разрешена авторизация на странице статистики по номеру договора + паролю (вкладка Пароль в карточке договора).

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

web.auth.modes=0:2
# Код параметра договора, значение из которого будет использоваться в качестве логина.
web.auth.contract.text.parameter=<код параметра>

Страница авторизации пользователя формируется шаблоном login.xsl. В стандартной поставке шаблон содержит только форму авторизации по номеру договора (либо текстовому параметру договора) и паролю.

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

web.exit.redirect=about:blank

По умолчанию это пустая страница, но вы можете разместить здесть URL страницы провайдера.

Сервер определяет тип авторизации по передаваемому в форме авторизации параметру midAuth=<коду модуля>. Если параметр отсутствует - авторизация идет по номеру договора (либо текстовому параметру договора) + паролю доступа к статистике.

Пример 1.5. Пример авторизации по логину

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

web.auth.modes=0:1;21:1

Теперь раскомментируйте вторую форму авторизации в login.xsl.

<form method="post" action="webexecuter">
<input type="hidden" name="midAuth" value="21"/>
 <table align="center" width="300px" class="filter" style="margin-top:20px;">
  <tr>
   <th align="left">Логин DialUP:</th>
   <td><input class="logon" type="text" name="user" SIZE="15"/></td>
  </tr>
  <tr>
   <th align="left">Пароль DialUP:</th>
   <td><input class="logon" type="password" name="pswd" SIZE="15"/></td>
  </tr>
  <tr>
   <td></td>
   <td><input type="submit" value="Вход" style="width: 100%; border: 1px solid #404040;"/></td>
  </tr>
 </table>
</form>

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

Аналогично можно добавить авторизацию по логину и паролю Voip-модуля. Возможно в midAuth-параметре формы передавать несколько модулей через запятую, 0 - код модуля ядра. При этом будет осуществлен последовательный поиск в указанных модулях. Модуль должен быть разрешен в web.auth.modes.

Так же для модуля Dialup есть отдельный режим авторизации по ip-адресу сессии. Пусть 21 - это код модуля Dialup, тогда этот режим настраивается так

web.auth.modes=0:1;21:2

Где 2- означает авторизацию по ip-адресу сессии. При этом сравнивается http-заголовок с ip-адресом переданный в http-запросе и Ip-адрес сессии абонента.

Имя http-заголовка, в котором хранится ip адрес, задается параметром

header.name.remote.addr=

в конфигурации сервера.

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

21.2.1. Восстановление пароля

С помощью системы восстановления пароля пользователь может произвести отправку пароля на E-Mail.

В поле Номер договора пользователь должен ввести номер своего договора, а в поле E-mail - почтовый адрес, который должен совпасть со значением текстового параметра договора, содержащим E-Mail-адрес для восстановления пароля. Код этого параметра указывается в конфигурации сервера биллинга contract.password.forgot.email.param.id=<числовой код параметра>.

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

21.2.2. Защита от подбора пароля

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

Временные характеристики защиты могут быть настроены в конфигурации сервера. Переменная logon.counter.max задает максимальное количество неудачных попыток авторизации для договора подряд. После каждой попытки может быть установлен таймаут, базовый размер которого определяется переменной logon.timeout.period. После первой неудачи таймаут равен периоду, после второй - двум периодам, затем трем и т.п. Алгоритм увеличения периода задается переменной logon.timeout.action. После исчерпания logon.counter.max попыток авторизации договор блокируется на время logon.timeout.lock секунд.

Оператору биллинга на вкладке Web договора доступны функции мониторинга доступа к Web-статистике.

На вкладке Входы отображаются входы на Web-статистику. На закладке Ошибки - ошибки авторизации с отображением введенных логина и пароля. Кнопка Разблокировать позволяет досрочно открыть закрытый из-за превышения количества неудачных попыток доступ к статистике.

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

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

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

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

Для смены логотипа следует заменить файл BGBillingServer/webroot/img/logo.gif нужным логотипом. По умолчанию в дистрибутиве идет логотип оператора Synterra в качестве примера. Цветовую гамму Web-интерфейса можно поменять в стилевой таблице style.css.

Страницы Web-интерфейса пользователя собираются из XML-документа с использованием XSLT-шаблона. Каждый модуль и плагин помещает свои XSLT-шаблоны в каталог BGBIllingServer/webroot/xsl. Модифицируя их, вы можете настраивать оформление страницы пользователя. Главный шаблон - main.xsl.

Web-интерфейс может работать в двух режимах: xml и html. Режим задается переменной web.mode конфигурации сервера биллинга. В xml режиме клиент получает XML-документ со ссылкой на XSLT-шаблон преобразования и браузер самостоятельно собирает страницу. В режиме html клиенту отдается собранная биллингом XHTML-страница.

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

Параметр web.xslt конфигурации сервера - URL папки, где будут находиться ваши XSLT-шаблоны. При использовании режима xml адрес 127.0.0.1 следует заменить на адрес машины с сервером биллинга, доступный пользователям из внешней сети.

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

web.menuItem1=Новости
web.menuItem2=Уведомления
web.menuItem3=Просмотр баланса
web.menuItem4=Смена пароля на доступ к статистике
web.menuItem5=Смена тарифных планов
web.menuItem6=Тарифные опции
web.menuItem7=Карточки
web.menuItem8=Управление лимитом
web.menuItem9=Управление статусом
web.menuItem10=Дополнительные действия
web.menuItem11=Примечания

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

web.menuItem1=none

XSLT-процессор получает XML-данные от сервера и на основании шаблонов создаёт XML-страницу. Чтобы просмотреть XML-документ, на основании которого создаётся страница, установите режим работы Web-статистики в xml, либо добавьте к URL в браузере строку &ct=xml, далее вызовите страницу и сделайте просмотр её исходного кода.

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

web.add.contract=1

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

Таким образом на странице статистики можно разместить, например, некоторые параметры договора.

Начиная с версии 6.0 в системе доступен редактор web-меню, доступный из меню Сервис = Настройка = Редактор web-меню. Можно создать несколько меню, назначить созданные меню на договора и указать в шаблонах. Одно из созданных меню можно назначить как меню "по умолчанию". Если в редакторе не создано ни одного меню или ни одно из них не указано как меню "по умолчанию", то меню будет генерироваться автоматически, так же как это было в предыдущих версиях.

Редактор web-меню.

Добавление пункта web-меню.

Переименование пунктов web-меню.

Добавление группы.

Добавление плагинного пункта web-меню.

Переименование группы web-меню.

Назначение меню на договор.

Задание меню в шаблоне договора.

Отображаются на первой странице кабинета пользователя.

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

Чтобы работали html-теги необходимо заключить новость в xml-теги <data></data>. В этом случае содержащаяся внутри информация должна быть правильным xml-документом, т.е все теги должны быть закрыты, все атрибуты должны быть в ""

<data>
Поздравляем всех с <b>ПРАЗДНИКОМ</b>!!!<br/>
Желаем счастья и т.д и т.п
</data>

После того как клиент зайдёт на свою страницу статистики он увидит справа от меню вашу новость.

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

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

Биллинг поддерживает возможность смены тарифов пользователями через Web-интерфейс пользователя.

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

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

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

В Справочники=>Группы тарифов создадим группу с названием "Первая" и установим следующие параметры.

Кроме перечня разрешённых тарифов и момента, когда можно менять тариф, необходимо установить:

Также обратите внимание, что для каждого тарифа может устанавливаться начальная и/или конечная даты периода, когда эти тарифы видны в Web-интерфейсе пользователя и доступны для выбора. Это дополнительное средство обеспечения гибкости. Можно, например, сделать доступными некоторые из тарифов группы через некоторое время. Но это не имеет никакого отношения к возможности установки на какое-то число начала действия тарифа. Это только период, когда тарифы видны в списке выбора тарифов для смены.

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

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

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

Тарифные опции позволяют клиенту изменять свойства сервиса или

У абонентов есть возможность загружать на свой комьпютер карточки своего договора в формате PDF.

Загрузка карточки происходит после нажатия на ссылку Скачать. Для просмотра сохраненной карточки необходимо установить программу для просмотра PDF-документов (например: Adobe Acrobat Reader, STDUViewer и др.).

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

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

# Коды групп договоров, для которых действует данная настройка, через ',' (чтобы узнать код группы нажмите Ctrl+i в справочнике 
# групп при выбранной строке таблицы)
contract.limit.<n>.groups=
# Максимальное количество не оплаченных (не возвратившихся) понижений,
# при котором клиенту будет доступно понижение, при 0 клиент не сможет выполнять
# понижение до тех пор пока будет хотя бы одно не оплаченное
contract.limit.<n>.maxnotpayoffed=
# Максимальное количество частично оплаченных понижений,
# при котором клиенту будет доступно понижение (0-1, частично оплаченное понижение
# может быть только одно)
contract.limit.<n>.maxpartialpayoffed=
# Количество просроченных платежей после последней разблокировки,
# после которых доступ к понижению будет заблокирован, 0 - не блокировать при любом количестве
contract.limit.<n>.maxexpiredforblock=
# Дни от до
contract.limit.<n>.mindays=
contract.limit.<n>.maxdays=
# Сумма от до
contract.limit.<n>.minsumm=
contract.limit.<n>.maxsumm=
# Нижний порог лимита при понижении клиентом (по умолчанию -100),
# т.е ниже этого порога клиент понизить не сможет
contract.limit.<n>.minlimit=

Где: <n> - целое число, начинающееся с 1, определяющее блок конфигурации для определённых групп договоров.

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

# Коды групп договоров для которых действует данная настройка, через ',' (чтобы узнать код группы нажмите Ctrl+i в справочнике 
# групп при выбранной строке таблицы)
contract.limit.1.groups=1,2
# Максимальное количество не оплаченных(не возвратившихся) понижений,
# при котором клиенту будет доступно понижение, при 0 клиент не сможет выполнять
# понижение до тех пор пока будет хотя бы одно не оплаченное
contract.limit.1.maxnotpayoffed=0
# Максимальное количество частично оплаченных понижений,
# при котором клиенту будет доступно понижение (0-1, частично оплаченное понижение
# может быть только одно)
contract.limit.1.maxpartialpayoffed=0
# Количество просроченных платежей после последней разблокировки
# после которых доступ к понижению будет заблокирован, 0 - не блокировать при любом количестве
contract.limit.1.maxexpiredforblock=1
# Дни от до
contract.limit.1.mindays=1
contract.limit.1.maxdays=4
# Сумма от до
contract.limit.1.minsumm=100
contract.limit.1.maxsumm=200
# Нижний порог лимита при понижении клиентом (по умолчанию -100),
# т.е ниже этого порога клиент понизить не сможет
contract.limit.1.minlimit=-400

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

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

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

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

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

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

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

В случае, если понижение недоступно, пользователь увидит страницу следующего вида.

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

Оператор биллинга может индивидуально управлять доступом договора к сервису временного понижения лимита через вкладку Web=>Управление лимитом договора.

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

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

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

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

Если статус договора не "активен" и не "приостановлен" - тоже не разрешена смена.

Если closed.date.enabled, то проверятся, что устанавливаемый статус не пересекается с закрытым периодом.

Смена статусов сопровождается событиями, как и при обычной смене статусов, не из Web. Только в событии ContractStatusChangingEvent устанавливается флаг isweb=true. Событие ContractStatusChangedEvent выполняется точно так же.

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

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

При необходимости можно вывести в Web-интерфейсе параметры договора. Для включения данного пункта меню необходимо в конфиге прописать web.menuItem12=Параметры договора или настроить в Редакторе web-меню

Какие параметры должны отображаться в Web-интерфейсе, задается в редакторе параметров выбором двух флагов Чтение в ЛК и Правка в ЛК

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

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

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

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

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

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

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

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

То же относится и к группам договоров - разрешён будет максимум из присвоенных клиенту групп пользователей. Если в какой-нибудь из групп пользователей не будет фильтра по группам договоров (и будет установлен параметр ИЛИ, см.далее) - будет разрешена работа со всеми договорами.

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

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

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

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

Поле Привязка к договору в свойствах пользователя позволяет заводить в системе агентов. При этом все агентские договоры должны иметь параметр типа Ссылка на договор (Агент в примере) и значение этого параметра должно быть равным агентскому договору (NK00001-03 для приведённого выше снимка экрана). Данному пользователю системы будет разрешена работа только со своими договорами. Они же будут выведены в результатах поиска. В договоре агента (NK00001-03 в примере) вы можете вести взаимозачёты с агентом. Правка параметра Агент должна быть запрещена для пользователя-агента!

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

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

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

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

Права на выполнение различных действий внутри системы контролируются подсистемой BGSecure. Все действия в биллинге собраны в древовидную структуру. При установке модуля вместе с ним инсталлируются его действия. Действия модуля прописаны в файле, расположенном в каталоге BGBillingServer/actions.

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

Запросы вы можете посмотреть в файле log, запустив клиент биллинга в DEBUG-режиме скриптом bgbilling_debug.bat (.sh), либо воспользуйтесь Сервис=>Журналы=>Журнал запросов. О различиях в видах запросов к серверу вы можете посмотреть здесь.

<group title="Модули и услуги">
 <action id="14" mask="module=service;action=GetServices" title="Просмотр услуг"/>
 <action id="15" mask="module=service;action=UpdateService" title="Обновление услуги"/>
 <action id="16" mask="module=service;action=DeleteService" title="Удаление услуги"/>
</group>

"module=dialup;action=RecalculateSessions;contract=R:\d+"

<group title="Платежи">
   <service id="89" name="PaymentService" operation="paymentList" title="Просмотр платежей"/>
   <service id="90" name="PaymentService" operation="paymentUpdate" title="Изменение платежа" expression="payment.getId() gt 0"/>
   <service id="101" name="PaymentService" operation="paymentUpdate" title="Добавление платежа"/>
</group>

Для каждого пользователя, либо для группы пользователей, ко всему прочему, можно настроить также и возможность скрытия ненужных по каким-либо причинам пунктов меню в клиенте BGBillingClient. Само описание меню хранится в файле BGBillingServer/data/menu.xml в виде дерева. Например:

...
<menu title="Сервис" id="service">
    <menu title="Журналы" id="log">
        <menuItem id="query" className="bitel.billing.module.admin.bgsecure.ActionQueryLogViewer" title="Журнал запросов"/>
        ...
    </menu>
</menu>
...

Каждый элемент меню однозначно характеризуется связкой <код меню>.<код пункта меню>. При наличии вложенности нескольких меню для определения конкретного пункта меню (т.е. листа дерева), используется только последний код меню, непосредственно включающего данный пункт. Например, пункту меню Сервис => Журналы => Журнал запросов соответствует ключ log.query (см. код выше). Пункты меню, соответствующие конкретному модулю имеют код вида <код модуля>. Например, для модуля Inet c кодом 12 код пункта меню будет равен 12. Пункты меню, соответствующие плагинам, прописаны в файле plugin.xml, который находится в корне jar-архива плагина. Данный архив находится в папке <BGBilling_server_path>/lib/app.

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

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

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

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

Большинство пунктов меню Сервис описано в документации в контексте подсистемы, к которой относится пункт меню. Описание прочих пунктов меню приведено ниже.

Может использоваться как протокол обмена между внешними программами по приёму платежей и сервером биллинга. Загрузка производится из текстового, либо DBF-файла. Менеджер загрузки расположен в меню Сервис=>Автоматизация=>Загрузка платежей и расходов.

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

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

Каждый шаблон обозначается уникальным числовым идентификатором (<id>), он должен присутствовать в каждой строке, описывающей шаблон. Шаблоны следует нумеровать строго по порядку. Приведённые ниже примеры описывают шаблон с кодом 1.

В каждом шаблоне должны быть обязательно определены параметры:

payment.load.pattern.<id>=<Название>
payment.load.pattern.<id>.type=<Тип>
payment.load.pattern.<id>.encoding=<Кодировка>
payment.load.pattern.<id>.payment_type=<Типы платежей>
payment.load.pattern.<id>.position_sum=<Позиции сумм>

Где:

Начиная с версии 4.6 появилась возможность указывать в одной строке одновременно несколько сумм для разных типов платежей. Для этого в полях payment_type и position_sum нужно указывать типы платежей и позиции сумм через запятую, в правильном, соответственном порядке. Т.е. если указать payment_type=1,2,3 и position_sum=2,3,4, то это будет означать, что на 2ой позиции расположена сумма с платежом типа 1, на 3ей позиции - типа 2 и т.п

В случае если тип формата определён как 1 (текстовый файл), то должен быть определён REGEXP разбития строки файла на позиции записи.

payment.load.pattern.<id>.regexp=<REGEXP>

Дополнительно для каждого шаблона могут быть определены следующие необязательные параметры:

payment.load.pattern.<id>.summa.replace=<Строка замен>
payment.load.pattern.<id>.position_comment=<Позиция комментария платежа>
payment.load.pattern.<id>.position_id=<Позиция уникального идентификатора>
payment.load.pattern.<id>.position_date=<Позиция даты>
payment.load.pattern.<id>.date_format=<Формат даты платежа>

Где:

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

payment.load.pattern.<id>.summa.replace=\-=>.|\s=>

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

payment.load.pattern.<id>.search.mode=and

В системе установленно жёсткое ограничение, по которому каждый тип поиска возвращает не более 10 результатов. Это реализовано в MySQL опцией LIMIT. Режимы поиска работают с учётом даты платежа, она сравнивается с периодом действия договора, логина, телефона и пр. В результаты поиска не попадают договоры, помеченные как "скрытые".

Каждый метод поиска имеет свой подход (<s_id>) в пределах шаблона. В методе поиска должны быть определены обязательно параметры:

payment.load.pattern.<id>.search.<s_id>.type=<Тип метода>
payment.load.pattern.<id>.search.<s_id>.pos=<Позиция>
payment.load.pattern.<id>.search.<s_id>.regime=<Метод сопоставления>

Где:

При типах метода parameter, parameter_email необходимо указание кода параметра:

payment.load.pattern.<id>.search.<s_id>.pid=<Код параметра договора>

При типах поиска, связанных с конкретным модулем (login, phone, cerbercrypt), необходимо указать код экземпляра модуля:

payment.load.pattern.<id>.search.<s_id>.mid=<Код экземпляра модуля>

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

payment.load.pattern.<id>.search.<s_id>.groups=<Группы договоров>
payment.load.pattern.<id>.search.<s_id>.pattern=<REGEXP-фильтр>
payment.load.pattern.<id>.search.<s_id>.replace=<REGEXP замены>
# Не учитывать период действия договора при поиске
payment.load.pattern.<id>.search.<s_id>.no.contract.period.check=1

Где:

x0000;13.4;sfdsdfdsd

payment.load.pattern.1=Шаблон1
payment.load.pattern.1.type=1
payment.load.pattern.1.encoding=UTF-8
payment.load.pattern.1.payment_type=2
payment.load.pattern.1.position_sum=2
payment.load.pattern.1.regexp=(\w+);([\d\.]+);(\w+)
payment.load.pattern.1.position_comment=3
payment.load.pattern.1.search.1.type=contract
payment.load.pattern.1.search.1.pos=1
# 1 - eq, 2 - LIKE, 3 -REGEXP
payment.load.pattern.1.search.1.regime=1

2 2775102 20.07.07 147.88 Мурева Вова Витальевна г. Самара, ул Потейская д.144 кв.17

payment.load.pattern.1=Шаблон
payment.load.pattern.1.regexp=(\d+)\t(\d+)\t([\d\.]+)\t([\d\.]+)\t([а-яА-я \w]+)\t(.+)
# Позиция суммы и комментария (в комментарий идёт идентификатор платежа из файла)
payment.load.pattern.1.payment_type=2
payment.load.pattern.1.position_sum=4
payment.load.pattern.1.position_comment=1
# Метод поиска по телефону
payment.load.pattern.1.search.1.type=phone 
# Код экземпляра модуля телефонии
payment.load.pattern.1.search.1.mid=1
# В какой группе REGEXP идёт номер телефона
payment.load.pattern.1.search.1.pos=2
# Номер телефона дополняется перед поиском до E.164
payment.load.pattern.1.search.1.replace=.*=>7846$0
# ФИО
payment.load.pattern.1.search.2.type=comment
# ФИО идёт на пятой позиции файла
payment.load.pattern.1.search.2.pos=5
# Проверка ФИО+телефона
payment.load.pattern.1.search.mode=and

x0000;13-4;Иванов ;04.07.2008

payment.load.pattern.2=Шаблон2
payment.load.pattern.2.type=1
payment.load.pattern.2.encoding=UTF-8
payment.load.pattern.2.payment_type=2
payment.load.pattern.2.regexp=(\w+);([\d\,\.\s\-]+);([а-яА-Я\s]+);([\d\.]+)
payment.load.pattern.2.position_sum=2
# Преобразование суммы к нужному виду
payment.load.pattern.2.summa.replace=\-=>.|\s=>
# Дата платежа берётся из файла
payment.load.pattern.2.position_date=4
payment.load.pattern.2.date_format=dd.MM.yyyy
payment.load.pattern.2.search.mode=and
payment.load.pattern.2.search.1.type=contract
payment.load.pattern.2.search.1.pos=1
payment.load.pattern.2.search.1.regime=1
payment.load.pattern.2.search.2.type=comment
payment.load.pattern.2.search.2.pos=3
payment.load.pattern.2.search.2.regime=2
payment.load.pattern.2.search.2.replace=\s*([а-яА-Я]+)\s*=>%$1%
#

payment.load.pattern.3=Шаблон3
payment.load.pattern.3.type=2
payment.load.pattern.3.encoding=Cp866
payment.load.pattern.3.payment_type=2
payment.load.pattern.3.position_sum=3
payment.load.pattern.3.position_date=2
payment.load.pattern.3.date_format=yyyy-MM-dd
payment.load.pattern.3.search.1.type=contract
payment.load.pattern.3.search.1.pos=6
payment.load.pattern.3.search.1.regime=1

Обработка платежей осуществляется на основании реестров следующим образом:

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

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

Для проведения реестра - выбрать строку в таблице и нажать кнопку Провести реестр. Для отката - также выбор строки и кнопка Откат реестра.

report.mail=<E-Mail адрес, на который высылать ошибки разбора реестров>
load.from.dir=<полный путь к каталогу, из которого загружаются реестры>
processed.to.dir=<полный путь к каталогу, в который перемещаются обработанные реестры>

filetype.<id>.load_pattern=<Код шаблона загрузки>
filetype.<id>.name_pattern=<REGEXP имени файла>

filetype.<id>.date_format=<формат даты>
filetype.<id>.position_date=<номер группы в REGEXP имени файла, где записана дата>

report.mail=shamil@bitel.ru
load.from.dir=/home/shamil/tmp/payments
processed.to.dir=/home/shamil/tmp/payments/processed
filetype.1.load_pattern=3
filetype.1.name_pattern=TNE(\d{8})\.DBF
filetype.1.date_format=yyyyMMdd
filetype.1.position_date=1

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

client.gui.time.of.check.messages4users=3600000

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

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

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

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

SQL редактор (Утилиты=>SQL-Редактор) представляет собой средство низкоуровневого доступа к БД биллинга. С помощью него можно выполнять произвольные SQL-запросы, получать результаты, сохранять их в файл и отправлять на указанный e-mail.

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

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

В нижнем поле "Отправить на e-mail" можно ввести адрес электронной почты и с помощью кнопки Отправить сформировать электронное письмо с вложением в виде csv, в котором будет результат текущего запроса.

Поля запроса и результата разделены подвижным Split-ом.

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

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

В конфигурации приложения должна быть определена как минимум одна главная (мастер) база. Эта база постоянно актуальна и может выполнять как запросы обновления, так и выборок. В *.properteis конфигурации приложения биллинга определены хост, порт MySQL, имя базы данных и учётные данные для MySQL, например так:

db.driver=com.mysql.jdbc.Driver
db.url=jdbc:mysql://192.168.184.245/bgbilling?useUnicode=true&characterEncoding=UTF-8&allowUrlInLocalInfile=true&zeroDateTimeBehavior=convertToNull&jdbcCompliantTruncation=false&elideSetAutoCommits=true&useCursorFetch=true&queryTimeoutKillsConnection=true
db.user=bill
db.pswd=bgbilling
db.maxIdle=10
db.maxActive=50

Параметр db.maxIdle определяет максимально число простаивающих в данный момент соединений с базой данных; простаивающие соединения, выходящие за данное количество, закрываются. При большом одновременном количестве запросов к приложению биллинга число активных соединений растёт, по мере надобности устанавливаются новые соединения с MySQL, добавляясь в пул. При достижении активного количества соединений db.maxActive создание соединений прекращается, потоки ожидают освобождения уже занятых соединений.

Каждое приложение биллинга способно возвращать свой статус, вызовом *_status.* скрипта (server_status.sh, radius_status.sh). Сообщение о статусе приложения обязательно содержит время старта приложения и время работы, информацию по соединениям с базой данных и используемой памяти. Рассмотрим как пример вывод server_status.sh:

BGBillingServer v 4.6  build 333 from 01.03.2009
Started: 11.03.2009 16:29:49 Uptime: 0 d 00:00:05
Memory total: 6 045 696; max: 66 650 112; free: 2 975 800
Connections pool to Master status Idle: 1; Active: 0; maxActive: 4; maxIdle: 10
Connections pool to Slave "1" status Idle: 0; Active: 0; maxActive: 4; maxIdle: 10

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

Затем - использование ОЗУ. Параметр max определяет максимальный объем памяти, которую Java-машина может получить у операционной системы; total - сколько реально отобрано Java-машиной памяти в настоящий момент; free - сколько из этой реально выделенной памяти свободно.

По мере работы сборщик мусора освобождает неиспользуемую память. Если использование памяти все равно растёт - увеличивается параметр total. Однако он никогда не может превысить порога, заданного max. Размер памяти max можно увеличивать, изменяя число после параметра -Xmx в скрипте запуска приложения. На 32х разрядных ОС невозможна установка параметра max более 1.5 Гб. При нормальной работе приложения total не должен достигать max.

Последние строки (одна или более) отображают статусы пулов соединений к мастер и слейв базам данных.

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

Для добавления реплики в *.properties файле приложения (data.properties, radius.properties) указывается после конфигурации основной (Мастер) базы:

db.slave.<slave_id>.url=jdbc:mysql://<host>:<port>/<db_name>?useUnicode=true&characterEncoding=UTF-8&allowUrlInLocalInfile=true&zeroDateTimeBehavior=convertToNull&jdbcCompliantTruncation=false&elideSetAutoCommits=true&useCursorFetch=true&queryTimeoutKillsConnection=true
db.slave.<slave_id>.user=<user>
db.slave.<slave_id>.pswd=<pswd>
db.slave.<slave_id>.maxIdle=<max_idle>
db.slave.<slave_id>.maxActive=<max_active>

Где:

Для каждого приложения биллинга реплики указываются отдельно в *.properties файле, что позволяет регулировать использование реплик различными приложениями. Необходимо проконтролировать, чтобы пользователь <user> имел права только на SELECT и CREATE TEMPORARY TABLES в реплике. Также хорошим вариантом является выдача полного набора прав с установкой опции --read_only=1 при старте сервера MySQL (либо установка этой же опции в my.cnf файле).

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

db.slave.1.url=jdbc:mysql://repl:3306/bgbilling?useUnicode=true&characterEncoding=UTF-8&allowUrlInLocalInfile=true&zeroDateTimeBehavior=convertToNull&jdbcCompliantTruncation=false&elideSetAutoCommits=true&useCursorFetch=true&queryTimeoutKillsConnection=true
db.slave.1.user=bill
db.slave.1.pswd=
db.slave.1.maxIdle=10
db.slave.1.db.maxActive=20

Возможно определение нескольких Slave-серверов с разными <slave_id>. В этом случае запрос будет адресован к серверу, имеющему наименьшее отношение активных соединений в настоящий момент к максимальному числу активных соединений. В случае, если количество соединений ко всем подключённым Slave-базам исчерпано, будет возвращено подключение к Мастер-базе.

Можно отключить возможность предотвращения перерасхода slave-соединений, тогда попытки взять соединение из Master-БД делаться не будет, а будет ожидание освобождения slave-пула. Для этого в data.properties надо добавить параметр

# отключение предотвращения перерасхода slave-соединений (по умолчанию если кончаются
# slave-соединения, например при подвешивании реплики, берутся master-соединения).
db.disable.prevention.slave.overrun=1

Для отслеживания актуальности реплик установите в конфигурации сервера биллинга параметр slave.alarm.second.behind.master=<seconds>, где <seconds> - количество секунд. При отставании реплики от основной базы на <seconds> и более секунд высылается аларм. Опция, установленная в конфигурации сервера биллинга, применяется ко всем приложениям биллинга. В качестве теста возможна установка опции в 0, что должно спровоцировать высылку сообщения. Для работы опции пользователь MySQL приложения биллинга должен иметь в Slave-базах право REPLICATION CLIENT.

Также возможно включить возможность автоматического отключения сильно отстающих реплик с последующим их автоматическим же включением в случае ликвидации критического отставания. Для этого необходимо в конфигурации сервера биллинга установить параметр slave.disable.second.behind.master=<seconds>, где <seconds> - количество секунд. При отставании реплики от основной базы на <seconds> и более секунд высылается аларм, а сервер биллинга, в свою очередь, помечает данную реплику отстающий и прекращает обращения к ней. Через некоторое время, если отставание реплики стало менее <seconds>, то обращения к данной реплики биллингом возобновятся автоматически.

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

В данный момент поддержано хранение в "Мусорной" базе таблиц:

"Мусорная" база определяется в конфигурации сервера биллинга (Сервис=>Настройки) следующим образом:

db.trash.<trash_id>.url=jdbc:mysql://<host>:<port>/<db_name>?useUnicode=true&characterEncoding=UTF-8&allowUrlInLocalInfile=true&zeroDateTimeBehavior=convertToNull&jdbcCompliantTruncation=false&elideSetAutoCommits=true&useCursorFetch=true&queryTimeoutKillsConnection=true
db.trash.<trash_id>.user=<user>
db.trash.<trash_id>.pswd=<pswd>
db.trash.<trash_id>.maxIdle=<max_idle>
db.trash.<trash_id>.maxActive=<max_active>

Где:

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

trash.table.map.<pos>.<table_prefix>=<trash_id>

Где:

Например, так можно определить хранение таблиц log_function_process в отдельной мусорной базе:

db.trash.trash_1.url=jdbc:mysql://192.168.184.2:3306/trash_1?useUnicode=true&characterEncoding=UTF-8&allowUrlInLocalInfile=true&zeroDateTimeBehavior=convertToNull&jdbcCompliantTruncation=false&elideSetAutoCommits=true&useCursorFetch=true&queryTimeoutKillsConnection=true
db.trash.trash_1.user=root
db.trash.trash_1.pswd=
db.slave.trash_1.maxIdle=10
db.slave.trash_1.maxActive=4
#
trash.table.map.1.log_function_process=trash_1

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

table.create.<table_name>.data.directory=<data_dir>
table.create.<table_name>.index.directory=<index_dir>
table.create.<table_name>.engine=<engine>

Где:

Например:

table.create.log_session_12.data.directory=/home/mysql
table.create.log_session_12.index.directory=/home/mysql
table.create.log_session_12.engine=INNODB

Указанные значения преобразуются в атрибуты DATA DIRECTORY, INDEX DIRECTORY и ENGINE команды CREATE TABLE при создании новой периодической таблицы. Более подробно читайте об этом в документации по MySQL.

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

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

-Dbgbilling.transfer.debug=true - выводить debug 
-Dbgbilling.client.os=linux - операционная система.   
-Dlocal.setting.file.name=config_v.4.5 - имя файла с настройками в папке пользователя.
-Dsun.net.client.defaultConnectTimeout=1000 - таймаут получения URL для клиента, если в FOP, например, есть недоступная картинка.
-Duser.home - домашаняя папка клиента (в которой хранится local.setting.file.name)
-Dshared.client.distribution=1 - при обновлении клиента в сетевой папке, все запущенные клиенты перезагружаются.

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

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

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

Для модификации данных в БД можно использовать как напрямую Java SQL API так и предлагаемые с BGBilling API, описанное в разделе документации API документация для разработки скриптов. Все классы-события расширяют базовый класс ru.bitel.bgbilling.kernel.event.Event.

Для получения имени класса события воспользуйтесь горячей клавишей Ctrl + i, располагаясь на списке событий в редакторе привязки событий к скрипту BGBS, либо Java-классу (см. далее). В JavaDoc по классу события представлена полная информация по событию.

Скрипты поведения заводятся в Справочники=>Другие.

В меню Сервис=>Автоматизация=>Скрипты поведения производится привязка к скрипту поведения его функций. Оно содержит две вкладки: Скрипты BGBS и Классы Java.

Вкладка Классы Java содержит интерфейс управления привязкой динамических классов к скриптам поведения. Добавление привязки динамически загружаемого класса Java к скрипту поведения в качестве реакции на определённое событие в целом аналогично такому же действию при добавлении функции скрипта поведения на BGBS. Однако в качестве прямого редактирования кода предлагается выбрать лишь один из динамических классов, реализующих интерфейс ru.bitel.bgbilling.kernel.script.server.dev.EventScript, можно использовать наследование от класса ru.bitel.bgbilling.kernel.script.server.dev.EventScriptBase.

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

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

Получение имени класса события по Ctrl + i.

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

Получение имени класса события по Ctrl + i.

Редактор скриптов обладает подсветкой синтаксиса, индикацией строки и позиции и следующими горячими клавишами:

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

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

Программирование в BeanShell в целом идентично Java, но есть некоторые исключения:

При обработке события в скрипт передаются следующие переменные:

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

import bitel.billing.server.contract.bean.*;
import bitel.billing.server.util.*;
import java.sql.*;
import java.util.*;
import bitel.billing.server.contract.bean.*;

includeBGBS( "bgbs://ru.bitel.bgbilling.kernel.script.common.bean.ScriptLibrary/default" );

public void onEvent( event, setup, con, conSlave ) 
{
   if( event.getActionId() != 3333 ) 
   {
     return;
   }

   gets(event);

   event.addReport(doSomething("vvv"));
}

Вот эта же функция, переписанная по-старому (работает медленнее в 8-10 раз):

import bitel.billing.server.contract.bean.*;
import bitel.billing.server.util.*;
import java.sql.*;
import java.util.*;
import bitel.billing.server.contract.bean.*;

includeBGBS( "bgbs://ru.bitel.bgbilling.kernel.script.common.bean.ScriptLibrary/default" );

if( event.getActionId() != 3333 ) 
{
   return;
}

gets(event);

event.addReport(doSomething("vvv"));

Обратите внимание на инструкцию включения библиотеки:

includeBGBS( "bgbs://ru.bitel.bgbilling.kernel.script.common.bean.ScriptLibrary/default" );

Сами библиотеки скриптов определяются в меню Сервис=>Автоматизация=>Библиотеки скриптов. Для каждой библиотеки должно быть определено уникальное имя. Библиотека представляет из себя функции, которые становятся доступными после включения в скрипте инструкции includeBGBS. На снимке ниже представлен код библиотеки default, использованной в скрипте выше.

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

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

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

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

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

Класс, привязанный к глобальному скрипту, должен расширять базовый класс ru.bitel.bgbilling.kernel.script.server.dev.GlobalScriptBase. Для однократного выполнения глобального скрипта необходимо нажать на кнопку Выполнить скрипт. Выполнение скрипта происходит асинхронно. Результат выполнения скрипта логируется (см. вкладку Логи).

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

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

Для однократного выполнения глобального скрипта необходимо (предварительно его сохранив) нажать на кнопку Выполнить скрипт. Выполнение скрипта асинхронно. Результат выполнения скрипта логируется (см. вкладку Логи).

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

В качестве параметра для задачи необходимо указать tids=X,Y,Z, где X,Y,Z - коды скриптов, перечисленные через запятую.

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