Интеграция с СОРМ3

Интеграция с системами оперативно-розыскных мероприятий (СОРМ) реализована в соответствии с Приказом Минкомсвязи России № 573 от 29.10.2018, устанавливающим требования к «техническим и программным средствам информационных систем, содержащих базы данных абонентов оператора связи».

Принцип работы

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

Выгрузка данных реализована как Celery-задача и передаётся в базы данных СОРМ-систем по протоколу FTP в формате CSV и его модификациях:

• Разделитель полей — точка с запятой (;).
• Текстовые значения — в кавычках.
• Кодировка — UTF-8 или Windows-1251 (в зависимости от требований СОРМ-системы).
• Расписание выгрузки — настраивается (обычно каждые 5-15 минут).

Выгружаемые данные включают:

• Персональные данные абонентов (ФИО, паспортные данные, адрес регистрации).
• Данные об услугах и договорах.
• IP-адреса и сессии подключения (логин, начало/конец сессии, NAT-трансляции).
• Данные о платежах и балансе.

Интегрированные решения

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

Ожидающие интеграции

СОРМ «Якорь» (компания НЕОС) — находится в процессе интеграции. Планируется поддержка стандартного протокола обмена данными. Для получения информации о статусе интеграции обращайтесь в техническую поддержку.

Настройка подключения

Перейдите в раздел Оборудование → Настройки СОРМ (/admin/equipment/sorm_list/) и нажмите «+ Добавить». Откроется модальное окно с формой создания новой конфигурации — без перехода на отдельную страницу.

Модальное окно «Добавить настройку СОРМ»

Форма разделена на 4 секции и содержит подсказки (серая иконка i рядом с подписью каждого поля) — наведите курсор для пояснения значения и формата.

Tooltip-подсказка (пример для поля «Хост»):

Секции и поля модалки

Отчёты и SQL

Каждая СОРМ-запись содержит список отчётов — это именованные SQL-запросы, результат которых выгружается в CSV и отправляется на FTP.

Для каждого отчёта задаются:

• Наименование — произвольное название отчёта
• Префикс файла — начало имени файла на FTP (например abonents → файл abonents_20260315_143000.csv)
• Расширение файла — по умолчанию csv
• SQL запрос — произвольный SELECT к базе данных биллинга. Первая строка результата станет заголовком CSV
• Периодичность — расписание автоматической выгрузки

Стандартные отчёты СОРМ-3

При нажатии кнопки «Первоначальная настройка отчётов» создаются 13 стандартных отчётов в формате, совместимом с Carbon 4:

Расписание автоматической выгрузки

Celery Beat проверяет расписание каждые 10 минут и автоматически запускает отчёты согласно настроенной периодичности:

Каждый отчёт выполняется как отдельная Celery-задача billing.tasks.sorm_export.export_sorm_report. При ошибке задача повторяется до 2 раз с интервалом 60 секунд.

Админка: выгрузка на сервера РКН

Раздел: Оборудование → Настройки СОРМ (URL /admin/equipment/sorm_list/).

Оператор связи обязан передавать в Роскомнадзор данные об абонентах, платежах, услугах. Биллинг автоматически формирует CSV-отчёты по схеме поставщика СОРМ-3 оборудования и загружает их на FTP-сервер РКН по расписанию.

Список конфигураций

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

Таблица показывает по каждой конфигурации:

• Vendor — поставщик СОРМ-оборудования: СигналТек, НОРСИ 2020, СпецТехПитон, МФИ Софт, Элком НТ, VAS Experts
• FTP — хост и путь выгрузки на стенде РКН (если не задан — предупреждение)
• Расписание — время автоматической выгрузки
• Отчётов — количество настроенных SormReport (по дефолту 14)
• Последняя выгрузка — дата/время + значок статуса (✓ успех, ⚠ частично, ✗ ошибка, ⏳ идёт) + сколько файлов из общего числа

Кнопки в строке: ⚙ открыть настройки, ▶ запустить выгрузку сейчас, 🗑 удалить конфигурацию.

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

Проверка готовности данных

Перед выгрузкой полезно проверить — все ли обязательные поля заполнены у активных абонентов. Кнопка Проверить готовность запускает анализ UserAttributes и показывает список пропусков.

Например, если у юр.лиц не заполнены ИНН, КПП, ОГРН, Директор — система покажет точное число абонентов с каждым пропуском и в каком отчёте СОРМ это поле используется. Выгрузка не блокируется, но РКН может вернуть файл с замечанием.

Бейдж результата (рядом с кнопкой):

