Настройка стандартных схем СОРМ

Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.

Изменения (61)

просмотр истории страницы

h2. Первичные настройки

Для настройки отчётов *СОРМ* необходимо перейти в раздел *Управление абонентами и тарифами - Оборудование - Настройки СОРМ*. Если до этого Вы ещё не проводили данные настройки - будет открыто окно Мастера создания СОРМ. В нем будет предложено заполнить только название и схему. Если в списке схем нет необходимой для Вас схемы - Вы можете выбрать пользовательскую схему и настроить её под Ваши требования.
Все логи по данному функционалу находятся в файле */var/log/sorm.log*

!master_sorm.png|border=0,width=6700!

h2. Основные настройки для составления и выгрузки отчетов


!sorm.png|border=0,width=600!
!sorm_new.png|border=0,width=700!

После выбора схемы и нажатия кнопки *Сохранить* биллинг автоматически создаст в БД все настройки для данной схемы, такие как:
*Разделитель.* Разделитель будет общим на все отчёты, которые будут созданы в рамках этой схемы. Пример разделителя *;*(точка с запятой)

*Формат даты.* Формат даты будет общим для всех отчётов, которые будут создан в рамках это схемы. Он будет распространяться на *все* поля, которые можно распознать как дату.
Пример формата даты *%Y-%m-%d %H:%M:%S*
В данном случае:
Вы можете настроить любой формат даты, используя эти переменные

*Поля в кавычках.* Если данная опция выставлена - биллинг автоматически обернет каждое отдельное поле из отчёта в двойные кавычки.

*Кодировка.* utf-8 или cp1251. Файлы, выгружаемые на ftp или доступные для скачивания будут иметь указанную кодировку. Кодировка распространяется на все отчёты.

Так же на основной странице доступны кнопки *Установить настройки схемы* и *Подготовить отчёты*.
*Установить настройки схемы* заменяет все текущие настройки из списка на стандартные, которые соответствуют выбранной схеме
*Подготовить отчёты* удаляет все текущие отчёты и создает новые стандартные, которые соответствуют выбранной схеме
*Установить физ. лицам реквизит "Тип документа"* добавляет всем абонентам, которые являются физ. лицом, стандартный реквизит "Тип документа" со значением "Паспорт гражданина РФ"
{info} При первой настройке СОРМ функции кнопок *Установить настройки схемы* и *Подготовить отчёты* выполняются автоматически сразу после того, как будет введено название, выбрана схема и нажата кнопка *Сохранить* в *Мастере создания СОРМ{*}{info}

h2. Список отчётов

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

!sorm_reports.png|border=0,width=1000!

h2. Настройки отчётов

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

h3. Вкладка "Основные"

К основным относятся следующие:
* *Тип отчета* - \- метод, которым будет сформирован отчет для выгрузки данных в СОРМ;
* *Название* - \- Название отчета для отображения в веб-интерфейсе биллинга;
* *SQL запрос* - \- поле предназначено для указания запроса к БД при формировании отчета (работает только с "Типом отчета" - SQL)

h34. Различие типов отчета

|| Тип отчета Python || Тип отчета SQL ||
|!type_report_1.png|border=0,width=400!|!type_report_2_1.png|border=0,width=400!| | !type_report_1.png|border=0,width=400! | !type_report_2_1.png|border=0,width=400! |
| * Работает только для стандартных схем интеграции с СОРМ, представленных в биллинге;
* Не подлежит модификации пользователем, только через запрос к технической поддержки;
* Работает только при условии, когда в начальных настройках указаны указаны\\
"схема интеграции" + "Название схемы". Если условие не выполняется - отчет не будет сформирован | * Можно применить любой корректный запрос к БД;
* Может редактироваться пользователем; пользователем;\\
[Примеры отчетов|CarbonBilling:Примеры технических отчётов] |

{info}{*}Внимание:* при составлении SQL отчёта обязательно добавляйте последним полем *уникальный ключ* для этого отчёта. *Уникальный ключ* при этом может быть составным, например abonent_id:user_id c помощью операции конкатенации. Последнее поле никогда не будет выгружено в окончательной выгрузке и нужно только для того, чтобы в будущем формировать периодические выгрузки. Добавляйте *уникальный ключ* даже тогда, когда периодические выгрузки нужно выгружать всегда целиком или не нужно выгружать вообще, т.к. последнее поле всегда не будет попадать в выгрузку{info}
----
h3. Вкладка "Дополнительно"
!extened_settings_sorm_2.png|border=0,width=350!

