Инструкция по обновлению с версий 3.5-7.0 до версии 7.1

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

1) Установите и настройте MQ сервер. Как это сделать описано в документации.
   http://bgbilling.ru/v5.2/doc/ch01s05s03.html
2) Выполните в "SQL Редакторе" либо с помощью mysql клиента запрос:
   ALTER TABLE `installed_modules` ADD COLUMN `uninstall` LONGTEXT;    
3) BGBilling c версии с 5.1 должен быть запущен под JDK не JRE! При необходимости установите JDK     

1) Подсоеденитесь к mysql с правами root используя консольного клиента 
	mysql -uroot -p bgbilling
И выполните команды:
	GRANT ALL PRIVILEGES ON bgbilling.* TO 'bill'@'localhost' IDENTIFIED BY 'bgbilling';
	GRANT ALL PRIVILEGES ON bgbilling.* TO 'bill'@'%' IDENTIFIED BY 'bgbilling';
Это позволит инсталлятору биллинга выполнять команды ALTER, что было запрещено ранее.

2) Если вы используете управление шлюзом в IPN модуле - сохраните все шаблоны правил
   в файл и создайте в дальнейшем на их основе типы правил для шлюза типа manad.

1) В "Сервис=>SQL Редактор" либо с помощью mysql клиента выполните запрос:
	ALTER TABLE installed_modules ADD COLUMN `id` INT  NOT NULL AUTO_INCREMENT PRIMARY KEY;
	
2) Перед обновлением модуля MPS до 4.3 выполните в "SQL Редакторе" либо с помощью mysql клиента запросы:
	ALTER TABLE mps_payment_$mid_$yyyy$mm ADD `type` INT NOT NULL DEFAULT 0
	ALTER TABLE mps_payment_$mid_$yyyy$mm ADD rawNumber VARCHAR(20) NOT NULL DEFAULT ''
   где $mid - код модуля MPS, $yyyy - год и $mm - месяц, для текущего и предыдущих месяцев.
3) В "Сервис=>SQL Редактор" либо с помощью mysql клиента выполните запрос: 
	SHOW COLUMNS FROM contract_status;

   Если таблица присутсвует и имеет следующий вид
	+--------+---------------------+------+-----+---------+-------+
	| Field  | Type                | Null | Key | Default | Extra |
	+--------+---------------------+------+-----+---------+-------+
	| cid    | int(10) unsigned    | NO   |     | 0       |       |
	| mid    | int(11)             | NO   |     | 0       |       |
	| status | tinyint(3) unsigned | NO   |     | 0       |       |
	+--------+---------------------+------+-----+---------+-------+
  , удалите ее: 
  	DROP TABLE contract_status;
  	Если она имеет другой вид, то не трогайте ее.

4) В "Сервис=>SQL Редактор" либо с помощью mysql клиента выполните запрос : 
 	describe contract_status_log;
 	Если таблица присутсвует и имеет следующий вид
	+---------+------------------+------+-----+---------------------+-------+
	| Field   | Type             | Null | Key | Default             | Extra |
	+---------+------------------+------+-----+---------------------+-------+
	| dt      | datetime         | NO   |     | 0000-00-00 00:00:00 |       |
	| cid     | int(10) unsigned | NO   |     | 0                   |       |
	| mid     | int(11)          | NO   |     | 0                   |       |
	| action  | tinyint(4)       | NO   |     | 0                   |       |
	| uid     | int(11)          | NO   |     | 0                   |       |
	| comment | char(200)        | NO   |     |                     |       |
	+---------+------------------+------+-----+---------------------+-------+
	, удалите ее:
  DROP TABLE contract_status_log;
  
  Если она имеет другой вид, то не трогайте ее.

1) В "Сервис=>SQL Редактор" либо с помощью mysql клиента выполните запрос: 
ALTER TABLE `installed_modules` ADD COLUMN `uninstall` LONGTEXT;

1) Произведите настройку перечня статусов договоров в ядре.
   Перечень статусов, переменные contract.status.list, contract.status.no.manual.set: http://bgbilling.ru/v5.2/doc/ch01s18s09.html
   Либо скопируйте все переменные из конфигурации по умолчанию, получив аналог параметров 5.1 системы: http://bgbilling.ru/v5.2/doc/ch01s10s01.html
      
