← На главную

При автоматизации складского учета и внедрении обязательной маркировки («Честный Знак», ЕГАИС) технические специалисты часто сталкиваются со следующей проблемой: терминал сбора данных (ТСД), например Honeywell ScanPal EDA50K, отлично сканирует сложные двумерные коды DataMatrix локально (в блокнот на устройстве), но при попытке сканирования внутри сессии удаленного рабочего стола (RDP) часть символов бесследно исчезает. В результате учетная система (например, 1С) не может распознать код маркировки, выдает ошибку или некорректно разбирает структуру штрихкода.

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

Почему RDP «проглатывает» символы штрихкода?

Для того чтобы найти верное решение, сначала выясним техническую причину происходящего. По умолчанию сканирующий модуль ТСД работает в режиме эмуляции клавиатуры (этот режим часто называется Keyboard Wedge). Когда вы нажимаете кнопку сканирования, ТСД считывает штрихкод и мгновенно «впечатывает» его в активное текстовое поле операционной системы Android.

В этот момент в процесс вмешивается RDP-клиент. Передача нажатий клавиш через удаленный рабочий стол имеет свои ограничения:

1. Высокая скорость передачи данных: Сканер ТСД «выплевывает» весь штрихкод (который может содержать более 80 символов) практически одновременно — как единый массив текста. Сетевой протокол RDP не рассчитан на такую скорость эмуляции клавиатуры и просто не успевает обработать и передать серверу столь плотный поток сетевых пакетов. В результате часть символов теряется по дороге.
2. Проблема со служебными символами: Стандартный код GS1 DataMatrix содержит скрытый управляющий символ разделения групп данных — GS (Group Separator, ASCII-код 29). На физической клавиатуре компьютера такой клавиши не существует. Когда RDP-клиент на Android встречает этот символ, он не знает, как его интерпретировать, и просто отбрасывает его. Без символа GS 1С не может понять, где заканчивается серийный номер и начинается так называемый «криптохвост» (код проверки).
3. Регистр символов: Передача заглавных и строчных букв требует синхронизации виртуального нажатия клавиши Shift. Из-за сетевых задержек RDP-клиент часто путает регистр букв штрихкода.

Рассмотрим по шагам, как можно решить эти проблемы программными и аппаратными методами.

Решение 1. Тонкая настройка метода передачи данных (Wedge Method) на ТСД Honeywell

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

Разберем алгоритм настройки для ТСД Honeywell:

1. Откройте на ТСД системное приложение Settings (Настройки).
2. Перейдите в раздел Honeywell Settings, затем выберите пункт Scanning.
3. Откройте параметры встроенного сканера: Internal Scanner -> Default profile.
4. Перейдите в меню Data Processing Settings (Настройки обработки данных).
5. Найдите параметр Wedge Method. По умолчанию там может быть установлено значение Standard или Normal. Измените его на Keyboard. Это переключит логику работы устройства на посимвольную эмуляцию клавиатурного ввода.
6. Важный нюанс: В этом же меню обратите внимание на параметр Wedge as keys (обычно там прописаны значения 9,10,13, соответствующие клавишам Tab и Enter). Обязательно полностью очистите это поле (сделайте его пустым). Если этого не сделать, данные управляющие символы будут вырезаться при передаче в режиме клавиатуры.

Решение 2. Настройка задержки между символами (Inter-character delay)

Даже при переключении в режим Keyboard скорость эмуляции может оставаться слишком высокой для вашего интернет-соединения с RDP-сервером. Чтобы сервер успевал обрабатывать каждую букву штрихкода, необходимо принудительно замедлить передачу.

Для этого в настройках профиля сканирования ТСД (в том же меню Data Processing Settings или через утилиту ScanWedge) найдите параметр Inter-character delay (Задержка между символами).

Установите значение задержки экспериментальным путем:

• Начните со значения 15–20 миллисекунд.
• Если символы все еще теряются, увеличьте задержку до 30–50 миллисекунд.
• Примечание: При значении 50 мс визуальное появление штрихкода на экране удаленного рабочего стола будет происходить с небольшой задержкой (эффект «бегущей строки»), но это гарантирует 100% стабильность и полноту передаваемых данных.

Решение 3. Обработка управляющего символа GS (ASCII 29)

Как мы уже выяснили, символ GS теряется при передаче через RDP, так как не имеет клавиатурного аналога. Чтобы обойти это ограничение, мы можем настроить ТСД таким образом, чтобы он автоматически заменял невидимый символ GS на любой другой печатный символ перед отправкой данных в RDP-клиент. Также для восстановления пропущенных разделителей на стороне конфигурации можно использовать расширение для восстановления символов GS в считанных кодах маркировки.

Рекомендуем использовать в качестве подмены символ решетки #, вертикальной черты | или тильды ~.

Для настройки замены выполните следующие действия:

