Модули со стороны: как чужой код попадает в ваш биллинг

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

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

Модуль, виджет и вендор-пак — разные вещи

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

Разделение не формальное. Чем меньше сущность вмешивается в ядро, тем дешевле её проверить и тем меньше шансов, что обновление что-то сломает.

Путь расширения от автора до вашей установки

flowchart LR
  A[Автор<br/>заявка и кабинет] --> B[Пакет: код,<br/>манифест, версия]
  B --> C{Автоматический<br/>разбор}
  C --> D{Проверка<br/>человеком}
  D -->|вернуть| B
  D -->|опубликовать| E[Каталог]
  E --> F[Ваша установка:<br/>видно то, что в тарифе]
  F --> G[Обновление<br/>по вашему решению]

Ключевых мест два, и оба про то, кто отвечает за результат.

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

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

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

Что вы видите со своей стороны

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

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

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

Если нужного нет

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

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

Список того, что уже есть, — на странице модулей. Как модуль попадает в установку технически — в документации.

Как это работает в СмИТ Биллинге

Каталог расширений — это не «магазин, куда сходить», а страница внутри системы. На ней видно, что включено, какой версии и по какому тарифу лицензии доступно.

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

Схемы по теме все схемы →

Архитектура Runtime-архитектура Процесс Безопасный деплой Архитектура Очереди и фоновые задачи