Работа со сканером штрихкода в терминальной сессии (RDP) часто сопровождается техническими сложностями. Типичная ситуация: пользователь сканирует товар, но в документе 1С позиции появляются с огромной задержкой — например, со скоростью один товар в секунду. При этом при сканировании в обычный «Блокнот» данные передаются мгновенно. Рассмотрим подробно, почему это происходит в 1С:Управление торговлей 10.3 и какие шаги необходимо предпринять для решения проблемы.
Первым делом нам необходимо понять, на каком этапе происходит задержка: на уровне передачи данных от сканера к серверу или на уровне обработки данных внутри 1С. Для этого проанализируем работу сканера в текстовом редакторе. Откроем notepad.exe прямо внутри той же RDP-сессии, где запущена 1С, и попробуем быстро отсканировать десяток штрихкодов.
Если в блокноте символы появляются мгновенно, значит, канал связи и проброс устройства настроены корректно. Проблема кроется в том, как 1С:Предприятие интерпретирует входящий поток данных. Если же и в блокноте цифры «печатаются» медленно, проблему нужно искать в настройках RDP-протокола или аппаратных настройках самого сканера.
Большинство бюджетных сканеров по умолчанию работают в режиме Keyboard Wedge (эмуляция клавиатуры). В этом режиме каждый символ штрихкода передается как отдельное нажатие клавиши. Проанализируем, что происходит в RDP: при сканировании кода из 13 цифр (EAN-13) сканер имитирует 13 нажатий клавиш и нажатие Enter. Каждое нажатие — это отдельный пакет данных, который должен пройти по сети, обработаться сервером и вернуться обратно. Это создает огромную нагрузку на очередь сообщений Windows.
Решение: Переведем сканер в режим эмуляции COM-порта (USB-Serial). В этом режиме данные передаются не посимвольно, а единым пакетом данных («внешнее событие»).
Это кардинально снижает нагрузку на канал связи и убирает задержки, связанные с «залипанием» клавиш.
Если перевод на COM-порт невозможен, разберем настройки драйвера (например, АТОЛ или 1С:Сканер штрихкода). В параметрах драйвера есть критически важный показатель — Таймаут (или Чувствительность). Если этот параметр выставлен слишком большим (например, более 100-200 мс), система будет ждать окончания ввода после каждого символа, что и создает эффект «медленного прибавления единичек».
Проверим также версию драйвера. В старых версиях библиотек ScanOPOS.dll наблюдались проблемы с утечкой дескрипторов в RDP-сессиях, что приводило к деградации производительности при длительной работе пользователя в системе.
В конфигурации УТ 10.3 при поступлении данных от сканера вызывается процедура ВнешнееСобытие. Рассмотрим, что может замедлять её выполнение. Выясним, какие действия выполняются при каждом сканировании. Часто в коде прописаны «тяжелые» операции:
Если проблема проявляется только у определенных пользователей, проверим их права доступа (RLS). Ограничения на уровне записей могут заставлять SQL-сервер выполнять сложные проверки при каждом поиске товара, что значительно увеличивает время отклика.
Посмотрим на пример упрощенного кода обработки события (подобная логика используется, когда печатается накладная из перемещения товаров со штрихкодом):
Процедура ВнешнееСобытие(Источник, Событие, Данные)
Если Событие = "Barcode" Тогда
// Вместо поиска в цикле по всей базе,
// используем специализированные функции драйвера
СтруктураНоменклатуры = РаботаСШтрихкодами.ОпределитьНоменклатуруПоШтрихкоду(Данные);
Если СтруктураНоменклатуры.Пустая() Тогда
Возврат;
КонецЕсли;
// Добавление в документ
ОбработкаРедактированияДанных(СтруктураНоменклатуры);
КонецЕсли;
КонецПроцедуры
Поскольку пользователи отмечают, что тормоза «плавающие» и привязаны к конкретным учетным записям, проанализируем состояние кэша 1С на сервере. Со временем файлы кэша метаданных и пользовательских настроек могут повреждаться или разрастаться до гигантских размеров.
Выполним следующие действия для «проблемных» пользователей:
%AppData%\1C\1Cv8 и %LocalAppData%\1C\1Cv8 на сервере для данного профиля.Выясним настройки подключения к серверу. Для стабильной работы устройств ввода в современных версиях Windows Server крайне рекомендуется использовать UDP вместо стандартного TCP. UDP гораздо устойчивее к микрозадержкам и потерям пакетов, которые часто случаются на складах с Wi-Fi покрытием.
Также проверим настройки графики в RDP. Высокая глубина цвета (32 бита) и визуальные эффекты могут «забивать» канал данных, из-за чего пакеты от сканера обрабатываются с низким приоритетом. Рекомендуется установить глубину цвета 15 или 16 бит для складских рабочих мест.
Если база данных работает на MS SQL Server, медленный поиск товара может быть следствием фрагментации индексов в таблице штрихкодов (обычно это регистр сведений Штрихкоды). Разберем ситуацию: при каждом сканировании 1С делает запрос к этой таблице. Если статистика SQL устарела, сервер может выбрать неоптимальный план запроса (например, сканирование всей таблицы вместо поиска по индексу).
Рекомендуется настроить еженедельное (или ежедневное для крупных баз) выполнение следующих команд в Management Studio:
-- Обновление статистики для ускорения поиска
UPDATE STATISTICS [ИмяТаблицыРегистраШтрихкодов];
-- Реорганизация индексов
ALTER INDEX ALL ON [ИмяТаблицыРегистраШтрихкодов] REORGANIZE;
Мы проанализировали основные причины замедления работы сканера в 1С:УТ 10.3. Чаще всего проблема решается переводом сканера в режим COM-порта и настройкой UDP в RDP-сессии. Если эти меры не помогают, следует переходить к профилированию кода ВнешнееСобытие и проверке индексов базы данных. Системный подход к диагностике (от блокнота к коду 1С) позволяет быстро найти «узкое горлышко» и восстановить нормальную скорость отгрузки товаров.