← На главную
Рассмотрим распространенную и сложную задачу автоматизации розничной сети: объединение нескольких территориально распределенных магазинов в единую информационную базу 1С. Основная сложность при такой централизации заключается в работе с ЕГАИС, кассовым ПО (Frontol) и периферийным оборудованием (весами, фискальными регистраторами). Разберем, почему популярная идея «пробросить все смарт-карты на один терминальный сервер» технически некорректна, какие законодательные требования выдвигает регулятор и как правильно выстроить отказоустойчивую архитектуру.
Технические и законодательные ограничения терминального сервера (RDP)
Проанализируем базовую идею: установить несколько экземпляров УТМ на один терминальный сервер и пробрасывать ключевые носители (JaCarta, Рутокен ЭЦП) через RDP-сессии пользователей при подключении. На практике такая схема не работает по ряду критических причин:
- Работа службы в Session 0: Службы УТМ (
Transport, Transport-Updater) функционируют как системные службы Windows в изолированной нулевой сессии. Стандартный RDP-проброс смарт-карт подключает токен только в конкретную пользовательскую сессию, из-за чего служба УТМ попросту не видит носитель и криптопровайдер.
- Один экземпляр УТМ на ОС: Штатный дистрибутив УТМ жестко привязан к системным путям реестра и файловой структуры. Запустить несколько независимых служб УТМ на одной операционной системе без сложной контейнеризации невозможно.
- Запрет виртуализации: В технических требованиях к штатной эксплуатации УТМ прямо зафиксирован запрет на использование систем виртуализации и подключение нескольких аппаратных ключей к одному экземпляру.
- Лицензионные требования ФСРАР (РАР): Согласно законодательству, транспортный модуль с ключом электронной подписи должен физически располагаться по месту осуществления лицензируемой деятельности — то есть по адресу конкретного КПП обособленного подразделения. Контрольные органы сопоставляют IP-адреса и подсети отправки данных с фактическими местами торговли.
- Уязвимость кассовой зоны: При продаже крепкого алкоголя кассовое ПО (в частности Frontol) должно мгновенно обращаться к УТМ для генерации фискального чека с QR-кодом. Если канал связи между магазином и центральным офисом оборвется, касса не сможет подписать чек и продажи алкоголя полностью остановятся.
Оптимальная архитектура: локальный УТМ и распределенная работа с центром
Выясним причину, почему правильнее всего оставлять УТМ непосредственно на торговой точке. В УТМ заложен механизм автономной работы: при потере интернета модуль позволяет фиксировать розничные продажи до 72 часов в накопительном режиме. Следовательно, связка кассового терминала и УТМ должна быть локальной.
Рассмотрим надежные варианты построения единого информационного пространства:
Вариант 1. УТМ на магазине, объединение сетей через VPN и прямое подключение 1С
Разберем по шагам реализацию схемы, когда центральная база 1С напрямую обращается к магазинам по защищенным каналам:
- Установка оборудования в магазине: Аппаратный ключ устанавливается в кассовый компьютер или выделенный локальный ПК магазина. Там же инсталлируется УТМ. Frontol обращается к модулю локально (
127.0.0.1:8080), что исключает простои кассы при сбоях интернет-провайдера.
- Настройка сетевого доступа к УТМ: По умолчанию веб-сервер модуля слушает только локальный интерфейс. В файле конфигурации УТМ (
transport.properties) переопределяем параметр привязки адреса, указав host=0.0.0.0, чтобы служба принимала входящие сетевые пакеты из внутренней сети.
- Организация канала VPN: Между центральным сервером и магазинами настраивается единая защищенная сеть (IPSec, OpenVPN, WireGuard). Это решает проблему отсутствия статических публичных («белых») IP-адресов на точках.
- Настройка параметров ЕГАИС в 1С: В конфигурации (например, «1С:Розница» или «1С:Управление торговлей») в справочнике настроек обмена с ЕГАИС для каждого обособленного подразделения (КПП) указывается собственный
FSRAR_ID, а также индивидуальный IP-адрес магазина в VPN-сети и порт 8080.
- Маршрутизация регламентных заданий: Обратим внимание, что если обмен ТТН и актами в 1С выполняется регламентным заданием в фоне, то сетевой доступ к магазину через VPN должен быть настроен непосредственно с сервера «1С:Предприятие», а не с клиентских компьютеров операторов.
Вариант 2. Использование распределенной информационной базы (РИБ)
Посмотрим на классическое решение для ритейла — РИБ с разделением по магазинам:
- Каждый магазин имеет собственную локальную информационную базу 1С, установленную на месте.
- Оператор магазина локально принимает накладные через установленный здесь же УТМ и оформляет перемещения.
- Обмен данными между узлами РИБ и центральным сервером выполняется в фоновом режиме по расписанию (через веб-сервисы, FTP или общие сетевые папки).
- Главное преимущество: Полная автономность. Магазин сохраняет работоспособность даже при длительном отсутствии связи с главным офисом, а после восстановления канала данные безболезненно синхронизируются.
Вариант 3. Тонкий клиент на управляемых формах через веб-сервер
Если требуется отказаться от распределенных баз и поддерживать единую online-базу без терминальных RDP-лицензий, проанализируем публикацию базы 1С:
- Центральная база публикуется на веб-сервере (IIS или Apache).
- Сотрудники на торговых точках подключаются к базе через тонкий клиент 1С по протоколу HTTP/HTTPS или через внутренний VPN.
- Поскольку клиентское приложение выполняется на локальном ПК магазина, взаимодействие с локальным торговым оборудованием и драйверами происходит на клиенте. В то же время Frontol на кассе сохраняет прямую локальную связь с магазинной службой УТМ.
Настройка работы весов с печатью этикеток из центра
Рассмотрим подробнее вопрос взаимодействия центральной базы с торговыми весами (Штрих-М, Масса-К), расположенными в филиалах:
- Через прямое сетевое подключение: При наличии настроенной VPN-сети драйвер весов на сервере обращается напрямую к IP-адресу весов в локальной подсети магазина (при необходимости на локальном роутере настраивается проброс сетевых портов).
- Файловый обмен: В центральной 1С формируется регламентное задание, которое генерирует файл выгрузки номенклатуры (PLU) и отправляет его в магазин (через общую папку или скриптом). Локальная утилита загрузки весов опрашивает каталог и автоматически прогружает весы по расписанию, снижая зависимость от постоянного канала связи.