Биллинг онлайн руководство

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

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

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

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

4. Иногда названия скриптов указывается таким образом: , что следует трактовать как: запустите для Linux-платформы, либо для Windows-платформы.

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

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

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

• модули.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

chmod 755 /etc/init.d/bgbilling

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

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

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

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

dos2unix *.sh

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

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

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

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

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

del /F *.sh

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

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

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

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

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

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

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

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

Обратите внимание на закомментированный фрагмент, в этом отрывке настраивается сеть серверов 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 приложения биллинговой системы. Если все компоненты биллинга установлены на одном сервере, то можно оставить значение =nio://127.0.0.1:61616. Иначе нужно указать ip интерфейса, на который будут идти подключения или установить =nio://0.0.0.0:61616, чтобы порт был открыт на всех интерфейсах.

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

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

Для локальной машины =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

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

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

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

JAVA_HOME=/opt/java/jdk

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

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

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

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

Установите переменную окружения .

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

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

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

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

Замечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/ изменяют год, / — месяц.

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

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

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

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

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

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

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

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

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

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

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

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

bg.enable=0

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

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

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

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

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

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

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

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

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

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

 <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.

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

2.

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

3.

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

4.

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

5.

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

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

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

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

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

Где:

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

Значения атрибутов в текстовых конфигурациях указываются в виде: , например: . Для текстовой строки с бинарными кодами бинарный код указывается как , где — код в 16-ичной системе счисления. Например: .

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

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

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

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

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

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

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

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

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

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

Для поддержки отправки почты через 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

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

Например: «[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.db.slave.connect.error=240

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

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

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

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

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

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

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

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

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

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

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

11. Модули

Внимание

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

12. Плагины

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

Внимание

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

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

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

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

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

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

./snapshot.sh create

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

./shapshot.sh restore <FILE>

, где — имя файла со снапшотом.

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

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

Замечание

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

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

Замечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Адресный справочник необходим для правки параметров договоров и объектов типа «Адрес». Основная сущность справочника — дом. Страны, города, кварталы, районы и улицы — это обычные перечисления, которые используются в справочнике домов. Города привязаны к странам. Кварталы, районы и улицы привязаны к городам. Дома привязаны к улицам. Адресный справочник доступен в меню или при нажатии комбинации клавиш .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аналогично c и

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

18. Договор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

contract.status.active.codes=0

contract.status.suspend.codes=3,4

credit.contract.active.status=0

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

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

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

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

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

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

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

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

Дополнительные действия в договоре — это возможность непосредственного вызова скрипта BGBS для данного договора через АРМ оператора биллинга, либо из 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 возможен режим, когда при авторизации проверяется наличие в договоре всех требуемых для данной сессии услуг.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4) по меткам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Алгоритм 1:

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

Алгоритм 2:

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

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

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

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

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

Доступны в .

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

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

20. Объекты

Внимание

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

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

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

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

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

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

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

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

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

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

web.auth.modes=0:1

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

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

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

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

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

web.exit.redirect=about:blank

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

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

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

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

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

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

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

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

header.name.remote.addr=

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

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

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

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

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

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

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

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

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-статистики в , либо добавьте к URL в браузере строку , далее вызовите страницу и сделайте просмотр её исходного кода.

Возможно добавление в 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-интерфейс пользователя.

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

Где: — целое число, начинающееся с 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. Только в событии ContractStatusChangingEvent устанавливается флаг isweb=true. Событие ContractStatusChangedEvent выполняется точно так же.

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

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

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

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

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

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

22. Разграничение прав доступа

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

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

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

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

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

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

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

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

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

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

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

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

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

user.actions.permit.show_errors=0 — сокрытие ошибок Доступ запрещён от пользователя, при этом сервер просто игнорирует запрещённые действия.

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

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

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

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

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

Запросы вы можете посмотреть в файле log, запустив клиент биллинга в DEBUG-режиме скриптом , либо воспользуйтесь . О различиях в видах запросов к серверу вы можете посмотреть здесь.

<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. Само описание меню хранится в файле в виде дерева. Например:

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

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

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

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

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

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

23. Сервис

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

Может использоваться как протокол обмена между внешними программами по приёму платежей и сервером биллинга. Загрузка производится из текстового, либо 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 появилась возможность указывать в одной строке одновременно несколько сумм для разных типов платежей. Для этого в полях и нужно указывать типы платежей и позиции сумм через запятую, в правильном, соответственном порядке. Т.е. если указать и , то это будет означать, что на 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-запросы, получать результаты, сохранять их в файл и отправлять на указанный e-mail.

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

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

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

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

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

24. Администрирование и оптимизация

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

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

