← На главную

При переходе на требования 54-ФЗ перед многими торговыми компаниями встает вопрос выбора кассового оборудования. Нередко внимание привлекают компактные моноблоки (смарт-терминалы «все в одном»), объединяющие в одном корпусе планшетный компьютер, кассовое ПО и принтер чеков с фискальным накопителем. Рассмотрим типовую архитектурную задачу: в компании внедрена конфигурация 1С:Управление торговлей 10.3, кассиры и менеджеры подключаются к центральному серверу через терминальные сессии (RDP), а при оформлении чека в документе заполняются специфические реквизиты (акции, кастомные условия, внутренние статусы). Выясним, почему классический смарт-терминал в такой конфигурации создает критические ограничения и какое решение является технологически правильным.

Архитектурная разница между смарт-терминалом и фискальным регистратором

Для понимания сути проблемы проанализируем различия двух подходов к автоматизации кассовой зоны:

1. Классический фискальный регистратор (ФР): представляет собой аппаратное устройство без собственной операционной системы пользовательского уровня. Устройство подключается напрямую к учетной системе (локально или по сети) и работает под ее полным контролем. Вся логика продаж, проверка остатков, скидки и интерфейс кассира находятся внутри 1С. По команде из учетной системы ФР лишь формирует фискальный чек и отправляет данные оператору фискальных данных (ОФД).
2. Смарт-терминал (моноблок): это автономное рабочее место на базе операционной системы Android со встроенной собственной кассовой программой. В стандартном режиме он проектируется как самостоятельная учетно-кассовая единица для малого бизнеса (формата «микробизнес» или «ларек»), где кассир взаимодействует исключительно с интерфейсом встроенного планшета.

Ограничения интеграции смарт-терминала с 1С:УТ 10.3

Разберем, с какими непреодолимыми сложностями сталкивается бизнес при попытке внедрить автономный смарт-терминал в корпоративную инфраструктуру 1С:

1. Асинхронный обмен через внешнее облако (режим «ККМ Offline»). В типовом сценарии смарт-терминалы не подключаются к 1С напрямую как внешнее устройство печати. Обмен происходит по схеме: 1С выгружает номенклатуру и цены в облачный сервис производителя, откуда терминал периодически забирает данные. После совершения продаж терминал выгружает итоговые чеки обратно в облако, а 1С регламентным заданием загружает отчет о розничных продажах. В такой схеме отсутствует работа в режиме реального времени: кассир на терминале не видит актуальных остатков других складов, а менеджеры в 1С не видят факт продажи до окончания сеанса обмена.
2. Невозможность работы с кастомными реквизитами 1С. Если кассир в 1С при продаже выставляет специализированные галочки, распределяет позиции по заказам или применяет сложные алгоритмы лояльности, перенести это на смарт-терминал невозможно. Кассовая программа Android оперирует только фиксированным набором типовых полей: товар, цена, базовая скидка, способ оплаты. Доработать интерфейс кассового приложения планшета под индивидуальные поля из 1С стандартными средствами конфигуратора 1С нельзя.
3. Зависимость от интернет-канала и доступности облачных серверов. При сбоях на стороне внешнего облачного сервиса или обрыве связи на торговой точке синхронизация полностью блокируется. При включенном платном приложении интеграции редактирование товаров и цен на самом терминале зачастую заблокировано из соображений целостности данных, что парализует операционную деятельность.
4. Платная экосистема приложений. Базовая прошивка терминалов ориентирована на автономный ввод. Возможность интеграции с 1С, выгрузка отчетов в сторонние форматы, драйверы для весов или сканеров, а также модуль работы с маркировкой («Честный ЗНАК») требуют регулярной абонентской платы за приложения из специализированного маркета, что существенно повышает совокупную стоимость владения (TCO).
5. Сложности поддержки платформы 1С на обычных формах. Конфигурация «Управление торговлей 10.3» использует платформу 1С:Предприятие на обычных формах. Взаимодействие с современными REST API облачных касс требует использования громоздких внешних обработок с поддержкой JSON и авторизации по токенам. В случае изменения протокола на стороне облака интеграция перестает работать до выпуска и ручной установки обновления.

Специфика работы в терминальном доступе (RDP)

Проанализируем сетевое окружение, описанное в задаче. Если рабочие места кассиров вынесены на сервер терминалов, использование локально подключенных Android-устройств превращается в постоянный источник сбоев из-за необходимости проброса портов через сессию RDP.

Большинство смарт-терминалов аппаратно не могут выступать в роли подчиненного сетевого устройства печати чеков (исключение составляют редкие специализированные модификации производителя, например, линейка Power, имеющая аппаратный переключатель в режим фискального регистратора). Обычные же терминалы линеек 5, 7 или 10 превратить в сетевой фискальный регистратор невозможно.

Оптимальное решение для поставленной задачи

Для инфраструктуры под управлением 1С:УТ 10.3 с работой через RDP эталонным и надежным решением является использование классического фискального регистратора (например, оборудования брендов АТОЛ или Штрих-М) с поддержкой сетевого интерфейса (Ethernet или Wi-Fi).

Разберем по шагам правильную организацию кассового узла:

1. Подключение по TCP/IP: фискальный регистратор подключается сетевым кабелем к локальному коммутатору торговой точки и получает статический локальный IP-адрес.
2. Настройка торгового оборудования в 1С: в конфигурации 1С:УТ 10.3 в справочнике ПодключаемоеОборудование создается элемент с типом «ККТ с передачей данных». В параметрах связи вместо виртуального COM-порта указывается сетевой протокол TCP/IP, IP-адрес кассы и порт (например, порт 5555 для драйверов АТОЛ).
3. Прямая печать из сессии RDP: при проведении документа ЧекККМ или РеализацияТоваровУслуг сервер 1С напрямую отправляет пакет фискализации на IP-адрес устройства по локальной сети или через корпоративный VPN-туннель. Это полностью исключает зависание виртуальных портов RDP и исключает любые промежуточные облачные сервисы.
4. Централизованная логика: все кастомные условия, галочки, маркетинговые акции и обработка кодов маркировки по формату ФФД 1.2 выполняются непосредственно кодом конфигурации 1С. Касса выступает исключительно надежным фискальным исполнителем без скрытых ежемесячных подписок.

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