!extened_settings_sorm_2.png|border=0,width=350!

# *Генератор названий* - \- Определяет, как именно будут названы файлы при выгрузке на ftp сервер. В генераторе названий доступны те же переменные, что и в формате даты. Переменные для формата даты в генераторе названий +необязательны+.
{warning} Примечание: В генераторе названий формат даты обязательно указывайте между символами | \| и | \| {warning}
Пример генератора названий: *abonents-periodic-\|%y%m%d_%H%M%S\|.csv*
При такой настройке в название файла будет попадать время формирования файла в указанном формате. Для даты _2021-07-28_ _00:01:02_ название файла будет _abonents-periodic-20210728_000102.csv_
# *Папка на FTP* - \- В этом поле необходимо указать путь до папки на FTP-сервере в которую необходимо выгружать отчёт. Если данной папки не существует на FTP-сервере - выгрузка провалится.
# *Период выгрузки* - \- Определяет интервал через который будет запускаться данный отчёт. Доступные периоды: _ежечасно_, _ежедневно_, _только вручную_.
# *Формат периодичных отчётов* - \- Определяет, в каком именно формате будут выгружаться периодичные отчёты, сформированные по указанному SQL шаблону.
#* *Всегда целиком* - \- Означает, что каждый периодический отчёт будет сформирован полностью по всем записям, которые попадут в SQL выборку
#* *Только изменения* - \- Означает, что в каждый периодический отчёт попадет только та запись, которая изменилась с предыдущей выгрузки.
# *Заголовок* - \- название столбцов в отчете. Составляется обязательно через точку с запятой. +ВАЖНО\!+ В каждом отчете есть служебное поле (KEY), оно необходимо для сравнения записей при выполнении периодических выгрузок, чтобы система могла различить актуальный отчет от предыдущего.
|| Пример заголовка для отчета "ABONENT_USER" ||
| ABONENT_ID;REGION_ID;USER_NUMBER;USER_NAME;RECORD_ACTION;INTERNAL_ID1;+KEY+ |
# *Промежуточное имя отчёта*. Если в этом поле указано какое - либо значение, тогда загрузка на FTP будет проходить сначала с именем из поле "Промежуточное имя файла", после чего скрипт переименует этот же файл в имя из поля "Генератор отчёта". Данное поле предназначено для тех случаев, когда скрипты на стороне СОРМ слишком быстро обрабатывают файлы и их нужно сначала загрузить и потом переименовать.
# *Специальный формат периодических отчетов* - \- опция добавляет в отчет дополнительные строки для подробного отображения изменений в биллинге по записям.
+ВАЖНО\!+ Для каждой схемы эта опция работает по-разному. Использовать только для стандартных отчётов биллинга, сформированных на основе стандартных схем, а также включена по умолчанию у некоторых встроенных отчетах.
|| Пример работы опции при формировании отчета по схеме "Специальные технологии" ||
| Для отчёта abonents будет сформировано 3 строки по каждому абоненту, если у него редактировали данные с момента предыдущей выгрузки. \\ \\
1. Неактуальная запись (old_string) с изменённым record action(30 поле), Record action установлен со значением 2 (означает удалить запись); \\
2. Неактуальная запись (old_string), но в поле actual_to(6 поле) будет указана текущая дата, момент времени до которого запись была актуальна;\\
3. Новая запись (new_string) в поле actual_from(5 поле) будет иметь текущую дату, с которой информация по абоненту актуальна. |

h3. Общая логика работы для периодической(регулярной) выгрузки

# Если это первая периодическая выгрузка и на биллинге нет данных о последней успешной выгрузке на FTP сервер - будут выгружены полностью все записи исходя из SQL запроса
# Если выгрузка на FTP прошла успешно - на биллинге будет сохранен выгруженный файл в директории */var/local/sorm/reports/abonents/actual/* где *abonents* - \- имя отчёта в веб интерфейсе.
{warning}Внимание: В этой папке всегда должен быть только один файл, либо не должно быть файлов вообще. Если вы сохраните в эту директорию любой другой файл - выгрузка работать не будет\!{warning}
В этом файле последним полем будет указан *уникальный ключ*
Пример записи из файла в папке actual:
"1340";"BILL0000053";"Фролов Г. К.";"1340:1387"
{code}
В данном случае "1340:1387" - это *уникальный ключ*. 1340 - id абонента, 1387 id учетной записи. Вся остальная часть до последнего разделителя это *строка*, которая относится к данному ключу. Именно *строка* будет попадать в конечную выгрузку без уникального ключа и последнего разделителя.
# Если происходит периодическая выгрузка и биллинг находит последний актуальный файл в папке с тем именем, которое указано у отчёта в качестве имени - начинается сравнение строк по ключам: биллинг смотрит текущий файл и последний актуальный и сравнивает строки с одинаковыми ключами друг с другом. Если в строках находятся изменения - текущая строка попадает в выгрузку. Если выгрузка на FTP проходит успешно - текущий актуальный файл заменяется.
{info} Внимание: Актуальный файл на биллинге меняется только для выгрузок на FTP и только в том случае, если выгрузка прошла успешно. При ручном скачивании в csv или при выводе в веб интерфейсе актуальный файл меняться на биллинге не будет\!{info}