Каждое приложение биллинга способно возвращать свой статус, вызовом скрипта (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

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

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

По мере работы сборщик мусора освобождает неиспользуемую память. Если использование памяти все равно растёт — увеличивается параметр 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 в реплике. Также хорошим вариантом является выдача полного набора прав с установкой опции при старте сервера 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

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

Также возможно включить возможность автоматического отключения сильно отстающих реплик с последующим их автоматическим же включением в случае ликвидации критического отставания. Для этого необходимо в конфигурации сервера биллинга установить параметр , где <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

Для периодических таблиц (помесячных вида и подневных вида ) таблиц можно задавать отдельно «движок» и папку для хранения данных и индексов (эта опция поддерживается только для MyIsam). Необходимо указывать в конфигурации сервера биллинга (меню ).

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 - при обновлении клиента в сетевой папке, все запущенные клиенты перезагружаются.

1. Назначение

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

• язык BGBS — это интерпретируемый Java-подобный язык программирования, который хорошо подходит для написания небольших скриптов, время выполнения которых не критично. BGBS представляет собой интегрированный в биллинг интерпретатор языка BeanShell (http://www.beanshell.org/) + API для управления данными биллинга и набор событий биллинга, которые можно обрабатывать. Разработка на BGBS требует знание языка Java, т.к. большинство вызовов BeanShell прозрачно переадресуются Java API. Синтаксис BeanShell также практически полностью идентичен Java.;

2. Управление динамическим кодом

Внимание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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" );

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

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

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

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

4. Скрипты поведения глобальных событий

5. Глобальные скрипты

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

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

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

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

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

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

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

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

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

6. Резервные копии

7. Скрипты предобработки RADIUS запросов

8. Интеграция с внешними системами

Более ранний протокол. Подразумевает передачу параметров в HTTP запросе с получением XML ответа. Примерный вид запроса и ответа в логе клиента:

http://billing:8081/executer?module=npay&action=ServiceSetList&mid=6&BGBillingSecret=ONM13dhRxs8VDD9wFCzpPOrU&
[ length = 159 ] xml = <?xml version="1.0" encoding="UTF-8"?><data secret="B802E452DF43140146D0EC4219C847D1" status="ok"><list><item id="0" title="Полный набор услуг"/></list></data>

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

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

Более новые вызовы реализованы как Web-сервисы, пример обращения к ним вы можете посмотреть в WiKi. Используется Basic авторизация.

Примерный вид запроса и ответа:

http://billing:8081/executer/ru.bitel.bgbilling.kernel.module/ServiceService?wsdl -> {http://service.common.module.kernel.bgbilling.bitel.ru/}ServiceService:serviceList
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><ns5:serviceList xmlns:ns5="http://service.common.module.kernel.bgbilling.bitel.ru/" xmlns:common="http://common.bitel.ru" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><moduleId>9</moduleId></ns5:serviceList></S:Body></S:Envelope>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Header/><S:Body><ns5:serviceListResponse xmlns:ns5="http://service.common.module.kernel.bgbilling.bitel.ru/" xmlns:common="http://common.bitel.ru" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xml="http://www.w3.org/XML/1998/namespace"><return id="15" moduleId="9" title="Рекламный блок на Board.ufanet.ru в одном разделе (справа)" unit="0" using="true"/><return id="7" moduleId="9" title="Рекламный блок на Board.ufanet.ru в разделе &quot;Авторынок&quot; (справа)" unit="0" using="true"/><return id="12" moduleId="9" title="Рекламный блок на Board.ufanet.ru в разделе &quot;Аудио, видео, фототехника&quot; (справа)" unit="0" using="true"/><return id="6" moduleId="9" title="Рекламный блок на Board.ufanet.ru в разделе &quot;Компьютеры&quot; (справа)" unit="0" using="true"/>

Для более простого обращения к Web сервисам возможно использование протокола JSON RPC.

Запрос выглядит следующим образом, пример:

http://127.0.0.1:8080/bgbilling/executer/json/ru.bitel.bgbilling.kernel.contract.api/ContractService

{"method" : "contractList",
"user" :{ "user" : "shamil", "pswd" : "xxxx" },
"params" : {
"title" : "0",
"fc" : -1,
"groupMask" : 0,
"subContracts" : false,
"closed" : true,
"hidden" : false,
"page" : { "pageIndex" : 2, "pageSize" : 2 }
} }

URL запроса определяет Web-сервис, JSON запрос передаётся в теле запроса, кодировка UTF-8. Обязательные параметры:

Примерный вид корректного ответа:

{"status":"ok","message":"",
"data":
{
"page":{"pageSize":2,"pageIndex":2,"pageCount":49,"recordCount":97,"pageFirstRecordNumber":2},
"return":
[{"id":353023,"title":"0022010","groups":0,"password":"bg2rFZ2PEX","dateFrom":"2010-01-02","dateTo":null,"balanceMode":0,"paramGroupId":14,"personType":0,"comment":"","hidden":false,"superCid":0,"dependSubList":"","status":0,"statusTimeChange":"2010-01-13","titlePatternId":0,"balanceSubMode":0,"sub":false,"independSub":false,"balanceLimit":0.00,"super":false,"dependSub":false},
{"id":353209,"title":"06-10-10/И-Г/0","groups":0,"password":"9351220759","dateFrom":"2010-10-06","dateTo":null,"balanceMode":1,"paramGroupId":14,"personType":0,"comment":"","hidden":false,"superCid":0,"dependSubList":"","status":0,"statusTimeChange":"2010-10-06","titlePatternId":0,"balanceSubMode":0,"sub":false,"independSub":false,"balanceLimit":0.00,"super":false,"dependSub":false}]}}

В возвращается в случае корректного ответа, либо — ошибка. При этом в выводится текст ошибки.

Там выглядит сообщение об ошибке:

{"status":"error","message":"Неправильный пароль.","data":{}}

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

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

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

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

@JsonTypeInfo(use=NAME, 
               include=PROPERTY,
              property="type")
@JsonSubTypes(value={
@JsonSubTypes.Type(name="Address",value=FilterEntityAttrAddress.class),
@JsonSubTypes.Type(name="Date",value=FilterEntityAttrDate.class),
@JsonSubTypes.Type(name="House",value=FilterEntityAttrHouse.class),
@JsonSubTypes.Type(name="Int",value=FilterEntityAttrInt.class),
@JsonSubTypes.Type(name="List",value=FilterEntityAttrList.class),
@JsonSubTypes.Type(name="Text",value=FilterEntityAttrText.class),
@JsonSubTypes.Type(name="Email",value=FilterEntityAttrEmail.class)})

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

{"method" : "contractList",
"user" :{ "user" : "shamil", "pswd" : "xxxx" },
"params" :
{
"fc" : -1,
"groupMask" : 0,
"subContracts" : false,
"closed" : true,
"hidden" : false,
"page" : { "pageIndex" : 1, "pageSize" : 2 },
"entityFilter" : [ { "type" : "Text", "entitySpecAttrIds" : [2], "value" : "1"  } ]
}  }

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

1. Назначение модуля

2. Настройка модуля

3. Дилеры

4. Работа с карточками

Внимание

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

5. Генератор логинов и паролей для модуля «Карточки»

Генератор логинов и паролей написан на Java. Следовательно, для его работы на машине должен быть установлен JDK или JRE версии 1.5.0 или выше.

Распакуйте архив с генератором в любое место вашего диска и запускайте «run.bat»

После запуска генератора отображается окно.

Допустим, вам нужно сгенерировать карточки с серийными номерами 20 — 300, логины начиная с 3.

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

Если все прошло благополучно, будет выдано сообщение:

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

6. Web-интерфейс

7. Web-активация

8. Суперкарты

Внимание

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

9. IVR-Система

• bgivr.vxml — основной скрипт

• menu.vxml — пункты меню

• promts — фразы

1. с помощью голосового меню пользователь выбирает тип требуемого договора (при этом происходит определение адреса сервера биллинга и кода типа договора);

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

3. пользователь выбирает вид операции: активация карты, либо произнесение остатка на счёте;

4. если выбрано произнесение остатка, то запрашивается пароль и происходит обращение на сервер биллинга, который либо возвращает ошибку, если пароль не верен, либо генерирует VXML скрипт, произносящий баланс;

5. если выбрана активация карты, то запрашиваются слитно логин и пароль карты, которые отправляются в запросе на сервер. Карта либо успешно активируется, либо сервер возвращает код ошибки.

10. Удалённые платежи

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

findmode.x.mode=режим поиска 
findmode.x.mid=id модуля 
findmode.x.pid=id параметра 
findmode.x.title=название поиска

Возможные сочетания.

Поиск по номеру договора:

#(режим поиска - по номеру договора)
findmode.x.mode=contract
findmode.x.title=Номер договора

Поиск по адресу:

#(режим поиска - по адресу)
findmode.x.mode=address  
findmode.x.title=Адрес
#(id параметра, т.к в договоре может быть несколько параметров с типом адрес)
findmode.x.pid=x

Поиск по текстовому параметру

#(режим поиска - по текст. параметру)
findmode.x.mode=parameter
findmode.x.title=Параметр
#(id параметра, т.к в договоре может быть несколько текст. параметров)
findmode.x.pid=x

Поиск по комментарию договора

#(режим поиска - по комментарию договора)
findmode.x.mode=comment
findmode.x.title=Комментарий договора

*id параметра в справочнике можно узнать выбрав нужный элемент и нажав Ctrl+i

Поиск по логину модуля Inet

#(режим поиска - логин)
findmode.x.mode=login_inet
#(id модуля)
findmode.x.mid=x
findmode.x.title=Логин Inet

Поиск по логину модуля DialUp (VPN и т.д.)

#(режим поиска - логин)
findmode.x.mode=login_dialup
#(id модуля)
findmode.x.mid=x
findmode.x.title=Логин Dialup 

Поиск по логину модуля IP телефонии (VoiceIP)

#(режим поиска - логин)
findmode.x.mode=login_voip
#(id модуля)
findmode.x.mid=x 
findmode.x.title=Логин VoIP

Поиск по номеру модуля телефонии (Phone)

#(режим поиска - телефон)
findmode.x.mode=phone
#(id модуля)
findmode.x.mid=x
findmode.x.title=Телефон

Поиск по карточке модуля CerberCrypt

#(режим поиска - cerbercrypt)
findmode.x.mode=cerbercrypt
#(id модуля)
findmode.x.mid=x  
findmode.x.title=Карта цифрового телевидения

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

dealer.allow.contract.x.title=заголовок
dealer.allow.contract.x.group=группы договоров через запятую
dealer.allow.contract.x.regexp=regexp названия договора

При установке regexp-фильтра используется MySQL REGEXP. Например, фильтр по договорам частников (префиксы AA, AD, AL и т.п.) может выглядеть так:

dealer.allow.contract.1.title=Частники
dealer.allow.contract.1.regexp=(AA*)|(AD*)|(AL*)

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

dealer.findcontract.fewresults= 1 | 0

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

idealer.tariff.ids=X,Y,...,Z

Здесь , и — это коды тарифных планов. Порядок их расположения определяет порядок вывода тарифных планов в интерфейсе дилера. Например, сперва можно указать все тарифные планы телефонии (например, 10,11,12), а далее все тарифные планы абонплат (например, 23, 24, 26). Тогда при различных комбинациях этих тарифов у клиентов в любом случае на первом месте будет стоять один из тарифов телефонии, а затем уже какой-либо тариф абонплат. Не указанные в перечислении тарифные планы не отображаются. Для отображения персональных тарифных планов (всех сразу) следует указать код 0. При этом порядок также имеет значение.

Далее пример конфигурации:

#поиск по договору
findmode.1.mode=contract
findmode.1.title=Номер договора

#поиск по адресу
findmode.2.mode=address
findmode.2.title=Адрес
#id параметра-адреса
findmode.2.pid=19

#поиск по логину(алиасу) dialup
findmode.3.mode=login_dialup
findmode.3.mid=21
findmode.3.title=Логин Dialup

#поиск по логину(алиасу) VPN
findmode.4.mode=login_voip
findmode.4.mid=22
findmode.4.title=Логин VPN

#поиск по логину Voip
findmode.5.mode=login
findmode.5.mid=6
findmode.5.title=Логин VoIP

#поиск по телефону Phone
findmode.6.mode=phone
findmode.6.mid=20
findmode.6.title=Телефон

#поиск по картам Cerbercrypt
findmode.7.mode=cerbercrypt
findmode.7.mid=43
findmode.7.title=Карта цифрового телевидения

#

#будут выводиться только договоры из указанных через запятую групп
#номера групп указаны в справочнике
dealer.allow.contract.1.title=Поиск по VIP договорам
dealer.allow.contract.1.group=1,10,17
#будут выводиться договоры, название которых совпадает с regexp 
#(краткий список: .-любой символ,d-цифра,w-буква/цифра; * после одного из них - нет или любое кол-во,
#+ - один и более, ? - нет или один)
dealer.allow.contract.2.title=Поиск по физическим лицам
dealer.allow.contract.2.regexp=K.*
#если указаны и regexp и group то выводятся договоры, совпадающие по обоим параметрам
#
dealer.findcontract.fewresults=1
#
#коды тарифных планов для отображения в интерфейсе idealer'а. Сперва отображаем персональные ТП, 
#а затем ТП с кодами 10, 13, 24 (если они присутствуют у договора)
idealer.tariff.ids=0,10,13,24

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

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

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

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

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

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

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

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

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

# код услуги "Платежи"
dealer.pay.sid=105
# код услуги "Агентское вознаграждение"
dealer.bonus.sid=106

При привязке дилера к договору дилер сможет проводить платежи только, если у него в договоре сумма остатка больше лимита, либо если в договоре стоит режим КРЕДИТ.

Web-клиент по умолчанию находится по адресу

web-клиент является AJAX (active javascript and xml) приложением, работающим под IE, Firefox, Opera, реализующим интерфейс удалённых платежей модуля.

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

//код модуля
mid = <код модуля карточек>
//записей на странице
page_size = 15

//префикс номера транзакции,
//если не определён, то берётся
//значение из cookies
//prefix = ""

//дополнение к комментарию платежа,
//(если разрешено администратором)
//если не определён, то берётся
//значение из cookies
//postfix = ""

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

Формат реестра платежей:

<номер платежа>t<время проведения>t<договор>t<сумма>

t — знак табуляции;

время проведения в формате dd.MM.yyyy HH:mm:ss или yyyy-MM-dd HH:mm:ss

Например: 2147483647 2006-03-03 13:56:39 x0000 10

1. Назначение модуля

2. Базовые понятия и алгоритм работы модуля

• в режиме «только оплата», при котором покупки оплачиваются путём перенаправления из магазина Enaza на страничку в личном кабинете с подтверждением оплаты;

• в режиме встраивания IFRAME на страницу в веб-кабинете.

• в режиме встраивания Widget на страницу в веб-кабинете.

• либо через IFRAME/WIDGET на странице статистики, либо непосредственно на сайте магазина Enaza пользователь выбирает интересующий товар и начинает оформление заказа;

• биллинг Enaza перенаправляет пользователя на сервлет на сервере BGBilling, посредством которого происходит проверка корректности данных и перенаправление пользователя на страничку с подтверждением оплаты в личном кабинете;

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

3. Установка и настройка модуля

4. Инструкции по активации услуг компании Enaza

• http://provider.example.com[:PORT]/bgbilling/enaza_api/<MID>/access — получение access_token;

• http://provider.example.com[:PORT]/bgbilling/enaza_api/<MID>/client — получение user_data;

• http://provider.example.com[:PORT]/bgbilling/enaza_api/<MID>/login — авторизация по IP (в данной момент не реализована);

• http://provider.example.com[:PORT]/bgbilling/pubexecuter?action=Enaza&module=enaza&mid=<MID> — авторизация по логину и паролю от ЛК.

5. Клиентская часть

1. Назначение модуля

2. Настройка модуля

• [${fio}] — ФИО клиента;

• [${city}] — город;

• [${street}] — улица;

• [${house}] — дом;

• [${frac}] — дробь дома;

• [${flat}] — квартира;

• [${contractTitle}] — название договора;

• [${summ}] — сумма;

• [${account}] — счет;

• [${contractId}] — id контракта;

• [${dateFrom}] — дата начала периода оплаты (ставится начало месяца );

• [${dateTo}] — дата окончания периода оплаты (ставится дата формирования реестра ).

3. Работа с реестрами

4. Использование модуля

1. Назначение модуля

2. Базовые понятия и алгоритм работы модуля

• страничка в личном кабинете, в которую посредством вставки IFRAME интегрируется площадка по продаже ПО по подписке;

• сервлет на сервере BGBilling, посредством которого удаленные сервера Rentsoft «уведомляют» биллинговую систему о покупке, изменении статуса подписок и т.п. (должен быть доступен «извне»);

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

3. Установка и настройка модуля

4. Инструкции по активации услуг компании Рентсофт

• e-mail: partner@rentsoft.ru

• тел. +7 (499) 504-98-75

5. Клиентская часть

6. Работа с юридическими лицами

Если продажа продукта осуществляется самим провайдером при посещении им клиента, реализуется следующий сценарий.

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

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

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

7. Web интерфейс

1. Назначение модуля

2. Конфигурация модуля

3. Создание типов логинов

4. Активация TrayInfo клиентом

5. Настройка утилиты TrayInfo

6. Настройка утилиты TrayInfo3

7. Настройка утилиты TrayInfo для Mac Os

8. Отображение в утилите произвольной информации вместо баланса

1. Назначение модуля

• оплата по кредитной карте;

• оплата через платёжную систему WebMoney Transfer;

• оплата через платёжную систему Яндекс.Деньги;

• оплата через QIWI;

• оплата кредитной картой с использованием Assist®ID.

Замечание

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

2. Настройка модуля

• Режим. Тестовый или Рабочий. Таким образом, режим определятся двумя настройками — в самом магазине Assist и в конфигурации модуля.

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

• Можно также настроить автоматическое перенаправление покупателя на сайт предприятия после завершения платежа в АПК ПР. Для этого необходимо выбрать действие после авторизации «Перейти на страницу магазина» в Личном кабинете по адресу https://account.paysecure.ru/ в разделе «Настройки мерчантов», вкладка «Настройки платежей». В этом случае после авторизации сразу загружается страница веб-статистики, на которой показывается предварительный результат этого платежа.

• Настройка получения результатов операций: в личном кабинете assist поставить галку «отправлять результаты платежей», ввести URL, примерно такой: http://billing/bgbilling/assistexecuter?mid=<mid ассиста> , указать тип: SOAP. URL зависит от ваших настроек, проверьте доступность извне сервлета assistexecuter.

• Не ставить (снять) галочку «отправлять только успешные», иначе неудачные платежи будут вечно висеть в статусе «в обработке».

Внимание

Если у вас работала до этого старая версия протокола, то нужно задачу планировщика «Получение результатов операций».

Внимание

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

3. Оплата через систему Assist

4. Мониторинг и администрирование платежей

5. Настройка автоматической установки статусов платежей

6. Настройка сети, фаервола и т.д.

Внимание

Обратите внимание на ограничение Assist. В соотвествии с стандартом PCI DSS сервера Assist из продакшн среды не могут устанавливать соедения во внешую среду по нестандартным портам. Допустимо использование 80 и 443 (как с SSL, так и без) портов. Это означает, что ваш assistexecuter должен быть доступен извне по одному из этих портов. В противном случае оповещения об операциях не будут доходить.

7. Важные замечания

1. Назначение модуля

2. Краткий алгоритм работы модуля

3. Настройка модуля

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

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

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

В могут быть указаны следующие макросы, связанные знаками «+» и «-«. Вместо <month> могут быть подставлены значения , , , , , означающие в данном контексте месяц, за который производится выборка.

В могут быть указаны следующие макросы, связанные знаками «+» и «-«. Вместо <month> могут быть подставлены значения , , , , , означающие в данном контексте месяц, за который производится выборка. Вместо <mid> подставляется код экземпляра соответствующего модуля. Вместо <sids> подставляются коды услуг через запятую, это уточняющий и не обязательный параметр, если он не указан, будут взяты все услуги.

Если не указано, то позиция принимается за единицу.

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

В указывается просто строка вида «Мб», «Кб», «мин.». Если параметр не указан, то единицы принимаются за «шт.». Параметр определяет цифровой код единицы измерения. Если параметр не указан, то подставляется код 796, который, согласно Общероссийскому классификатору единиц измерений, соответствует единице измерения «шт.».

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

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

Рассмотрим несколько примеров построения позиций.

bill.pos.1.title=Долг за услуги Интернет
bill.pos.1.name=Долг за услуги Интернет за $month 
bill.pos.1.summ=DEBT($month)

bill.pos.1.title=Долг за услуги Интернет и Телефонию
bill.pos.1.name=Долг за услуги Интернет и Телефонию за $month 
bill.pos.1.summ=SERVICE_ACCOUNT($month, 2, 3 )
bill.pos.2.title=Абонплата за Интернет и Телефонию
bill.pos.2.name=Абонплата за Интернет и Телефонию за $nextmonth
bill.pos.2.summ=SERVICE_ACCOUNT($nextmonth,1 )
# 
invoice.pos.1.title=Услуги Интернет и Телефонии
invoice.pos.1.name=Услуги Интернет и Телефонии за $month
invoice.pos.1.summ=SERVICE_ACCOUNT($month, 2, 3)
invoice.pos.2.title=Абонплата за Интернет и Телефонию
invoice.pos.2.name=Абонплата за Интернет и Телефонию за $month
invoice.pos.2.summ=SERVICE_ACCOUNT($month, 1)

invoice.pos.3.summ=SERVICE_AMOUNT($month,101,102)+CHARGE($month,14,8,1,54,32)

bill.pos.3.title=Расходы
bill.pos.3.name=Расход
bill.pos.3.extractor=KERNEL_CHARGES($month)

# Код начисления
tariff_detail.cost_type.1=Включённый трафик
# Дополнительные параметры, range_take_all=1 предназначен для ветки диапазон, 
# если установлен, то независимо от того, сколько наработал в этом диапазоне договор, 
# количество наработки будет равняться кол-ву в диапазоне
tariff_detail.cost_type.1.range_take_all=1
# Код услуги, по которому отбираются договоры для обсчёта range_take_all 
# (т.к. договор может не иметь наработки совсем)
tariff_detail.cost_type.1.range_take_all.sid=
tariff_detail.cost_type.2=Превышение трафика

#код начисления
tariff_detail.cost_type.1=Включённый трафик (макс)
tariff_detail.cost_type.1.calc_type=2

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

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

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

Здесь X - это количество цифр, выделяемых под соответствующий номер, т.е. подставляемые номера дополняются нулями слева до длины, определенной этим числом.

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

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

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

.

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

create.only.when.pos.positive=x,y,…,z — создание счетасчета-фактуры только в том случае, если указанные позиции с кодами x,y,…,z положительны.

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

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

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

4. Настройка параметров договора

Замечание

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

5. Выставление счетов и счетов-фактур администратором

6. Работа со счетами

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

Если код спискового параметра указан верно в фильтре , в окне управления счетами будут отображаться допустимые значения спискового параметра договора. Например, это может быть: Запад, Центр, Восток. Или иное деление. В общем случае, пачка может нести любой смысл, позволяя разделить документы.

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

7. Работа со счетами-фактурами

8. Панель просмотра документов

9. Генерация печатных форм

Внимание

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

1. сумму документа;

2. набор позиций с суммами;

3. параметр НДС из конфигурации модуля;

4. параметры договора;

5. реквизиты модуля Бухгалтерия из договора;

6. INLINE-параметры — специфичные для текущего пользователя (номера доверенностей, Ф.И.О.).

Замечание

При модификации и отладке XSLT-шаблона следует отключить кэширование XSLT-шаблонов (опция в конфигурации сервера биллинга).

10. Отчёты договора модуля

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

Замечание

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

Замечание

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

12. Тонкости интеграции с внешними (1С) системами

13. Групповые операции над договорами

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

1. Назначение модуля

2. Структура и настройка модуля

3. Настройка gpg-подписи для Yandex.Деньги

4. Настройка WebMoney

5. Использование модуля

1. Назначение модуля

2. Настройка модуля

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

2. Номер транзакции создается следующим образом: берется ID транзакции из таблицы и соединяется с шаблоном. Например: если шаблон а ID пусть будет 34, тогда номер транзакции, отсылаемый на платежный шлюз BVCom, будет иметь вид:

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

3. Оплата через систему BVCom

4. Мониторинг платежей

5. Возврат платежей

1. Назначение модуля

2. Настройка модуля

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

sa=ru.bitel.bgbilling.modules.cerbercrypt.server.CerbercryptServiceActivator
server.0.host=192.168.168.10
server.0.port=8100
server.0.login=admin
server.0.pswd=xxxxx

Поддерживается всё железо аналогичное: CerberCrypt, DVCrypt, Teleview и прочие, в том числе настраивающиеся согласно документации CerberCrypt. Обратите внимание на права пользователя CerberCrypt, под которым происходит авторизация на удалённом сервере CerberCrypt (в примере выше — admin), ему нужно дать необходимые права для того, чтобы использовать все функции протокола (установление, чтение подписки и прочие).

Для Pisys Irdeto укажите адрес, порт и код оператора:

sa=ru.bitel.bgbilling.modules.cerbercrypt.server.PisysServiceActivator
server.0.host=192.168.168.10
server.0.port=80
server.0.operatorTag=
server.0.nationality=RUS
#регион (MO, BA, SA)
server.0.regionTag=

Для системы NordE/CTI примерная конфигурация такова:

sa=ru.bitel.bgbilling.modules.cerbercrypt.server.NordE2ServiceActivator

server.0.host=localhost
server.0.port=7000
server.0.timeout=5000

server.0.smsNumber=1
server.0.providerId=1
server.0.charset=ISO8859-1
server.0.providerName=Test Provider

server.0.emailEnable=1
server.0.emailDurationTime=1
server.0.emailInterval=1
server.0.emailTitle=Заголовок письма
server.0.emailFrom=Письмо от

server.0.osdEnable=1
server.0.osdTimes=1
server.0.osdInterval=1
server.0.osdTitle=Заголовок сообщения
server.0.osdFrom=Сообщение от

# период в днях, на сколько каждый раз продлевается активация (при подписке пакета на открытый период).
# для активаторов, которые (опционально) продлеваются постепенно: NordE2, .
# чтобы продлять на "бесконечно", ставится либо 100500 дней, либо параметр вообще не прописывается (по дефолту возьмётся опять же какое-то большое кол-во дней).
# если стоит небесконечный период, то обязательно запускать задачу "Постепенное продление подписки", которая будет сдвигать период по исходу этого кол-ва дней.
period.gradually.subscription=30

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

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

Номера пакета — вводится вручную при добавлении или редактировании пакета в поле «Номер пакета (код)».

Пример конфигурации оборудования, с которым тестировался данный протокол: сремблеры двух компаний родные Compunicate, и компании Gospell, любые современные железки от них совместимы с CAS. Oracle можно использовать любой. Версии модулей софта Conditional Access System : CAS Encryption Control System V2.02, CAS ECMG V2.545, CAS EMMG V2.5.4, CA Manager V2.0.2, SMS Console V2.00 2007.09. Для обмена данными между системами биллига различных разработчиков служит ПО SMS Console, версия консоли зависит от версии системы кодирования.

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

Система conax (beta-версия) требует подобную конфигурацию:

sa=ru.bitel.bgbilling.modules.cerbercrypt.server.ConaxServiceActivator
# Параметры сервера (т.е. ftp-аккаунт)
server.0.host=localhost
server.0.port=21
# Параметры аккаунта логин/пароль
server.0.username=anonymous
server.0.password=
# Корневой каталог относительно текущего-каталога-сразу-после-входа,
# относительно него уже ищутся каталоги autreq/req, autreq/ok, autreq/err
# (они тоже должны существовать)
# по умолчанию "." (точка, текущий каталог, т.е. никуда не делаем переход)
server.0.pwdroot=pub/conax

Система Gospell. Режим работы — с пакетами. Везде подразумевается один сервер; коннект берётся везде нулевой.

# активатор Gospell
sa=ru.bitel.bgbilling.modules.cerbercrypt.server.GospellServiceActivator

# настройки соединения
server.0.host=localhost
server.0.port=2888
server.0.timeout=5000

# заголовок email
server.0.emailTitle=email

# параметры osd (см. протокол)
server.0.osdShowTimeLength=30
server.0.osdShowTimes=0
server.0.osdPriority=0
# expired time, в секундах (1 день = 24*60*60)
server.0.osdExpiredTimeSecond=86400

Тестовый активатор, просто выводит всё в лог с уровнем DEBUG:

sa=ru.bitel.bgbilling.modules.cerbercrypt.server.TestServiceActivator

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

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

К каждому пакету должна быть указана услуга, на которую будет начислена наработка за пользование этим пакетом. Если необходима возможность включения/выключение пакета через Web, то следует установить флаги «Добавление через WEB» и «Закрытие через WEB». Если пакет должен быть всегда доступен пользователям («социальный пакет»), то необходимо установить галочку «Не блокируемый». Такой пакет не будет блокироваться задачей «Блокировка CerberCrypt».

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

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

<номер карты>t<пароль карты>

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

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

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

Формат перечисления карт приведён под окошком. Формат «n+k» означает k карт начиная с номера n. Отбор карты у дилера производится аналогично. Дилеры представляют из себя как реальных агентов по продаже карт, так и фиктивные контейнеры для учёта повреждённых карт, утерянных и т.п.

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

3. Настройка клиентов

4. Дополнительные возможности для Irdeto Pisys, CTI/NordE итд

5. Типы оборудования

6. «Мультирум»

7. Настройка задач планировщика

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

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

mid=<код модуля>

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

mid=<код модуля>

Осуществляется задачей планировщика . Рекомендуемая частота запуска — один раз в сутки. Целесообразно запускать задачу в первом часе каждых суток (например, в 0 часов 30 минут каждые сутки), тарификация производится включая текущие сутки с учётом актуальных статусов пакетов, установленных задачей .

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

mid=<код модуля>

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

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

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

mid=<код модуля>
# сколько часов от суток "прощать" при блокировке
forgive.hours=2

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

Если у пакета установлен параметр «Не блокируемый», то в этой задаче он обрабатываться не будет.

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

В параметрах задачи указывается код модуля и адрес E-Mail на который высылаются сообщения о недоступности сервера CerberCrypt.

mid=<код модуля>
error.mail=bill@bill.ru
#через запятую можно указать номера карт, подписку для которых обновлять не следует
#ignore.cards=
#указываются группы договоров, подписку на которых обновлять не следует
#ignore.contract.groups=

Специфика некоторых систем (CTI/NordE, conax и т.д.) такова, что при указании подписки они требуют период активации, в отличие от протокола CerberCrypt, например, где подписка ставится/снимается сиюминутная. В данном случае существует примерно такое стандартное поведение:

* открываем пакет с закрытой датой закрытия — так и отсылаем;

* открываем пакет с бесконечностью — ставим большой правый период.

Встаёт задача: как-то решить недостаток от продления пакета в бесконечность и последующим отключением пользователем самого себя от системы с целью пользоваться картой вечно. Сократить подобное пользование до разумного периода. Т.е. в том числе это защита от «хитрых клиентов».

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

Это делается через задачу планировщика ». Приэтом в БД создается отдельная таблица «продление пакетов/каналов», поля: entityId — идентификатор картпакета, date — дата последнего продления «сущности». Таблица не критичная, её содержимое можно удалить, тогда просто считается, что последний раз для закрытых периодов картпакетов уже было отослано, а для открытых было отослано в начале открытия на месяц, так что при следующем запуске этой задачи все они снова продлятся. В любом случае всё продлится и заново начнётся отсчёт при любом редактировании картпакета.

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

а) либо с закрытым периодом, тогда ничего не делаем, ибо полагаем, что уже было всё отослано один раз;

б) либо с открытым, тогда берётся для каждого картпакета из указанной таблички одна дата — дата последнего успешного продления (точнее, до какого числа РЕАЛЬНО было продлено).

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

