При автоматизации складского учета и розничной торговли в среде «1С:Предприятие 7.7» нередко возникает неприятная ситуация: товар промаркирован штрихкодом из 13 цифр, начинающимся с нуля (например, 0000692000601), однако при сканировании в систему передается только 12 знаков без первой цифры. При этом обычные коды, начинающиеся с ненулевых символов, считываются корректно. Выясним причину такого поведения оборудования и разберем по шагам все способы устранения проблемы.
Проанализируем техническую сторону формирования штрихкодов. Исторически первым появился американский стандарт UPC-A, содержащий 12 значащих цифр. Позже для международного использования был разработан европейский стандарт EAN-13 на 13 позиций. Чтобы обеспечить обратную совместимость, разработчики EAN-13 сделали структуру кода расширением UPC-A: тринадцатая (крайняя левая) цифра кодируется не отдельными штрихами, а выбором схемы кодирования для левой группы знаков.
Если первой цифрой тринадцатизначного кода оказывается ноль, то рисунок штрихов становится абсолютно идентичным двенадцатизначному штрихкоду UPC-A. Сканер штрихкодов (например, популярные модели Metrologic / Honeywell MS9520 Voyager), считывая такой рисунок, по умолчанию распознает его как UPC-A и передает в порт компьютера ровно 12 цифр без лидирующего нуля. Это поведение заложено в прошивке на аппаратном уровне.
Самый правильный и надежный путь — настроить сам сканер штрихкодов так, чтобы он автоматически преобразовывал распознанные двенадцатизначные коды UPC-A в тринадцатизначный формат EAN-13 путем принудительного добавления первого нуля.
В результате сканер начнет автоматически возвращать полные 13 знаков с лидирующим нулем для всех кодов, построенных по этой схеме.
Если после включения трансляции UPC-A в EAN-13 проблема сохраняется, проанализируем другие сервисные функции сканера:
Если на предприятии используется парк разнородных сканеров или нет физической возможности перенастроить оборудование у удаленных пользователей, решим задачу программно на уровне конфигурации 1С. Рассмотрим подробнее реализацию.
При поступлении данных от внешней компоненты драйвера сканера вызывается предопределенная процедура ОбработкаВнешнегоСобытия. Добавим проверку длины полученной строки: если длина штрихкода равна 12 символам, дополним его лидирующим нулем перед поиском товара в базе данных.
Посмотрим на пример кода, размещаемого в модуле формы или в процедуре глПолучитьТоварПоШтрихкоду глобального модуля:
Процедура ОбработкаВнешнегоСобытия(Источник, Событие, Данные)
Если Событие = "BarCodeValue" Тогда
ВходнойШтрихкод = СокрЛП(Данные);
// Если сканер вернул 12 символов вместо 13, восстанавливаем первый ноль
Если СтрДлина(ВходнойШтрихкод) = 12 Тогда
ВходнойШтрихкод = "0" + ВходнойШтрихкод;
КонецЕсли;
// Выполняем стандартный поиск номенклатуры по нормализованному коду
Товар = глНайтиТоварПоШК(ВходнойШтрихкод);
КонецЕсли;
КонецПроцедуры
Также важно обратить внимание на режим подключения сканера. Если сканер работает в режиме клавиатурной эмуляции (USB-HID), данные просто «впечатываются» в активное поле ввода. Если реквизит диалога имеет тип Число, платформа 1С автоматически отсечет любые начальные нули. Проверьте, чтобы реквизиты штрихкодов в справочниках и документах всегда имели строковый тип данных (Строка).
Разберем фундаментальную причину возникновения подобных коллизий. Штрихкоды формата 0000692000601 формируются некорректно с точки зрения стандартов GS1. Префиксы, начинающиеся с 0, отведены международной классификацией для предприятий США и Канады (система UPC-A).
Чтобы раз и навсегда избежать аппаратных конфликтов в сканерах штрихкодов, рекомендуем использовать правильные диапазоны:
2000000000018). Эти префиксы официально зарезервированы под внутреннее использование, не пересекаются с мировыми кодами производителей и никогда не распознаются сканерами как UPC-A.