• 🟢 Все данные готовы — пропусков нет
• 🟡 Пропусков: N — есть пропуски (≤100)
• 🔴 Проблем: N мета + M data — критические проблемы метаданных или >100 пропусков
• ⚪ Не проверялось — проверка ни разу не запускалась

Бейдж сохраняется между сессиями — рядом показывается timestamp последней проверки.

Основные настройки

Открывается при клике на имя конфигурации. Содержит пять под-вкладок: Основные · FTP · Уведомления · Отчёты · История.

Что задаётся:

Кнопки внизу:

• Сохранить — сохранить изменения формы
• ↻ Дефолты схемы vendor — переустановить SQL и схему всех 14 отчётов под выбранного поставщика. Текущие настройки отчётов будут перезаписаны — требуется подтверждение
• 📇 Создать реквизит «Тип документа» — добавить в UserAttributes стандартный набор типов документов (паспорт, ИНН, СНИЛС и т.д.) если их ещё нет в системе

В шапке справа — кнопка ▶ Выгрузить сейчас запускает ручную выгрузку всех отчётов на FTP (см. 22.7).

Подключение к FTP-серверу РКН

Параметры доступа предоставляет поставщик СОРМ-оборудования. Запросите у их техподдержки: хост, пользователь, пароль, путь.

• FTP хост — IP или DNS-имя сервера РКН
• Порт — обычно 21
• Пользователь / Пароль — для авторизации. Кнопка 👁 показывает пароль
• Путь выгрузки — каталог на сервере, обычно /sorm/. Корень сервера — /
• Активный режим FTP — большинство FTP работают в Passive (выкл). Active включают если сервер РКН не отвечает на data-port

Кнопка Проверить FTP запускает диагностику: открывает TCP-соединение, авторизуется, делает CWD по каждой части пути, листинг файлов. Результат показывает в модалке с этапами проверки и временем каждого шага в миллисекундах. При ошибке выводится тип исключения и сообщение FTP-сервера — можно скопировать диагностический JSON и отдать саппорту.

Уведомления в Telegram

После каждой выгрузки можно отправлять отчёт в Telegram-чат — удобно для оперативного контроля что СОРМ доходит до РКН.

• Отправлять отчёт после каждой выгрузки — главный переключатель
• Chat ID — числовой ID Telegram-чата. Для супергруппы начинается с -100. Узнать через @userinfobot
• Thread ID — необязательно. ID топика в супергруппе с включёнными темами

Кнопка Тест отправки отправляет тестовое сообщение в указанный чат — позволяет убедиться что бот добавлен и Chat ID/Thread ID верные.

Бот для отправки берётся из общих настроек: Настройки → Интеграции → Telegram. Прокси для api.telegram.org тоже наследуется оттуда.

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

Стандартный набор — 14 отчётов СОРМ-3: ABONENT, ABONENT_IDENT, ABONENT_SRV, ABONENT_USER, ABONENT_ADDR, PAYMENT, SUPPLEMENTARY_SERVICE, REGIONS, DOC_TYPE, PAY_TYPE и другие. У каждого свой SQL-запрос и префикс имени файла.

В каждой строке:

• Префикс файла — например ABONENT_USER
• Расширение — обычно .csv
• Описание — что выгружает отчёт
• Периодичность — выпадающий список: Вручную / Каждые 10 минут / Каждый час / Ежедневно / Ежемесячно. Меняется одним кликом, изменение сохраняется и пишется в аудит
• ▶ — запустить только этот отчёт сейчас (выгрузить на FTP)
• ⚙ — открыть полную страницу настроек отчёта (SQL-запрос, схема, дополнительные поля)

Кнопка Управление отчётами в правом верхнем углу — переход на список всех отчётов с возможностью добавить/удалить/восстановить.

Ручной запуск выгрузки

Кнопка ▶ Выгрузить сейчас в шапке detail-страницы запускает выгрузку всех отчётов конфигурации немедленно (минуя расписание).

Что происходит:

1. Создаётся запись в SormExportLog со статусом running
2. Запись добавляется в журнал аудита (кто запустил)
3. Celery-задача проходит по всем активным отчётам, выполняет SQL, формирует CSV, загружает на FTP
4. По мере прогресса обновляется files_ok, total_rows, total_bytes
5. В конце статус меняется на success / partial / failed
6. Если включены Telegram-уведомления — отправляется сообщение с итогами

UI после запуска переключает на вкладку История и поллит endpoint каждые 5 секунд пока есть активная (running) выгрузка.

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

История выгрузок

Журнал последних 50 запусков — для compliance-аудита и быстрой диагностики «что выгружали и доходили ли файлы до РКН».

Колонки:

