← На главную

В розничной торговле скорость обслуживания покупателей имеет решающее значение. Ситуация, когда онлайн-касса (например, популярная модель Атол 25Ф) начинает пробивать чек по 10–15 секунд вместо одной, способна полностью парализовать работу кассовой зоны. Особенно часто с этой проблемой сталкиваются компании, использующие терминальный доступ (подключение по RDP) к информационной базе 1С:Управление торговлей или 1С:Розница.

Разберем классический сценарий. Касса физически подключена к локальному компьютеру кассира, а программа 1С запущена на удаленном сервере. На обеих машинах установлены драйверы торгового оборудования (ДТО). Первые несколько дней система работает безупречно, а затем внезапно начинается сильная задержка при пробитии чеков. В тесте драйвера на локальной машине ККТ определяется мгновенно, а через RDP-сессию — с огромным опозданием. Выясним причину такого поведения и рассмотрим детальные технические решения, которые позволят навсегда избавиться от этой проблемы.

Почему возникает задержка и почему касса сначала работала нормально?

Проанализируем техническую сторону взаимодействия 1С с кассовым аппаратом через протокол удаленного рабочего стола. Главная проблема кроется в архитектуре проброса последовательных (COM) портов по RDP.

1. Особенности протокола RDP. Стандартный механизм проброса портов передает данные небольшими порциями (посимвольно или мелкими блоками) и требует подтверждения доставки для каждого пакета. В процессе фискализации чека 1С совершает сотни последовательных микрозапросов к ККТ: проверяет статус кассы, передает построчно номенклатуру, цены, скидки, налоги, отправляет команду закрытия чека и ожидает ответа от фискального накопителя. Если касса подключена локально, эти транзакции занимают доли секунды. Через RDP каждый такой микрозапрос вынужден совершать сетевое путешествие туда и обратно.
2. Чувствительность к задержкам сети (Ping). Здесь кроется разгадка того, почему первые два дня все могло работать отлично. Небольшое увеличение пинга до сервера (например, с 10 мс до 40 мс) визуально незаметно для пользователя, работающего в интерфейсе 1С. Однако для ККТ, требующей сотни транзакций на один чек, это выливается в лавинообразный рост задержки. Достаточно провайдеру пустить трафик по резервному маршруту или временно загрузить канал, как печать чека замедляется до 10–20 секунд.
3. Влияние маркировки (Честный ЗНАК). Продажа маркированной продукции накладывает дополнительные требования. При проверке кодов маркировки ККТ выполняет онлайн-запросы. Передача этих данных поверх и без того перегруженного RDP-канала создает критические задержки.
4. Обновления операционной системы. Обновления Windows на сервере или клиенте могут изменять настройки таймаутов, буферизации COM-портов или алгоритмы шифрования RDP-трафика, что также мгновенно отражается на скорости обмена данными.

Решение 1. Переход на Тонкий клиент 1С (Рекомендуемый способ)

Рассмотрим наиболее правильный с точки зрения архитектуры 1С способ решения проблемы. Вместо трансляции тяжелого графического интерфейса всей операционной системы через RDP, мы можем использовать локальный запуск платформы в режиме тонкого клиента.

Посмотрим на алгоритм реализации этого метода по шагам:

1. Установим технологическую платформу 1С на локальный компьютер кассира. При установке выберем компонент Тонкий клиент.
2. Опубликуем базу данных 1С:Управление торговлей на веб-сервере (IIS или Apache) на стороне сервера. Это позволит подключаться к базе по протоколу HTTP или HTTPS.
3. Запустим локальный тонкий клиент и добавим информационную базу, указав веб-адрес публикации.
4. Установим драйвер торгового оборудования (ДТО) локально на компьютере кассира.
5. Подключим кассу через USB или COM к локальному ПК. Настройку торгового оборудования в 1С выполним непосредственно в сессии тонкого клиента.

Почему это решает проблему? При такой схеме весь тяжелый код выполняется на сервере, но само взаимодействие с торговым оборудованием происходит локально на клиенте. Тонкий клиент передает на сервер только готовые данные документа, а физическая печать чека инициируется локальным драйвером АТОЛ без какого-либо участия сетевых RDP-задержек. Чек пробивается мгновенно.

Решение 2. Прямое сетевое подключение кассы (Ethernet / Wi-Fi) через VPN

Если специфика работы требует сохранения RDP-сессий, проанализируем альтернативный вариант — отказ от проброса портов в пользу прямого сетевого подключения ККТ.