2) Если вы используете систему работы с кредитовыми договорами: http://bgbilling.ru/v5.2/doc/ch01s18s09.html#d0e3685
   То вам необходимо установить переменные конфигурации сервера credit.contract.active.status и credit.contract.open.by.payment.status.

3) Установите активные статусы по модулям:   
   RentSoft: http://bgbilling.ru/v5.2/doc/ch06s03.html    
   VoiceIp: http://bgbilling.ru/v5.2/doc/ch31s03.html 
   DialUp: http://bgbilling.ru/v5.2/doc/ch15s03.html
   IPN: http://bgbilling.ru/v5.2/doc/ch19s02.html
   E-Mail: http://bgbilling.ru/v5.2/doc/ch17s02s02.html
   CerberCrypt: http://bgbilling.ru/v5.2/doc/ch13s02.html
   Phone: http://bgbilling.ru/v5.2/doc/ch24s02.html
   
   Переменные contract.status.active.codes и contract.status.suspend.codes (не во всех модулях).
   
   Если использовали до этого флаг dbinfo.allow.to.change.status в клиента, то нужно удалить его 
   и использовать contract.status.no.manual.set в конфигцрации сервера вместо него ( внимание смысл обратный - тут отрицание).    

4) Для модуля NPay установите переменную contract.status.suspend.codes: http://bgbilling.ru/v5.2/doc/ch22s02.html

   В модуле абонплат перенастроить логику замещающих абонплат и неприостанаваливаемых абонплат.
   Вместо переменных service.no.suspend, service.no.suspend.in.suspend, service.no.suspend.in.close, wrap.service 
   указать новые согласно документации (старые можно оставить, сопроводив комментарием об удалении после обновления).
   
   Укажите статусы договоров для дебетовых абонплат, если вы их используете:
   http://bgbilling.ru/v5.2/doc/ch21s07.html
   
5)  Для версии >=5.2 база данных должна работать на транзакционном движке InnoDb. Исключение составляют таблицы "мусорных" баз.
   Если вы используете движок MyIsam, выполните настройку и конвертацию: 
   http://wiki.bgbilling.ru/index.php/%D0%A0%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D0%B0%D1%86%D0%B8%D0%B8_%D0%BF%D0%BE_%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B5_MySQL
   
   Проверить движок можно SQL запросом SHOW TABLE STATUS, третий столбец Engine. При конвертации можно пропустить старые помесячные таблицы с сессиями, 
   наработкой сессий и т.п., т.к. они рано или поздно будут удалены и более не правятся.
   
6) В настройке задач планировщика удалите задачи "Пользовательские рассылки" и "Рассыльщик почты", данный функционал перенесён в плагин рассылок.

7) Обновите конфигурацию activemq из ftp://ftp.bgbilling.ru/pub/bgbilling/activemq/linux/apache-activemq-5.4.2/conf/activemq.xml

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

1) Начиная с версии 5.2 все шаблоны FO должны быть строговалидны. Если вы писали сами (или правили дистрибутивные)
	карточки договора, шаблоны счетов, счетов-фактур итд, то вам надо дополнительно проверить
	их на валидность стандарту FO-XSL. Варианты:
	а) использовать заново файлы из дистрибутива или изменить их снова, там они подправлены и заведомо корректные;
	б) проверить любым fo-xsl редактором на валидность свои шаблоны;
	в) использовать простой fo-валидатор, указывающий (но не исправляющий!) все ошибки, встречавшиеся
	во всех дистрибутивных fo-xsl документах.
	Дополнительная информация: http://forum.bgbilling.ru/viewtopic.php?t=4942
	Ссылка: ftp://ftp.bgbilling.ru/pub/bgbilling/util/fo_validator.zip
	
	   	
2)	Плагин cachcheck: понятие очереди печати изменилось. Также изменились вид и имя таблицы в БД, экшены сменились на вебсервисы.
	Старая таблица остаётся на месте, всё копируется в новую. Если используете в отчётах таблицу, обратите внимание, что надо указать новую.
	Если у вас были какие-то внешние обращения к экшенам или БД (приложения, отчёты) обратите на это внимание.
	Вместо скриптов формирования вида чека используется динамический код. Если у вас самописные скрипты, потребуется постепенно переписать.
	В настройках плагина параметры сервер и порт регистратора не поддерживаются, используется параметр connector.
	Дополнительная информация: http://forum.bgbilling.ru/viewtopic.php?t=6194
	