Период (например, как выше названо «месяц») настраивается в задаче самой конфигурации модуля (т.е. в конфигурации данного активатора).

period.gradually.subscription=30

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

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

Пользователь открывает пакет в биллинге, указывает только дату начала активации пакета: на карту шлётся период ДАТА_НАЧАЛА — ДАТА_КОНЦА, где ДАТА_КОНЦА = ДАТА_НАЧАЛА + 30 дней; в таблицу записывается реальный период и системный (реальный — ДАТА_НАЧАЛА — ДАТА_КОНЦА, а системный ДАТА_НАЧАЛА — (открытая_дата))

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

Имеется специальная задача контроля синхронизации, которая отвечает за корректную отправку синхронизаций по картам. То есть, если в момент синхронизаций сервер УД был недоступен, то подписка уйдёт только в лучшем случае при следующем изменении карты или на границе суток, когда запустится задача общей синхронизации (если она будет успешна). Задача контроля синхронизации следит за картами с флагом «требует синхронизации» и при наличии карт с ним ставит синхронизатор по ним снова в очередь. Задача необязательна, период настраивается также по желанию нужной оперативности при возможных сбоях сервера УД.

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

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

8. Настройка тарифных планов

9. Возможности Web-интерфейса модуля

10. Создание договоров пользователем через Web