Современные кассы, включая модель Атол 25Ф, оснащены сетевыми интерфейсами Ethernet или модулями Wi-Fi. Мы можем подключить ККТ напрямую к локальной сети торговой точки.

Разберем шаги по настройке данной схемы:

1. Подключим кассу кабелем к роутеру на торговой точке. В настройках ККТ (через тест драйвера локально) зададим статический IP-адрес из диапазона локальной сети магазина.
2. Настроим защищенный VPN-канал (например, IPSec, OpenVPN или WireGuard) между роутером торговой точки и сервером, где развернута 1С. Это необходимо, чтобы сервер видел локальную сеть магазина.
3. В RDP-сессии запустим 1С, перейдем в настройки торгового оборудования и выберем тип подключения TCP/IP (или Сеть) вместо COM-порта.
4. Укажем IP-адрес кассы, назначенный на первом шаге, и порт подключения (по умолчанию для АТОЛ это 5555).

При такой схеме данные передаются напрямую по сетевому протоколу TCP/IP. Скорость передачи пакетов в разы выше, чем при эмуляции последовательного порта средствами Microsoft RDP Redirection, а стабильность соединения значительно возрастает.

Решение 3. Использование Веб-сервера АТОЛ или Сервера удаленного подключения

Начиная с 10-й версии драйверов (ДТО 10), разработчики АТОЛ добавили мощные встроенные инструменты для сетевой работы. Рассмотрим, как применить эти технологии для ускорения печати.

Первый вариант — использование Сервера удаленного подключения (RPC):

1. На локальном компьютере, к которому подключена касса по USB, запускаем службу ККТ и активируем функцию удаленного подключения в настройках драйвера.
2. Эта служба начинает ожидать входящие подключения на определенном порту.
3. На удаленном сервере в тесте драйвера АТОЛ (и соответственно в 1С) настраиваем подключение по IP-адресу локального компьютера кассира, указав соответствующий порт удаленного сервиса.

Второй вариант — Веб-сервер АТОЛ. Это современный подход, использующий JSON-запросы:

1. На локальном компьютере кассира запускается служба Web-Server ККТ. Она принимает команды по протоколу HTTP.
2. В 1С на сервере настраивается интеграция с ККТ через веб-сервер. Вместо прямого управления низкоуровневыми командами порта, 1С отправляет один структурированный JSON-пакет с данными чека.
3. Веб-сервер на локальном ПК принимает этот пакет, ставит его в очередь и самостоятельно выполняет печать. Для пользователя в 1С процесс завершается практически мгновенно, так как программа не ждет физического окончания печати каждой строки на бумаге.

Решение 4. Использование стороннего софта для проброса COM-портов по TCP/IP

Если предыдущие варианты не подходят (например, используются старые версии ДТО 9.x, как у автора темы, или нет технической возможности настроить VPN), мы можем заменить стандартный RDP-проброс портов сторонним программным обеспечением.

Существуют специализированные утилиты, которые упаковывают трафик COM-порта в чистые TCP-пакеты и передают их по сети с минимальными закладными расходами. К ним относятся программы класса VSPE (Virtual Serial Port Emulator), com0com в связке с com2tcp, или коммерческие решения вроде FabulaTech FT Serial Ports Sharing.

Рассмотрим логику работы такой связки:

1. На локальном ПК кассира устанавливается утилита-сервер. Она захватывает физический COM-порт (или виртуальный USB-COM) кассы и транслирует его в сеть на определенный TCP-порт (например, 4000).
2. На удаленном сервере 1С устанавливается утилита-клиент. Она подключается к IP-адресу локального ПК по порту 4000 и создает в диспетчере устройств виртуальный COM-порт (например, COM10).
3. В настройках торгового оборудования 1С на сервере мы указываем этот виртуальный COM10.

Поскольку передача осуществляется специализированным драйвером по оптимизированному TCP-каналу без посредничества тяжелых алгоритмов RDP, скорость отклика кассы увеличивается в несколько раз, возвращаясь к комфортным показателям в 1-2 секунды на чек.

Подводя итог, отметим: стандартный проброс портов в RDP — это устаревшая и крайне нестабильная технология для работы с торговым оборудованием. Для долгосрочной и бесперебойной работы торговой точки настоятельно рекомендуется перевести пользователей на Тонкий клиент 1С или использовать современные сетевые интерфейсы ККТ.