3) Если у вас был скриптовый обработчик события "Приход платежа" и вам нужно обрабатывать так же и изменение лимитов этим
	обработчиком( до версии 5.2 при изменени  лимита генерировалось событие "Приход платежа"), то нужно также обработать и событие "Изменение Лимита договора"
	(проставте галочку возле этого события тоже) .			   
	
4)  Структура WiFi-агента для модуля Dilaup кардинально поменялась, нужно скачать его целиком с сайта, настроить заново. 
Обратите вимание на: 
	а) имя конфигурационного файла поменялось на dialup_wifi.properties, 
	б) опция  billing.server.dialup.mid заменилось на  billing.server.moduleId, добавились новые опции,
	в) добавились настройки activemq 
	г) встроенные команды вынесены во внешние скрипты, 
	д) перед запуском нужно запустить update.sh, 
	е) в setenv.sh прописать JAVA_HOME, 
	ж) более подробно читайте в документации .  
	
5) Плагин CRM. Так как в 5.2. появилась возможность настраивать список статусов задач, то для хранения истории изменения статусов была добавлена новая таблица register_task_log
если вам нужна история изменения статуса для старых задач, то нужно выполнить несколько sql запросов для того, что бы заполнить таблицу register_task_log данными

 insert into register_task_log select id, open_dt, open_uid, 0 from register_task;
 insert into register_task_log select id, accept_dt, accept_uid, 1 from register_task;
 insert into register_task_log select id, close_dt, close_uid, 2 from register_task;
 
6) Если вы используете Slave базы, скорректируйте параметры в URL подключения к БД согласно документации.	   
	http://bgbilling.ru/v5.2/doc/ch01s24s02.html 