Если в выгрузке были ошибки — под строкой раскрывается их текст (топ-20).

Кнопка ↻ в правом верхнем углу — обновить список вручную. Если в журнале есть выгрузка со статусом «Идёт» — список обновляется автоматически каждые 5 секунд.

Автоматическое расписание

Celery beat-задача run_scheduled_sorm_exports запускается каждые 10 минут и проверяет какие отчёты пора выгрузить:

• Каждые 10 минут — выгружается каждым тиком beat
• Каждый час — в первые 10 минут каждого часа
• Ежедневно — в 00:00 — 00:10 каждого дня
• Ежемесячно — 1-го числа в 00:00 — 00:10
• Вручную — игнорируется автоматикой, запускается только кнопкой ▶

Поле «Время выгрузки» на вкладке «Основные» влияет на удобство — обычно ставят утренние часы (например 09:00) чтобы при проблеме оператор увидел в начале рабочего дня.

Структуры данных

Таблицы sorm_readiness_check и sorm_export_log созданы миграцией 0099_sorm_readiness_export_log.

URL-эндпоинты

Команды управления

Из контейнера web (docker exec app-web-1 python manage.py ...):

• sorm_run_export <sorm_id> — запустить выгрузку всех отчётов одной конфигурации
• sorm_run_report <report_id> — запустить один отчёт по ID
• sorm_validate_meta — проверка метаданных UserAttributes без UI

Управление отчётами

Страница отчётов: /admin/equipment/sorm_list/1/reports/. Все операции выполняются через модальные окна без перехода на другие страницы.

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

Действия

• ▶ Выполнить — открывает модальное окно с выбором режима:
  • В браузер — выполняет SQL и отображает результат в таблице прямо в модале (для проверки данных)
  • FTP — формирует CSV и отправляет файл на FTP-сервер. Показывает имя файла, количество строк, статус
  • CSV — скачивает файл в браузер
• ✏ Редактировать — модальное окно с SQL-редактором, настройкой периодичности, префикса файла. Доступны функции: uf_ip2hex(), uf_mask2hex(), uf_date2sorm()
• 🗑 В архив — мягкое удаление с возможностью восстановления из блока «Архив»

СОРМ-метаданные UserAttributes

SQL отчётов СОРМ генерируется автоматически через сервис billing.services.sorm_sql.SormReportBuilder, который читает метаданные прямо из записей UserAttributes. Это позволяет переименовывать атрибуты в /admin/dictionary/UserAttributes/ без поломки выгрузки — отчёт всегда обращается к актуальным записям через ID, а не по захардкоженным именам.

Builder выбирает все UserAttributes где is_sorm=True, sorm_field_code != '' и тип отчёта присутствует в sorm_report_types, упорядочивает по order_no и собирает SELECT-подзапросы. Для атрибутов с sorm_alt_names используется WHERE NAME IN (...) — это покрывает обе графемы одновременно (например на одной БД хранятся записи и с кириллической «р/с», и с латинской «р/c»).

Управление метаданными в UI

Открыть атрибут в модалке /admin/dictionary/UserAttributes/ и включить чекбокс «Участвует в СОРМ-отчётах» — появится секция «СОРМ-метаданные» с 4 полями:

• Техническое имя поля — латинские буквы/цифры/_, первый символ — буква. Будет именем колонки в SQL и CSV-выгрузке.
• Альтернативные имена графем — для исторических дублей (например р/с;р/c где с кириллическое и c латинское).
• Типы СОРМ-отчётов — multi-checkbox: ABONENT / ABONENT_LEGAL / ABONENT_IDENT / ABONENT_USER / ABONENT_ADDR. В каких отчётах поле появляется как колонка.
• Обязательное поле — pre-flight валидация заблокирует выгрузку (выдаст предупреждение) при отсутствии значения у активных абонентов.

В таблице атрибутов цветовая индикация:

• Красный щит + tooltip с field_code — атрибут полноценно настроен для СОРМ.
• Жёлтый щит — флаг is_sorm=True, но sorm_field_code пустой. Builder его пропустит — нужно дозаполнить метаданные.
• Серая точка — обычный (не СОРМ) атрибут.

Текущая карта метаданных

Миграции 0097_user_attributes_sorm_meta и 0098_sorm_meta_extra_legacy заполняют метаданные для 23 атрибутов из коробки:

Pre-flight валидация перед выгрузкой

На странице /admin/equipment/sorm_list/ добавлена кнопка «Проверить готовность». Она вызывает endpoint GET /admin/equipment/sorm_list/validate/ и показывает в модалке две группы проблем:

Проблемы метаданных (meta_issues)

