Работа с онлайн-кассами АТОЛ в терминальной среде RDP часто превращается в головную боль для системных администраторов и пользователей. Типичная ситуация: в главном офисе, где сервер расположен локально, чеки печатаются мгновенно, а в удаленных филиалах процесс занимает от 30 секунд до 10 минут. При этом во время печати сеанс 1С может «зависать», блокируя работу остальных пользователей. Разберем подробно, почему это происходит и как настроить систему для быстрой и стабильной печати.
Проанализируем физику процесса. Основная проблема кроется в особенностях протокола управления ККМ и механизме RDP Passthrough (проброс портов). Драйверы АТОЛ (особенно старых версий 8 и 9) общаются с кассой по принципу «вопрос — короткий ответ (подтверждение)». Для печати одной строки чека драйвер отправляет десятки микро-пакетов. Если пинг до сервера составляет 50 мс, то на каждый пакет тратится время на путь туда и обратно. Суммарно при печати среднего чека количество таких итераций может достигать нескольких сотен, что и превращает задержку в минуты ожидания.
Рассмотрим по шагам основные способы решения этой проблемы — от простых настроек до изменения архитектуры подключения.
Это самый эффективный метод, позволяющий драйверу общаться с кассой напрямую по сетевому протоколу, минуя медленный механизм проброса портов RDP. Для этого необходимо, чтобы сервер 1С «видел» IP-адрес компьютера, к которому физически подключена касса.
Вариант А: Использование штатной службы FDSVC (для ДТО 8 и 9)
На локальном компьютере, к которому подключена касса, необходимо запустить службу FDSVC (драйвер ККМ АТОЛ позволяет это сделать в настройках). Эта служба делает кассу доступной в сети по определенному порту (обычно 6220).
Вариант Б: Использование утилиты com2tcp
Если штатные средства не справляются, воспользуемся проверенным методом туннелирования порта. Разберем пример настройки:
com2tcp на локальный компьютер с кассой.
com2tcp \\.\COM3 10500
Где COM3 — это порт, на котором сидит АТОЛ, а 10500 — произвольный TCP-порт, который начнет «слушать» входящие команды.
Проанализируем ситуацию с современным ПО. В 10-й версии драйвера (ДТО 10) архитектура была полностью пересмотрена. Теперь вместо множества мелких запросов можно отправлять JSON-задания. Драйвер формирует один большой пакет с данными чека, отправляет его на ККТ, и касса сама занимается его расшифровкой и печатью. Это полностью нивелирует задержки сети.
Для реализации в 1С:Комплексная автоматизация 1.1 или УТ 10.3 (обычные формы) потребуется:
Выясним причину, почему при пробитии чека у одного пользователя «подвисают» остальные. В типовых конфигурациях на обычных формах часто используется механизм «подключения» оборудования при открытии формы документа. Если связь с удаленной кассой плохая, 1С блокирует поток выполнения, ожидая ответа от порта.
Рассмотрим пример доработки кода в обработке обслуживания. Нам нужно перенести инициализацию связи с оборудованием непосредственно в момент нажатия кнопки «Пробить чек».
В модуле обработки найдите место, где происходит подключение. Вместо общего подключения при открытии, используйте конструкцию:
// Пример логики отложенного подключения
Функция НапечататьЧек(ОбъектДрайвера, ПараметрыЧека)
// Подключаемся только перед печатью
Результат = ОбъектДрайвера.Подключить();
Если Не Результат Тогда
Сообщить("Ошибка подключения к кассе!");
Возврат Ложь;
КонецЕсли;
// Выполняем печать чека
ОбъектДрайвера.СформироватьЧек(ПараметрыЧека);
// Сразу отключаемся, чтобы освободить ресурсы и не держать зависший порт
ОбъектДрайвера.Отключить();
КонецФункции
Также проверьте, чтобы в системе не вызывалась функция ПеречислитьУстройства() без необходимости, так как она заставляет сервер опрашивать все проброшенные порты всех пользователей, что вызывает массовые «фризы».
Иногда причина тормозов кроется в банальном переполнении файлов журналов. Драйвер АТОЛ пишет каждое действие в файл atol.log. При работе через RDP, если файл разрастается до сотен мегабайт, запись в него на дисковую подсистему сервера может вызывать задержки.
%AppData%\Roaming\Atol или C:\ProgramData\Atol).Проанализируем влияние доменной структуры. Если сервер и удаленные ПК находятся в разных доменах или разных рабочих группах, Windows может тратить значительное время на проверку прав при каждом обращении к ресурсу проброшенного порта. Выяснилось, что введение всех машин в единый домен или настройка идентичных учетных записей с одинаковыми паролями может сократить время «отклика» драйвера.
Также обратите внимание на настройки MTU в вашем VPN-канале. Если пакеты фрагментируются, протокол АТОЛ может считать связь разорванной и уходить в бесконечный цикл переповторов. Оптимальное значение MTU для стабильной работы касс через VPN — 1300-1400.
Существует экзотический, но рабочий метод для старых конфигураций — использование Multi File Port Monitor. Суть метода заключается в том, что касса на локальном ПК настраивается как текстовый Windows-принтер. RDP пробрасывает принтеры гораздо быстрее и стабильнее, чем COM-порты. 1С печатает текстовый файл на этот принтер, а специальная утилита-монитор подхватывает его и отправляет в COM-порт кассы. Главный минус — отсутствие обратной связи (вы не узнаете из 1С, закончилась ли бумага), но скорость печати становится мгновенной.
Подведем итог: для исправления ситуации в первую очередь попробуйте уйти от проброса портов в пользу TCP/IP (через com2tcp или FDSVC). Это решит 90% проблем с производительностью в терминальных сессиях.