Как устранить ошибку 702 регистрации на сервере gRPC при интеграции ПИоТ и АТОЛ RPC

Системный администратор 1С v8.3 (Управляемые формы) 1С:Розница Торговля и дистрибуция
← На главную

При настройке разрешительного режима маркировки и интеграции кассового оборудования АТОЛ с модулем проверки (ПИоТ / ЕСМ) системные администраторы часто сталкиваются со сбоем инициализации кассы. Ошибка «702: Ошибка регистрации на сервере GRPC, Номер ЛУ=1, COM...» чаще всего проявляется в терминальной среде (RDP) при попытке проброса физического порта или использовании встроенной службы RPC-сервера драйвера ККТ. В результате 1С блокирует фискализацию чеков с маркированной продукцией, а перезапуск службы спасает лишь на короткое время либо не помогает вовсе.

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

Причины сбоя gRPC и специфика терминального сервера

Для понимания корня проблемы выясним, как взаимодействуют между собой компоненты драйвера ККТ и программный модуль проверки маркировки (ПИоТ):

  1. Изоляция сессий Windows (Session 0 Isolation): Служба ATOL: Fptr grpc service (исполняемый файл atol-grpc-service.exe) по умолчанию регистрируется как системная служба и выполняется в нулевой сессии. Физические COM-порты или порты, перенаправленные через RDP-клиент, существуют только в пользовательском пространстве конкретного сеанса. Служба из нулевой сессии теряет доступ к проброшенному порту пользователя, что порождает ошибку регистрации устройства.
  2. Конфликт сетевых сокетов: Сервис gRPC слушает локальный интерфейс на порту 4041, а служебный порт драйвера резервирует 4042. В многопользовательской среде первый запущенный сеанс занимает сокет на 127.0.0.1. Все последующие подключения к gRPC завершаются отказом, так как сервис не разделяет сетевые сокеты между сессиями.
  3. Блокировка службы UEM Agent: Модули проверки маркировки плотно связаны со службой uema.exe (UEM Agent). Зависание проверки лицензий или аварийное закрытие RDP-сессии оставляет порт заблокированным, блокируя инициализацию нового gRPC-канала.
  4. Несовместимость релизов ПИоТ и ДТО: Начиная с версий драйвера 10.10.8.24 наблюдались изменения в механизме взаимодействия через RPC, приводящие к потере связи драйвера с сервером gRPC.

Способ 1. Обновление компонентов до совместимых релизов

Рассмотрим первый путь решения — выравнивание версий программного обеспечения. В ранних релизах интеграции ПИоТ не мог корректно распознавать удаленный RPC-сервер АТОЛ с подключенной кассой.

  1. Удалим текущие версии драйвера ККТ и модуля ПИоТ с сервера.
  2. Установим связку компонентов: драйвер ККТ АТОЛ версии 10.10.9.20 (или проверенную ветку 10.10.8.21 / 10.10.7.21) и пакет ПИоТ версии 1.6.4.0 (сборка 375). В этих релизах локальный модуль проверки научился корректно маршрутизировать запросы драйвера к удаленному экземпляру RPC.
  3. Проверим разрядность драйвера ККТ: для корректного взаимодействия с компонентами 1С и модулем маркировки всегда используем 32-битную (x86) версию драйвера, даже если серверная операционная система 64-битная.
  4. Установим актуальные корневые сертификаты безопасности, требуемые для шифрования канала проверки маркировки согласно документации к ПИоТ.

Способ 2. Запуск службы gRPC в контексте пользовательской сессии

Если касса подключена к клиентскому ПК и пробрасывается в терминальную сессию по COM-порту, решим проблему изоляции сессий. Перенесем выполнение gRPC-сервера из системной службы в автозагрузку пользователя.

Разберем процесс по шагам:

  1. Откроем оснастку управления службами Windows (services.msc).
  2. Найдем службу с именем ATOL: Fptr grpc service, остановим ее и переведем тип запуска в состояние «Отключена».
  3. Перейдем в каталог установки драйвера: C:\Program Files (x86)\ATOL\Drivers10\KKT\atol-grpc-service\.
  4. Создадим командный сценарий (BAT или CMD) для запуска службы при старте пользовательского сеанса RDP:
    
    rem Завершаем зависшие процессы предыдущих сессий
    taskkill /F /IM atol-grpc-service.exe /T 2>nul
    rem Запускаем сервис в пользовательской среде
    start "" "C:\Program Files (x86)\ATOL\Drivers10\KKT\atol-grpc-service\atol-grpc-service.exe"
    
  5. Добавим запуск данного сценария в папку «Автозагрузка» пользователя или назначим его выполнение через групповую политику при входе в систему (Logon script). Теперь процесс выполняется с правами текущего сеанса и видит проброшенный COM-порт кассы.
  6. Настроим скрипт завершения сеанса (Logoff script) с командой taskkill /F /IM atol-grpc-service.exe, чтобы порты 4041 и 4042 не оставались заблокированными после выхода кассира.

Способ 3. Переход на прямую сетевую топологию (TCP/IP)

Опыт эксплуатации касс в связке с ПИоТ показывает, что проброс портов через RDP и использование RPC-сервера драйвера являются наименее надежными решениями в терминале. Наиболее отказоустойчивый вариант — полностью исключить RDP-проброс и перевести обмен данными на сетевые протоколы.

Разберем реализацию альтернативной схемы:

  1. Прямое сетевое подключение ККТ (Ethernet / Wi-Fi): Настроим кассовый аппарат на получение постоянного статического IP-адреса в локальной сети предприятия. В параметрах торгового оборудования в 1С выберем канал связи «TCP/IP (клиент)», указав IP-адрес кассы и порт (по умолчанию 5555). При такой схеме сервер терминалов связывается с кассой напрямую по сети без необходимости запуска промежуточного RPC-сервера на портах 4041/4042.
  2. Развертывание ПИоТ на рабочем месте кассира: Установим модуль проверки ПИоТ локально на компьютере, к которому подключена касса. В настройках подсистемы интеграции с ИС МП в 1С укажем IP-адрес рабочего места кассира и порт модуля проверки (по умолчанию 51401 или 51402). В таком случае ПИоТ взаимодействует с кассой локально без конфликтов виртуализации портов.
  3. Использование аппаратных USB-over-IP шлюзов: Если кассовый аппарат не имеет встроенного сетевого интерфейса Ethernet, применим сетевой USB-концентратор. Драйвер концентратора монтирует виртуальный COM-порт на уровне операционной системы сервера, благодаря чему порт отображается как локальное физическое устройство, доступное системным службам драйвера.

Применение правильной комбинации релизов или переход на прямое подключение ККТ по протоколу TCP/IP полностью устраняют ошибку 702 и обеспечивают бесперебойную проверку маркированных кодов на кассовой линии.

← На главную