• missing_field_code — атрибут с is_sorm=True, но sorm_field_code пустой. Builder его пропустит, данные потеряются в выгрузке.
• invalid_field_code — field_code не соответствует регэкспу ^[a-z][a-z0-9_]*$. Чаще всего — пробелы, кириллица, тире.
• duplicate_field_code — два разных атрибута имеют один и тот же field_code в одном и том же отчёте. Builder выберет один через LIMIT 1 непредсказуемо.

Пропуски обязательных полей (data_issues)

Для каждого sorm_required=True атрибута проверяется сколько активных абонентов без заполненного значения. Юр-поля (ABONENT_LEGAL) проверяются только у юр.лиц (company=True); физ-поля (passport_series_number, birth_date) — только у физических лиц.

Пример вывода на проде testbill:

Бейдж готовности на странице

В верхней панели страницы /admin/equipment/sorm_list/ появился сводный бейдж готовности — показывает результат последней проверки и время:

• Все данные готовы — нет ни meta_issues, ни data_issues.
• Пропусков: N — есть data_issues (значения), но метаданные в порядке.
• Проблем: M meta + N data — есть проблемы метаданных, требует исправления до выгрузки.

Pre-flight в Celery-задаче выгрузки

Pre-flight также интегрирован в billing.tasks.sorm_export.run_report_export: перед запуском выгрузки в логах появляется warning:

EXPORT pre-flight: report=33 meta-issues=0
EXPORT pre-flight: report=33 missing-values=1043 in 4 fields

Сообщение в результате задачи также обогащается строкой pre-flight: пропуски в 4 полях (1043 абонентов) — оператор увидит её в UI запуска отчёта.

Дубликаты атрибутов и команда merge

На некоторых базах (миграция из EBS / Carbon 4) могут быть два атрибута с одинаковым именем — например «Директор» с id=10 и id=-219000. Без дедупликации builder выбирает значение через LIMIT 1 непредсказуемо — для одного абонента может выгрузиться значение из дубля, для другого — из канонической записи.

Команда manage.py merge_sorm_attribute_dups группирует атрибуты по sorm_field_code, выбирает каноническую запись (наименьший положительный pk) и переносит все AttributeValues с дублей через UPDATE attribute_id=...:

# Dry-run — только показать что будет сделано:
python manage.py merge_sorm_attribute_dups

# Применить (ОБЯЗАТЕЛЬНО pg_dump перед!):
python manage.py merge_sorm_attribute_dups --apply

# Только одна группа:
python manage.py merge_sorm_attribute_dups --field-code director --apply

# Группировка по name (для legacy без field_code):
python manage.py merge_sorm_attribute_dups --by-name --apply

Пример вывода (testbill):

Найдено 1 групп дубликатов:

  Группа «director» (2 записей):
    id= -219000  name='Директор'  values=97
    id=      10  name='Директор'  values=96  ←canonical
    → перенесено 97 AttributeValues, удалено 1 дублей

Готово: удалено 1 дубликатов, перенесено 97 значений на canonical-записи.

REST API проверки готовности

Endpoint GET /admin/equipment/sorm_list/validate/ возвращает JSON со структурой:

{
  "ok": true,
  "has_problems": true,
  "meta_issues": [
    {
      "kind": "missing_field_code",
      "attribute_id": 13,
      "attribute_name": "Паспорт №",
      "message": "СОРМ-атрибут без sorm_field_code"
    }
  ],
  "data_issues": [
    {
      "report_type": "ABONENT_LEGAL",
      "field_code": "inn",
      "attribute_name": "ИНН",
      "attribute_id": 4,
      "missing": 241
    }
  ]
}

Аутентификация: стандартная сессионная (Django @login_required). Доступен любому залогиненному пользователю; выдаёт информацию которая не зависит от прав абонент-папок.

Это удобный endpoint для интеграций — например, мониторинг (Zabbix / Grafana) может опрашивать его через cron и алёртить когда has_problems == true или когда data_issues содержит обязательные поля с большим числом пропусков.

Схемы настройки

• Стандартная схема Настройка передачи данных по стандартной (типовой) схеме. Используется для сертифицированных СОРМ-систем с предопределённым форматом обмена. Включает настройку FTP-соединения, расписание выгрузки, выбор набора данных и формат CSV-файлов. Подходит для большинства интеграций.
• Пользовательская схема Создание индивидуальных схем передачи данных для нестандартных СОРМ-систем. Позволяет настроить произвольный формат выгрузки: выбор полей, порядок столбцов, кодировку, разделители, формат дат. Используется при интеграции с СОРМ-системами, не поддерживающими стандартный формат.