h3. Как выбрать уникальный ключ для отчёта.

Для каждого отчёта уникальный ключ необходимо подбирать индивидуально, исходя из того, какие поля выводятся в отчёте. Основным критерием выбора ключа должно быть то, что во всей выборке он должен принадлежать только одной записи, т.е. будет обязательно *уникальным*.
Примеры:
# В отчёте abonents есть данные как об основных параметрах абонента(таблица abonents), так и о параметрах учетных записей(таблица users). Первым делом приходит на ум использовать в качестве уникального ключа просто id таблицы abonents. Однако это решение будет неверным, потому что у одного и того же абонента может быть несколько учетных записей и тогда в выборке будет несколько записей(строк), в которых ключ будет одинаковым. Это можно понять по связи модели users с abonents.
Точно так же будет неверным использовать только id из таблицы users, потому что может быть такая ситуация, в которой у абонента нет ни одной учетной записи и таких абонентов будет несколько и в итоге в выборке будет несколько разных записей(строк), в которых будет одинаковый пустой ключ.
В данном отчёте лучше всего подойдет составной ключ из этих двух таблиц, например *abonent_id:user_id*. Такой составной ключ можно добавить с помощью конкатенации и указать последним полем в отчёте следующую конструкцию:
a.id || ':' || u.id
{code}
Таким образом последнее поле в отчёте(уникальный ключ) будет составным и состоять из двух id разных таблиц, разделенных двоеточием, например *"1340:1387"*. Такая связка будет гарантировать, что у каждой записи(строки) будет уникальный ключ.

h2. Выгрузка данных

h2. Ручной запуск отчётов
Выгрузить на FTP. Выгружает файл на FTP сервер.
{info} Внимание: При успешной выгрузке файла на FTP сервер, на биллинге будет создан актуальный файл, с которым потом будет проходить сравнение в периодической выгрузке{info}
Выполнить в веб - интерфейсе. Показывает информацию в виде таблице в веб - интерфейсе биллинга

h2. Периодическая выгрузка отчетов

После проведения проверки отчетов специалистами СОРМ необходимо настроить выгрузку отчетов за определенные интервалы времени согласно требованиям.
Для этого необходимо изменить параметр *"Период выгрузки"* и нажать кнопку *"Сохранить"* - \- информация по этому отчету будет записана в службе cron и, в дальнейшем, отчет будет формироваться автоматически.

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

!sorm_report2.png!
!sorm_report3.png!


h2. Выгрузка pay_types (типы платежей)

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

# Добавляются типы платежей, обязательные для конкретного СОРМ
# Из таблицы БД FINANCE_OPERATIONS берутся уже существующие типы платежей по полю operator_name(SBERBANK_ACQ,Robokassa и т.д.), их id формируются автоматически.

h2. Особенности отдельных СОРМ

h3. Сигналтек

Для всех юридических лиц, нужно отдельно выгружать информацию об их конечных пользователях (abonent_type = 2). Такие записи выгружаются с тем же номером договора и идентификаторами. На данный момент возможна выгрузка только одного конечного пользователя. Чтобы в выгрузке abonents конечный пользователь шёл отдельной строкой, юридическому лицу необходимо добавить реквизит "В лице" (id реквизита - 29), где указать ФИО конечного пользователя. Адрес конечного абонента указывается в реквизите "Адрес" (id реквизита - 3).

h2. Отладка

2021-12-24 10:03:16,064 - worker - sorm_spec_tech - INFO - Выгрузка завершена
2021-12-24 10:03:16,447 - worker - sorm_functions - INFO - Не найден абонент с ключом 19898:19635 в старом файле. Добавляем в новый файл без изменений
2021-12-24 10:03:16,448 - worker - sorm_functions - INFO - Отчёт abonent_ident. У абонента 11860 с учетной записью 11880 изменилось поле IPV4
{code}