ТС ПИоТ как отдельный центральный узел, к которому подключаются разные кассы: эксперимент, диагностика и подводные камни

Важно про лицензии
Условия лицензирования ТС ПИоТ зависят от конкретного вендора. Во многих случаях лицензия привязывается к ККТ или кассовому узлу. Перед внедрением рекомендуется ознакомиться с условиями используемого решения.
Данная статья описывает техническую возможность централизации обмена, но не призывает нарушать лицензионные соглашения. 
Автор не несёт ответственности за решения, принятые на основе этой публикации.

Вместо введения

1 июля 2026 года ТС ПИоТ становится обязательной частью контура маркировки на кассе. Если у вас одна касса - ничего особенного не произошло. Поставили, настроили, работает. Но если у вас сеть магазинов, быстро появляется другой вопрос: сколько это всё будет стоить. Одна лицензия ТС ПИоТ стоит 5000 рублей в год. Если у вас 20 магазинов или кассовых узлов - это уже 100 000 рублей в год. В какой-то момент я поймал себя на мысли: я собираюсь размножить один и тот же сервис двадцать раз и платить за это двадцать лицензий. И я задал себе простой вопрос: обязательно ли ставить отдельный ТС ПИоТ в каждый магазин, если все они работают в рамках одного юрлица?

Я решил провести не большой эксперимент.

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

С чем я столкнулся

Сначала всё выглядело просто. Есть 1С. Есть ТС ПИоТ. Указываем адрес, порт и работаем, но довольно быстро выяснилось, что удалённое подключение не всегда работает так, как ожидаешь.

Если обращаться к ТС ПИоТ не локально, а по сети, можно получить:

То есть локально сервис работает нормально, а удалённые обращения ему явно не нравятся.

Тогда я решил зайти с другой стороны.

Что я сделал

Я написал и поставил промежуточный прокси сервер на тот же компьютер, где установлен ТС ПИоТ.

Получилась такая схема:

Прокси принимает запрос от удалённого магазина/кассы, передаёт его локальному ТС ПИоТ и возвращает ответ обратно.

Для 1С это выглядит как обращение к ТС ПИоТ.

Для ТС ПИоТ это выглядит как локальный HTTP-вызов с того же компьютера.

Никакой своей логики проверки там нет. Прокси не принимает решения, не меняет ответы и не вмешивается в работу маркировки.

Он просто передаёт запросы и ответы.

Вот пример, comp066 - удаленный компьютер, на котором работает ТС ПИоТ и прокси сервер на порту 8787:

ВАЖНО: Тип протокола должен быть HTTP

Для эксперимента использовался открытый HTTP-контур. В промышленной эксплуатации желательно ограничивать доступ firewall/VPN и не публиковать сервис напрямую в интернет.

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

Для работы схемы в типовых конфигурациях может потребоваться отключение проверки соответствия ФН на этапе сохранения настроек ПИоТ. Перед использованием рекомендуется оценить влияние такого изменения на сопровождение и лицензионную политику используемого решения.

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

Что оно делает:

• отключает только проверку совпадения ФН при сохранении настроек подключения к ТС ПИоТ.

Что оно не делает:

• не меняет логику маркировки;
• не отключает контроль ИНН владельца ККТ;
• не вмешивается в обмен с Честным Знаком.

Установка расширения обычная, после этого необходимо перезапустить 1С.

Код расширения, для модуля формы заимствованного объекта справочника ТСПИоТ:

&НаКлиенте
&Вместо("ПроверитьОтличияНастроекТСПИоТ")
Функция FNFIX_ПроверитьОтличияНастроекТСПИоТ()
	СтруктураВозврата = Новый Структура();
	СтруктураВозврата.Вставить("ЕстьОтличияНомераФН", Ложь);
	СтруктураВозврата.Вставить("ЕстьОтличияИНН", ИННПоДаннымТСПИоТ <> ИННОрганизации И ЗначениеЗаполнено(ИННОрганизации));
	Возврат СтруктураВозврата;
КонецФункции

Как это работает с точки зрения разрешительного режима

Это был первый вопрос, который мне задали коллеги.

Что будет, если касса находится в одном магазине, а ТС ПИоТ физически стоит в другом?

Я проверял это в рабочем контуре.

Логика получилась такой:

1. Касса отправляет код маркировки на проверку через ТС ПИоТ.
2. ТС ПИоТ получает результат проверки, включая разрешение и метку времени.
3. После этого касса печатает чек.

В моих тестах я не увидел жёсткой привязки разрешения к конкретному ФН, через который уходил запрос.

Но специально подчеркну:

1. Я не хочу делать вывод "так будет работать всегда".
2. Версии 1С разные, версии ТС ПИоТ разные, кассовое ПО тоже разное.

Поэтому правильнее сказать так:

В моём контуре схема работала нормально, но перед использованием у себя рекомендую проверить это отдельно.

Вот реальный пример проверки кода маркировки в удаленном магазине, через прокси сервер, запущенный на компьютере comp066 в офисе:
 

Быстрый старт

В архиве лежит:

esp-proxy-win-x64.exe
esp-proxy-win-x86.exe
config.yaml
FNFIX.cfe
ESP_PROXY_Руководство.html

Минимальный конфиг

Вот базовый вариант:

