В процессе работы с торговым оборудованием в среде «1С:Предприятие 8» технические специалисты часто сталкиваются с загадочным поведением сканеров штрихкодов. Ситуация выглядит следующим образом: сканер исправно работает в Блокноте, корректно проходит тесты в драйвере торгового оборудования, но при попытке «пикнуть» товар в реальный документ (например, «Заказ клиента» или «Реализация товаров и услуг»), штрихкод в строке поиска искажается или разбивается на непонятные сегменты. Особенно часто это происходит со штрихкодами, начинающимися на цифру «2».
В данной статье мы подробно проанализируем, почему так происходит, разберем внутреннюю логику работы 1С с префиксами и выясним, как правильно настроить систему, чтобы штрихкоды считывались без ошибок. Мы пройдем путь от диагностики оборудования до тонкой настройки масок в конфигурации «1С:Управление торговлей 11».
Первым делом проанализируем ситуацию, описанную пользователем. Если штрихкод 2900054712345 в Блокноте отображается верно, а в 1С превращается в нечто вроде 2_00054_12345, это означает, что физически сканер работает исправно. Он считывает последовательность символов и передает их в операционную систему.
Проблема кроется на уровне логической обработки данных внутри 1С. Когда данные попадают в программу, они не просто вставляются в поле, а проходят через библиотеку подключаемого оборудования (БПО). Система анализирует первый символ и длину кода. Согласно международному стандарту GS1, диапазон префиксов с 20 по 29 зарезервирован для внутреннего использования предприятиями. Именно здесь зарыта причина: 1С «знает» об этом стандарте и по умолчанию считает, что любой штрихкод на «2» — это не обычный штучный товар (EAN-13), а весовой или сложный штрихкод.
В результате встроенный парсер 1С начинает «разрезать» ваш 13-значный код на части, пытаясь найти в нем код товара (PLU) и вес. Если настройки префиксов не заданы верно, система выдает искаженный результат, так как пытается интерпретировать часть цифр как граммы или килограммы.
Проанализируем, как 1С воспринимает весовой товар. Обычно структура весового штрихкода EAN-13 выглядит так:
Если в вашей базе штрихкод штучного товара случайно начинается на «29», 1С применяет к нему эту маску. В итоге вместо поиска товара по полному коду 2900054712345, программа ищет товар с кодом 00054 и пытается подставить вес 71234. Естественно, такая логика ломает процесс подбора, если товар на самом деле является штучным.
Для исправления этой ситуации нам необходимо «объяснить» программе, что конкретные префиксы (или все коды на «2») должны обрабатываться как обычные штучные штрихкоды. Выполним следующие действия:
В открывшемся окне мы увидим таблицу, где сопоставляются префиксы и типы штрихкодов. Рассмотрим ситуацию: если ваши товары имеют штрихкоды, начинающиеся, например, на «29», а в таблице этот префикс помечен как «Весовой», или вовсе отсутствует (но система по умолчанию считает его весовым), нам нужно явно указать обратное.
Добавьте или отредактируйте строку для префикса «2» (или более детально, например, «29»). Установите для него тип Штучный товар. После сохранения этой настройки 1С перестанет пытаться «распилить» код на части и будет воспринимать его целиком, как обычный EAN-13.
Если предыдущий шаг не помог, нам следует проверить справочник Шаблоны штрихкодов. В современных версиях УТ 11 и ERP этот механизм позволяет настраивать очень сложные правила парсинга. Проанализируем ситуацию, когда в системе заведен шаблон, который перехватывает диапазон штрихкодов.
Если в справочнике существует активный шаблон для весового товара с маской, начинающейся на «2», система всегда будет отдавать ему приоритет. Проверьте длину кода в шаблоне — она должна строго соответствовать 13 символам для стандартных кодов. Если вы не используете весовое оборудование с печатью этикеток, лучше временно деактивировать подозрительные шаблоны для проверки.
Обратим внимание на технический аспект подключения оборудования. В сообщениях форума упоминалось, что в Блокноте все читается нормально. Это верный признак того, что сканер работает в режиме Keyboard Wedge (эмуляция клавиатуры).
Рассмотрим, почему для 1С это не самый лучший вариант:
Рекомендация: Переведите сканер в режим Virtual COM-port. В этом режиме данные передаются напрямую в порт, и 1С обрабатывает их через специальное ВнешнееСобытие. Это исключает влияние раскладки клавиатуры и фокусов ввода. В коде это выглядит примерно так (упрощенно для понимания логики обработки):
Процедура ВнешнееСобытие(Источник, Событие, Данные)
Если Событие = "Barcode" Тогда
Штрихкод = СокрЛП(Данные);
ОбработатьШтрихкод(Штрихкод);
КонецЕсли;
КонецПроцедуры
При использовании режима COM-порта 1С получает «чистую» строку данных, которую легче контролировать и отлаживать.
Выясним еще одну важную деталь. Часто при парсинге весового штрихкода 1С пытается преобразовать часть кода в число. Рассмотрим штрихкод 2900054712345. Если система решит, что это весовой код, она выделит сегмент 00054 как код товара. Если в настройках системы тип кода товара определен как числовой, ведущие нули будут отброшены, и 1С начнет искать товар с кодом 54.
Если такого товара в базе нет (а есть только товар с полным штрихкодом 2900054712345), поиск завершится неудачей. Это еще раз подтверждает важность правильной настройки Префиксов внутренних штрихкодов, чтобы система даже не пыталась выделять SKU из штучного кода.
Подведем итог нашему исследованию. Если ваш сканер «глючит» только на определенных кодах, особенно начинающихся на «2», выполните следующие шаги:
13 (CR)).Мы проанализировали ситуацию и выяснили, что корень проблемы лежит не в поломке «железа», а в глубоких настройках парсинга штрихкодов внутри 1С. Правильная конфигурация префиксов позволит вам избежать ошибок при подборе товара и обеспечит корректную работу склада и торгового зала.