1. В настройках профиля сканирования Honeywell перейдите в раздел Data Editing (Редактирование данных).
2. Настройте замену символа (в зависимости от версии прошивки ТСД это делается либо через регулярные выражения в Decode Filter Script, либо через встроенную таблицу замены символов Symbology-Specific). Нам нужно указать правило: заменить символ с ASCII-кодом 29 на печатный символ, например, #.
3. После этого перейдите в вашу учетную систему (например, 1С) в настройки драйвера подключаемого оборудования (сканера штрихкодов).
4. В параметрах драйвера найдите поле Символ GS / Символ-разделитель и укажите там тот же самый знак (например, #). Теперь 1С будет корректно понимать, где в полученной строке находится разделитель групп данных, и сможет без проблем разобрать маркировку.

Решение 4. Использование специализированного софта для трансляции штрихкодов

Если стандартными средствами Android и RDP-клиента добиться стабильной работы не удается, отличным выходом будет использование сторонней утилиты-транспортера. На рынке существуют специализированные бесплатные и коммерческие приложения, которые перехватывают данные сканера на ТСД и передают их на сервер не в виде эмуляции клавиатуры, а по сетевому протоколу (TCP/IP) напрямую в специальную службу-приемник на сервере.

Одним из таких решений является утилита ScanCodeTransport (ТранспортШтрихкодов).

Для организации работы по этой схеме настроим интеграцию:

1. Установите мобильное приложение-клиент на ТСД.
2. Установите серверную часть утилиты на RDP-сервер (она будет слушать входящие данные на определенном порту и эмулировать ввод штрихкода локально на сервере).
3. В настройках сканера ТСД измените режим передачи с эмуляции клавиатуры на широковещательное сообщение (Intent).
4. В настройках приложения-транспортера укажите параметры перехвата этого сообщения. Для терминалов Honeywell ScanPal параметры будут следующими:
   Скопировать код

   
   Action (строка действия): scan.rcv.message
   String extra (дополнительные данные): dataBytes
   

5. Укажите IP-адрес сервера и порт для отправки. При такой схеме данные передаются мгновенно и без малейших потерь независимо от качества связи в RDP-сессии.

Решение 5. Настройка синхронизации клавиши SHIFT и выбор RDP-клиента

Если штрихкоды передаются полностью, но буквы приходят в неверном регистре (строчные вместо прописных), проанализируем настройки клавиатуры вашего RDP-клиента:

• В настройках подключения вашего RDP-клиента (например, Microsoft Remote Desktop) перейдите в раздел параметров локальных ресурсов (Local Resources).
• Найдите настройку обработки комбинаций клавиш клавиатуры (Apply Windows key combinations).
• Установите для нее значение On the local computer (Выполнять на локальном компьютере). Это позволит операционной системе ТСД самой обрабатывать регистр символов перед отправкой пакета на сервер.
• Если стандартный клиент от Microsoft продолжает сбоить, попробуйте использовать альтернативные RDP-клиенты, такие как Parallels Client. Практика показывает, что буфер клавиатуры в нем обрабатывается значительно стабильнее при работе со сканирующим оборудованием на Android.

Решение 6. Кардинальный подход: переход от RDP к специализированному мобильному ПО

Будем откровенны: использование ТСД в качестве «глупой клавиатуры» через RDP — это технологический костыль, из-за которого бизнес регулярно несет убытки при сбоях связи на складе. При малейшем пропадании Wi-Fi или задержке сети RDP-сессия зависает, а работа кладовщика останавливается.

Наиболее надежным решением проблемы является переход на архитектуру прямого взаимодействия через специализированное мобильное ПО (например, продукты линеек Клеверенс / Mobile SMARTS или мобильный клиент 1С). В качестве готового варианта работы на ТСД подойдёт решение для проверки и подбора маркируемой продукции через мобильный клиент 1С.

Рассмотрим, почему этот подход работает безупречно:

• Локальная обработка данных: Мобильное приложение устанавливается непосредственно в память ТСД. При сканировании оно обращается к сканирующему модулю на системном уровне через Android Intents. Потеря хотя бы одного символа исключена физически — устройство считывает штрихкод со 100% точностью.
• Автономность работы: Даже если на складе пропадет Wi-Fi, кладовщик сможет продолжить сканирование товаров. Все данные сохраняются в локальной базе данных ТСД. При восстановлении связи устройство автоматически синхронизирует документы с центральной базой 1С по HTTP/веб-сервисам.
• Удобство интерфейса: Экран RDP-сессии на ТСД выглядит мелко и неудобно для работы пальцами. Специализированные мобильные приложения имеют крупный, адаптированный под экраны ТСД интерфейс, что существенно ускоряет работу сотрудников.

Подводя итог, отметим: если вы ограничены бюджетом и обязаны настроить работу именно через RDP — последовательно выполните рекомендации по переводу ТСД Honeywell в режим эмуляции Keyboard, очистите поле Wedge as keys, настройте задержку Inter-character delay на уровне 30 мс и настройте замену символа GS. Это позволит решить проблему потери данных в большинстве стандартных сценариев.