11. Виртуальный кинозал

12. Лог синхронизаций

1. Назначение модуля

Замечание

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

2. Установка и настройка модуля

3. Использование модуля

Внимание

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

1. Назначение модуля

Замечание

В настоящее время для данного модуля разработана более современная замена — модуль Inet. Модуль DialUp оставлен для совместимости и постепенно будет удалён.

2. Базовые понятия и алгоритм работы модуля

Кроме одноимённого протокола RADIUS-сервером применяется протокол SNMP — для постоянной проверки активности соединения и его принудительного разрыва. Т.к. RADIUS-сервер обсчитывает соединение в реальном режиме времени, нужна постоянная информация о статусе соединения, чтобы предотвратить обсчёт соединения, если клиент вышел, но по какой-либо причине Stop сигнал не пришёл. Кроме того по SNMP происходит посылка сигнала на окончание сессии, если клиент вышел за 0 своего баланса.

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

Начиная с версии 3.5_p4 модуль содержит встроенный NetFlow-коллектор, позволяющий анализировать NetFlow потоки NASа и делить трафик соединения по типам.

RADIUS-сервер для модуля DialUp может работать в двух режимах:

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

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

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

Преимущества: Точное время сброса клиента, если не идёт обсчёт трафика.

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

б) Режим пересчёта по Update-пакетам (). Пересчёт происходит по получению Update-пакета, если после этого баланс будет отрицателен, идёт сигнал на завершение соединения.