1) Перейдите в режиме командной строки (для Windows - cmd либо Far) в каталог BGBillingServer и выполните:

	Для LINUX:   <путь к Java>/bin/java -Dnetworkaddress.cache.ttl=3600 -Xmx256m -Djava.awt.headless=true -cp .:./lib/app/*:./lib/ext/*  bitel.billing.server.contract.ServiceNormalizer
	Для Windows: <путь к Java>\bin\java -Dnetworkaddress.cache.ttl=3600 -Xmx256m -Djava.awt.headless=true -cp .:./lib/app/*:./lib/ext/*  bitel.billing.server.contract.ServiceNormalizer
	Для FreeBSD: (по рекомендации пользователей):java -Dnetworkaddress.cache.ttl=3600 -Xmx256m -Djava.awt.headless=true -cp ".:./lib/app/*:/lib/ext/*" bitel.billing.server.contract.ServiceNormalizer
	
	Программа сопоставит модули договорам на основании привязанных услуг модулей а также подключит абонплаты модуля NPay на основании подключенных услуг модуля. 
	Проверьте, подключились ли модули и абонплаты к договорам после выполнения данной команды. 
	Команду можно запускать многократно впоследствии, например, если у вас где-нибудь производится 	привязка абонентских плат к договору посредством занесения услуги модуля. 
	Будут перенесены только недостающие абонплаты и привязаны только недостающие модули.

2) Перейдите в режиме командной строки (для Windows - cmd либо Far) в каталог BGBillingServer и выполните:
	Для LINUX:   <путь к Java>/bin/java -Dnetworkaddress.cache.ttl=3600 -Xmx256m -Djava.awt.headless=true -cp .:./lib/app/*:./lib/ext/*  bitel.billing.server.contract.ServicePatternNormalizer
	Для Windows: <путь к Java>\bin\java -Dnetworkaddress.cache.ttl=3600 -Xmx256m -Djava.awt.headless=true -cp .:./lib/app/*:./lib/ext/*  bitel.billing.server.contract.ServicePatternNormalizer
	Для FreeBSD(по рекомендации пользователей):java -Dnetworkaddress.cache.ttl=3600 -Xmx256m -Djava.awt.headless=true -cp ".:./lib/app/*:/lib/ext/*" bitel.billing.server.contract.ServicePatternNormalizer
	Программа сопоставит модули шаблонам договоров на основании привязанных услуг модулей. Проверьте, подключились ли модули к шаблонам договоров после выполнения данной команды.

1) Если вы используете воип модуль добавьте в его конфигурации
	#
	findmode.0.title=Поиск по User-Name=LOGIN
	findmode.0.value=User-Name=LOGIN
	findmode.1.title=Поиск по User-Name=ALIAS
	findmode.1.value=User-Name=ALIAS
	findmode.2.title=Поиск по Calling-Station-Id=ALIAS
	findmode.2.value=Calling-Station-Id=ALIAS
	#
	find.order=0,1,2
   
   И во всех логинах которые находятся не по User-Name=LOGIN проставьте нужные
   режимы поиска.
   
2) Внимание!!!
   При использовании NetFlow коллектора для модуля IPN необходимо обновлять 
   биллинг во время с минимальным трафиком.

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

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

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

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

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

1) Скорректировать шаблоны кредитовых договоров для установки большого отрицательного лимита. Например, -10000000.

2) В "Сервис=>SQL Редактор" либо с помощью mysql клиента выполните запрос: 
	UPDATE contract SET closesumma=-1000000 WHERE mode=0
	
3) Для каждого из экземпляров dialup модуля выполните запрос в "Сервис=>SQL Редактор" ибо с помощью mysql клиента:
	ALTER TABLE session_detail_<mid>_<yyyyMM> ALTER COLUMN summa SET DEFAULT 0;
   где <mid> - код экземпляра модуля
   <yyyyMM> - текущие год и месяц, например 200801
   При выведении ошибки  Unknown column 'summa' in 'session_detail_...' пункт пропустить и перейти к следующему.

1) Для модуля IPN. 
   При переходе на версию 4.5 поменялась работа со шлюзами и типами правил для шлюзов Manad, Cisco, Miktotik, BGRadiusIPN .
   
   1.1. После обновления откройте список типов правил - он теперь не привязан к конкретному шлюзу и поэтому отображается полный список типов правил.  
   Если у вас много различных типов шлюзов, то чтобы  не путаться рекомендуется в зависимости от содержимого переименовать типы правил, так , 
   чтобы название типа шлюза было в названии правила ..Например manand_128, manad_256, cisco..
   
   1.2. При использовании типа шлюза Manad под FreeBSD со старым синтаксисом нужно добавить теги <LOOP></LOOP>. Т.е если у вас был тип правила:
	pipe {P0} config bw 512000
	pipe {P1} config bw 512000
	add {N1} pipe {P0} all from any to {A}
	add {N1} pipe {P1} all from {A} to any
   Его заменяем на :
	<LOOP>
		pipe {P0} config bw 512000
		pipe {P1} config bw 512000
		add {N1} pipe {P0} all from any to {A}
		add {N1} pipe {P1} all from {A} to any
	</LOOP>
   
   1.3. Для типов шлюзов Manad, Cisco, Mikrotik перенесите текст типов правил в команды типа шлюза. Синтаксис  команд в типе шлюза описан в документации 4.5(и выше). 
   При переносе типов правил Mikrotik обратите внимание, что нужно заменить теги <OPEN></OPEN> и <CLOSE></CLOSE> на [OPEN][/OPEN] и [CLOSE][/CLOSE] соответственно. 
   И нужно продублировать содержимое тега [CLOSE][/CLOSE] в теге [DELETE][/DELETE].

   1.4. Для типов шлюзов Manad, Cisco, Miktotik, BGRadiusIPN нужно указать какие типы правил доступны на данном типе шлюзе. 
   При редактировании типа шлюза есть вкладка "Типы правил". Туда нужно добавить соответствующие правила.
   
   1.5. Оптимизировать правила для Manad, Сisco, Mikrotik. Покажем на примере. Допустим, у вас был тип шлюза Manad и не нем следующие типы правил:
	Стандартный клиент 256: 	
		<LOOP>		
			pipe {P0} config bw 256000
			pipe {P1} config bw 256000
			add {N2} pipe {P0} all from any to {A}
			add {N2} pipe {P1} all from {A} to any
		</LOOP>
	Стандартный клиент 512:
		<LOOP>
			pipe {P0} config bw 512000
			pipe {P1} config bw 512000
			add {N1} pipe {P0} all from any to {A}
			add {N1} pipe {P1} all from {A} to any
		</LOOP>
	Вы создаете в типе шлюза следующую конфигурацию :
	[DEFAULT]
		<LOOP>
			pipe {P0} config bw ${speed}
			pipe {P1} config bw ${speed}
			add {N2} pipe {P0} all from any to {A}
			add {N2} pipe {P1} all from {A} to any					
		</LOOP>
	[/DEFAULT]

	Типы правил изменяете. Стандартный клиент 256: speed=256000; Стандартный клиент 512: speed=512000.

2) Если вы использовали смену тарифных планов пользователем через Web интерфейс,
   произведите настройку данной подсистемы заново, основываясь на документации:
   http://bgbilling.ru/v4.5/doc/ch01s21s08.html

3) В справочниках привязать улицы, районы, кварталы к городам. 
   Если у вас один город то можно привязать следующим образом.
   В В "Сервис=>SQL Редактор" либо с помощью mysql клиента выполните запросы: 
	UPDATE address_street SET cityid=<id города>  
	UPDATE address_area SET cityid=<id города>
	UPDATE address_quarter SET cityid=<id города>
    
   <id города> получаем в справочниках городов нажатием Ctrl+i.

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

2) Для всех шаблонов договоров проставьте сохраненные в пункте 3 абонентские платы.

3) При обновлении DHCP_IPN. Посмотреть новую документацию настройки шлюза DHCP для конретного шлюза(Dlink или Cisco2).
	В версии 4.6 изменилось зачение dhcp.82.key.position и добавилась новая опция dhcp.82.key.option.code. Их нужно правильно задать.
	Для Dlink:
	 dhcp.82.key.option.code=1
	 dhcp.82.key.position=5
	для Cisco2:
	 dhcp.82.key.option.code=1
	 dhcp.82.key.position=2

4) IPN. Если вы используете шлюз Zyxel, то надо в командах типа шлюза заменить все теги вида <LOOP></LOOP> на <LOOP_PORT></LOOP_PORT>.

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

6) IPN. Выполните в "SQL Редакторе" либо с помощью mysql клиента запросы:
ALTER TABLE ipn_contract_data_$mid_$yyyy$mm MODIFY COLUMN cost FLOAT(10,5)  NOT NULL DEFAULT 0;	
   где $mid - код модуля IPN, $yyyy - год и $mm - месяц, для текущего и предыдущих месяцев.
   Если не планируете делать преобсчет для старых месяцев, то может не обновлять для них(обновите только последний). 
   В новых создаваемых таблицах этого столбца не будет.   
    
7) IPN. если вы использовали шлюз Cisco2 в связке с дочерним шлюзом Zyxel , то нужно заменить в конфигурации шлюза 
строку:  
gate_manager.class=bitel.billing.server.ipn.vlan.CiscoVlanGateWorker
на :
gate_manager.class=bitel.billing.server.ipn.vlan.CiscoVlanParentGateWorker

1) Модуль IPN. Если вы используете типы шлюзов, в командах которых есть 
циклы вида <LOOP_NET> и <LOOP_NET_MASK>, то нужно поменять команды следующим образом
	a) В циклах LOOP_NET макросы {NET} заменить на {IP}/{MASK_BIT}.
	б) В циклах LOOP_NET_MASK макросы {NET_MASK} заменить на {IP}/{MASK}.
Эти макросы стали более гибкими, для более полной информации читайте соотвествующий раздел документации.  	

2) Модуль IPN. Если вы использовали учет портов на шлюзе, и в конфигурации шлюза  ставили параметр
port.range, то его нужно переименовать в gate.range.

3) Модуль IPN. Если вы использовали учет vlan на шлюзе и в конфигурации шлюза  ставили параметр range, 
то его нужно переименовать в vlan.range.

4) Модуль отчеты. Если вы использовали ТАБЛИЧНЫЕ отчеты (файлики 
с расширением *.java в папке reports), то  в них нужно поменять строку:   
public void fillReport( con, filter, bitel.billing.server.reports.BGCSVReport.ReportResult result, pageSize, pageIndex )
на 
public void fillReport( con, filter, bitel.billing.server.reports.BGCSVReport.ReportResult result )
и убрать в коде отчета все упоминания переменных pageSize, pageIndex(если они у вас есть ).

5) Ядро. Необходимо запустить программу конвертации таблицы телефонов из старого формата в новый.
Перейдите в режиме командной строки (для Windows - cmd либо Far) в каталог BGBillingServer и выполните:
	Для LINUX:   <путь к Java>/bin/java -Dnetworkaddress.cache.ttl=3600 -Xmx256m -Djava.awt.headless=true -cp .:./lib/app/*:./lib/ext/*  ru.bitel.bgbilling.server.util.ContractParameterPhoneConvertor
	Для Windows: <путь к Java>\bin\java -Dnetworkaddress.cache.ttl=3600 -Xmx256m -Djava.awt.headless=true -cp .:./lib/app/*:./lib/ext/*  ru.bitel.bgbilling.server.util.ContractParameterPhoneConvertor
			
6) Модуль Dr.Web. Необходимо запустить программу конвертации таблицы агентов из старого формата в новый.
Перейдите в режиме командной строки (для Windows - cmd либо Far) в каталог BGBillingServer и выполните:
	Для LINUX:   <путь к Java>/bin/java -Dnetworkaddress.cache.ttl=3600 -Xmx256m -Djava.awt.headless=true -cp .:./lib/app/*:./lib/ext/*  ru.bitel.bgbilling.modules.drweb.server.convert.Convert $mid
	Для Windows: <путь к Java>\bin\java -Dnetworkaddress.cache.ttl=3600 -Xmx256m -Djava.awt.headless=true -cp .:./lib/app/*:./lib/ext/*  ru.bitel.bgbilling.modules.drweb.server.convert.Convert $mid
            
7) Модуль Бухгалтерии. Необходимо перейти на новую систему нумерации счетов и счетов-фактур. Нумерация типов
документов больше не задается в конфигурации модуля, вместо этого предлагается использовать "Пулы номеров".
Необходимо установить для пула номеров "По умолчанию (счета)" и "По умолчанию (счета-фактуры)" нумерацию, 
которая была ранее прописана в конфигурации модуля в соответствии с документацией по пулам номеров: 
http://bgbilling.ru/v5.1/doc_op/billing.html#d0e18884.

8) В конфигурации сервера, если у вас стоит параметр client.gui.contract.tree.order, то нужно добавить в него "face". Например:    
client.gui.contract.tree.order=parameters objects hierarchy status limit mode face balance tariff modules groups web tariffGroup script addAction memo
если параметра нет , то можно его не ставить.

9) Модуль Город. В связи с введением тегов вместо фирм, необходимо запустить конвертер для преобразования уже имеющихся фирм в теги. Конвертер работает в 2 этапа: сперва все фирмы 
переносятся в теги, а затем, для обратной совместимости, в договорах, входящих в группы, указанные в конфигурации модуля (параметр group.mask), прописываются теги, соответствующие 
фирмам. Запуск конвертера осуществляется следующим образом: запустите командную строку (cmd в ОС Windows; xterm, konsole (или любой другой) - в Linux), перейдите в каталог 
BGBillingServer и запустите:
    Для LINUX:   <путь к Java>/bin/java -Xmx256m -cp .:./lib/app/*:./lib/ext/*  bitel.billing.server.gorod.utils.Converter_firm2tag <групповая_маска> <mid>
	Для Windows: <путь к Java>\bin\java -Xmx256m -cp .:./lib/app/*:./lib/ext/*  bitel.billing.server.gorod.utils.Converter_firm2tag <групповая_маска> <mid>
	Для FreeBSD(по рекомендации пользователей):java -Xmx256m -cp ".:./lib/app/*:./lib/ext/*" bitel.billing.server.gorod.utils.Converter_firm2tag <групповая_маска> <mid>
где <групповая_маска> - битовая маска групп (без угловых скобок), для которых запускается конвертер (параметр group.mask из конфигурации модуля);
<mid> - код модуля город.

10) Обратите внимание на смену поведения прав пользователя по части доступа к группам( чтобы искало все договора без группы надо поставить режим "ИЛИ"):

http://bgbilling.ru/v5.1/doc/ch01s25s02.html

1) Если у вас стоят параметры contract.xslt, contract.csv.xslt  в конфигурации сервера, то поменяейте их в соотвествии с документацией, соотвественно на

contract.balance.xslt=contract_balance_print.xsl
contract.balance.csv.xslt=contract_balance_print_csv.xsl
[!] Убрали параметры contract.balance.xslt, contract.balance.csv.xslt, contract.balance.detail.csv.xslt, 
contract.balance.detail.xslt — если менялись шаблоны - надо поправить.

2) Установите права пользователей: Резервы, возвраты, типы резервов.

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

Смысл этого скрипта в том, что он копирует все данные из всех таблиц вида rscm_service_account_{mid}_yyyyMM 
в одну таблицу rscm_service_account_{mid}. 

#!/bin/bash                           

DB_PARAMS="-ubill -pbgbilling bgbilling"
TT=rscm_service_account_

BB=`mysql $DB_PARAMS -e "show tables like \\"${TT}%\\"" | grep -P "${TT}[0-9]+$" | cut -d _ -f 4`
AA=`mysql $DB_PARAMS -e "show tables like \\"${TT}%\\"" | grep -P "${TT}[0-9]+_"`

#echo $BB

for tableName in $AA;
do
  echo $tableName
  mysql $DB_PARAMS -e "INSERT INTO $TT$BB (cid, sid, date, amount, comment) SELECT cid, sid, date, amount, comment FROM $tableName"
done

4)  Если вы используете модуль paymaster, там поменялись названия почти всех опции . Зайдите в конфигурацию, там откройте шаблон и исправьте все параметры.
В частности параметр paymaster.LMI_MERCHANT_ID сменился на paymaster.merchant.id,  
paymaster.LMI_SUCCESS_URL сменился на paymaster.success.url и т.п. Все названия однозначно определяются.
Устаревшие опции подсвечиваются темно-серым цветом и находятся в конце списка. 
Обратите внимание на paymaster.LMI_INVOICE_CONFIRMATION_URL - его удалили вообще(но скорее всего у вас его и нет).   

5) Перейдите в режиме командной строки (для Windows - cmd либо Far) в каталог BGBillingServer и выполните:

Для LINUX:

<путь к Java>/bin/java -Dnetworkaddress.cache.ttl=3600 -Xmx256m -Djava.awt.headless=true -cp .:./lib/app/*:./lib/ext/* ru.bitel.bgbilling.kernel.task.server.TaskConverter

Для Windows:

 <путь к Java>\bin\java -Dnetworkaddress.cache.ttl=3600 -Xmx256m -Djava.awt.headless=true -cp .:./lib/app/*:./lib/ext/* ru.bitel.bgbilling.kernel.task.server.TaskConverter

Для FreeBSD:

java -Dnetworkaddress.cache.ttl=3600 -Xmx256m -Djava.awt.headless=true -cp ".:./lib/app/*:/lib/ext/*" ru.bitel.bgbilling.kernel.task.server.TaskConverter

6) Во всех приложениях( сервер билинга, BGInetAccess, BGInetAccounting, BGDaiusDialup, BGIPNNetflowCollector и т.п) поменялся url доступа к базе дынных. 
Там теперь characterEncoding=UTF-8 вместо cp1251. Но надо указать cp1251, если в вашей базе данных такая кодировка.
Если БД у вас в utf8 и collation в ней установлен utf8_unicode_ci (не utf8_general_ci) обратите внимание на параметр connectionCollation=utf8_unicode_ci , он обязательно должен соответствовать реальному collation БД.
Если БД у вас в cp1251, то connectionCollation нужно указать соответствующий правильный (или удалить).

1) Поменяйте настройки всех приложений ( BGInetAccess, BGInetAccounting, BGDaiusDialup, BGIPNNetflowCollector и т.п), чтобы запускались на на jdk 1.8.

2)  Модуль MPS.  Если не работает приход платежей, то возможно дело в кодировке. Раньше они по умолчанию была cp1251, теперь для каждой системы есть настройка :

https://docs.bitel.ru/pages/viewpage.action?pageId=43385605

1. Для модуля Inet: переместите параметр конфигурации accounting.deviceTypeIds из inet-access.xml (<param name="accounting.deviceTypeIds" value="x"/>) в конфигурацию модуля (accounting.deviceTypeIds=x), если еще не сделали этого.