server:
  host: "0.0.0.0"
  port: 8787
  workers: 1

upstream:
  base_url: "https://127.0.0.1:51401"
  timeout_sec: 60
  verify_tls: false

logging:
  level: "INFO"
  log_dir: "./logs"

Главное здесь:

host: "0.0.0.0" — принимаем запросы со всех интерфейсов

port: 8787 — сюда будет обращаться 1С

base_url — локальный адрес ТС ПИоТ

verify_tls: false — отключаем проверку локального сертификата

Полный конфиг есть в архиве, лучше использовать его

Запуск

Проверка из консоли:

.\esp-proxy-win-x64.exe run --config .\config.yaml

Установка как службы Windows:

.\esp-proxy-win-x64.exe install-service --config .\config.yaml

.\esp-proxy-win-x64.exe start-service

Остановка:

.\esp-proxy-win-x64.exe stop-service

Удаление:

.\esp-proxy-win-x64.exe remove-service

Проверка

Проверить работу прокси можно так:

curl http://localhost:8787/health

Нормальный ответ:

{"status":"ok","compatibility_mode":"pass_through","upstream_status":"ok"}

Типичные проблемы

Что я увидел при диагностике

Интересная вещь.

Прокси может работать идеально:

• запрос получил;
• запрос передал;
• ответ вернул;
• HTTP 200.

А проверка всё равно не проходит.

Причина обычно не в прокси.

Проблема чаще находится внутри результата проверки:

• статус марки;
• офлайн-контур;
• ошибки Честного Знака;
• состояние КМ.

Для диагностики можно включить в конфиге:

enable_payload_logging: true

Очень быстро становится понятно, где проблема: транспорт или бизнес-логика.

Риски

Теперь самое важное.

Централизация - это не только экономия, это ещё и единая точка отказа.

Что может случиться:

• выключился компьютер, где стоит ТС ПИоТ;
• пропал интернет;
• остановилась служба;
• упал прокси;
• проблемы между магазинами и центральным узлом;
• пиковая нагрузка.

Если ТС ПИоТ стоит отдельно в каждом магазине, проблема локализуется. Если он один - проблема становится общей. Это нужно учитывать заранее.

Когда я бы так делать не стал

• если магазины сильно распределены;
• если плохая связь;
• если простой кассы обходится дорого;
• если некому администрировать систему.

Почему бесплатно

ESP_PROXY получился небольшим и достаточно простым инструментом. Я не хотел делать из него отдельный коммерческий продукт.

Готовые сборки и инструкция - бесплатные.

Архив можно использовать как основу для собственного эксперимента или адаптации под свой контур.

Исходники проекта выложил тоже бесплатно. Скачивайте, смотрите, дорабатывайте под себя.

Итог

Я хотел проверить одну простую мысль: обязательно ли размножать одинаковый сервис на каждый магазин.

Но решение надо оценивать не только по деньгам. Стоимость простоя иногда оказывается выше стоимости лицензий. 
 

ВАЖНО:
Автор не призывает экономить на лицензиях любой ценой. Задача публикации - показать, что технически схема работоспособна. Юридическая же сторона остаётся за рамками этой статьи и лежит в зоне ответственности тех, кто внедряет или использует это решение.

Даже если технически один экземпляр ТС ПИоТ может обслуживать несколько кассовых узлов, это не означает, что такой режим разрешён условиями лицензии конкретного вендора. Во многих случаях лицензирование может считаться не по количеству установленных экземпляров, а по количеству ККТ или кассовых рабочих мест.

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

Интересно, как эту задачу решают или собираются решать коллеги?

Другие мои готовые решения для 1С (маркировка, токены, ТСД и т.д.):

Маркировка в "древней" УТ 10.3 (10.3.6.8) и полноценный ТСД (Online) или как обойтись без перехода на УТ 11.5

Как подключить маркировку в древней УТ 10.3 без перехода на УТ 11.5 - все необходимые объекты, модули и доработки

Автоматическое обновление токенов Честного Знака в 1С

Автоматическое обновление токенов Честного Знака в 1С - готовое решение для УТ, КА, ERP, УНФ, Розницы и Бухгалтерии, которое избавляет от ручных обновлений и остановки процессов.

Дубликатор кодов маркировки (КИЗ) DataMatrix: Расширение 1С с проверкой в Честном Знаке (копирует ЛЮБЫЕ КИЗы!)

Автоматическое обновление токенов Честного Знака в 1С - готовое решение для УТ, КА, ERP, УНФ, Розницы и Бухгалтерии, которое избавляет от ручных обновлений и остановки процессов.

Маркировка остатков товаров на складе: Как сделать все быстро и без ошибок (мой практический опыт)

Маркировка остатков 10 000+ товаров без ошибок — готовое решение, которое исключает человеческий фактор, автоматизирует процесс и работает напрямую с 1С. Пошаговый опыт и готовое расширение внутри.

Маркировка остатков в распределенной рознице: Как промаркировать более 100 тыс. товаров в нескольких десятках магазинов без хаоса и ошибок

Маркировка остатков 100 000+ товаров в рознице без хаоса и ошибок — клиент-серверное решение, где сканируешь ШК в магазине и сразу получаешь КМ на принтере, независимо от кассового ПО. Практический опыт, регламент и готовый комплект кода внутри.