: Уменьшенная нагрузка на сервер обсчёта, обсчёт происходит только по сигналам Update.

:

— Необходима поддержка на NASе Update-пакетов;

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

Предпочтительным режимом работы является Update, режим работы может быть установлен как глобально на BGRadiusDialup в конфигурации модуля, так и персонально для каждого NASа.

Каждое соединение в ходе своей жизни проходит несколько статусов: , , . После авторизации статус соединения становится до прихода Start-пакета. Таймаут максимального ожидания старта задаётся переменной конфигурации модуля. Если в течении указанного времени Start-пакет по Nas-Port не будет получен, соединение удаляется.

После прихода старта статус становится до момента подтверждения активности по SNMP (CHECKER режим) или посредством Update-пакета (UPDATE режим). При положительном результате проверки статус переходит в , соединение учитывается при подсчёте активных соединений логина, идёт обсчёт его времени и трафика.

Если в течении некоторого времени не приходят UPDATE-пакеты (для режима UPDATE, таймаут задаётся переменной конфигурации модуля в секундах), либо результат проверки по SNMP показывает, что соединение неактивно — оно вновь переходит в статус .

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

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

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

Все соединения RADIUS-сервера должны быть сброшены после наступления нового месяца. Для этого можно устанавливать опцию в конфигурации NASа =1, либо производить корректное завершение сессий на NASах иными средствами. Требование разрыва на границе месяца связано с особенностью тарификации биллинга.

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

1) При режиме тарификации , после получения UPDATE-пакета:

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

2) При режиме тарификации CHECKER (устаревший режим). Тарификация осуществляется по таймеру, периодически просыпающимся потоком. При каждом обсчёте:

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

Описание атрибутов, специфичных для NASа, необходимо смотреть в документации к NASу.

3. Настройка модуля

4. REALMы

5. Наборы атрибутов

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

2. задания опций работы для тарифного плана (см. далее настройку тарифов).

6. Выдача атрибутов соединения и выделение IP адресов

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

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

3. Выбираются атрибуты, установленные в свойствах логина на вкладке ;

4. Если на вкладке установлена опция присваивания атрибутов , то выдаются атрибуты для текущего REALMа соединения, указанные в конфигурации модуля и NASа;

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

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

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

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

4. Делается попытка выдачи адреса из глобального пула, определённого в конфигурации модуля как .

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