Как настроить распознавание штрихкодов складских ячеек в Рабочем месте склада в 1С:Комплексная автоматизация 2.4?

При внедрении адресного склада и ордерной схемы в конфигурациях 1С:Комплексная автоматизация 2.4 (а также в смежных решениях 1С:ERP 2.4 и 1С:Управление торговлей 11.4) специалисты часто сталкиваются со специфической проблемой. При попытке отсканировать распечатанный штрихкод складской ячейки в обработке «Рабочее место работника склада» (РМС) система выдает ошибку «Считан неверный штрихкод». При этом ручной ввод буквенно-цифрового кода ячейки (например, «Л02-03-Я1-1») работает корректно.

В этой статье мы подробно разберем причины возникновения этой проблемы, изучим архитектуру механизма виртуального штрихкодирования в 1С и рассмотрим несколько способов решения этой задачи — от быстрого исправления «в лоб» до красивой программной доработки с использованием расширений конфигурации.

---

Выясняем причину: почему штрихкод не распознается системой?

Для того чтобы понять суть проблемы, проанализируем, как формируется штрихкод ячейки при печати через стандартную обработку ПечатьЭтикетокИЦенников. Когда мы нажимаем кнопку «Печать» на форме складской ячейки, система генерирует штрихкод на основании внутренней функции общего модуля ШтрихкодированиеПечатныхФорм:

Функция ЧисловойКодПоСсылке(Ссылка) Экспорт
    ШестнадчатиричноеЧисло = СтрЗаменить(Строка(Ссылка.УникальныйИдентификатор()), "-", "");
    Возврат ПреобразоватьИзШестнадцатиричнойСистемыСчисленияВДесятичноеЧисло(ШестнадчатиричноеЧисло);
КонецФункции

Проанализируем этот алгоритм:

1. Система получает уникальный идентификатор объекта (UUID/GUID) ячейки из базы данных. Это 36-символьная строка в шестнадцатеричном формате.
2. Из строки удаляются дефисы, в результате чего получается 32-значное шестнадцатеричное число.
3. Это число переводится в десятичную систему счисления. Получается очень длинная цифровая последовательность (обычно 37–38 знаков), например: 9507420177192455137943445267655225560. Именно это число кодируется в графический штрихкод (обычно формата Code-128) и выводится на печать.

Теперь посмотрим, что происходит в обработке «Рабочее место работника склада» (РМС) при сканировании этого штрихкода:

1. Реквизит формы, принимающий значение сканирования (ШтрихкодПараметраСканирования), имеет жесткое ограничение на длину ввода. Длинный 38-значный цифровой код просто обрезается при получении данных от сканера.
2. Логика РМС в старых релизах линейки 2.4 не производит обратное декодирование десятичного GUID в ссылку. Вместо этого программа пытается напрямую сравнить полученную строку с текстовым кодом ячейки (например, «Л02-03-Я1-1»). Разумеется, сравнение длинного цифрового кода с коротким буквенно-цифровым адресом завершается ошибкой.

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

---

Вариант 1. Быстрое исправление логики сравнения строк (Вариант автора темы)

Рассмотрим первый практический вариант решения, который позволяет быстро исправить ситуацию путем точечной доработки кода. Метод заключается в перенаправлении логики сопоставления на реквизит ШтрихкодЯчейки.

Шаг 1. Увеличение длины принимающего реквизита на форме

В обработке РабочееМестоРаботникаСклада на всех используемых формах необходимо найти реквизит ШтрихкодПараметраСканирования и в его свойствах увеличить максимальную длину ввода. Установите значение длины равным 45 символам. Это гарантирует, что длинный цифровой код, преобразованный из GUID, не будет обрезаться при сканировании или ручном вводе.

Шаг 2. Корректировка серверного модуля обработки

Перейдем в общий модуль РабочееМестоРаботникаСкладаСервер. Нам необходимо скорректировать логику в процедуре ПриСканированииЯчейки. Вместо сравнения с текстовым кодом ячейки мы заставим систему сверять данные по штрихкоду:

// Было:
// Для Каждого СтрокаТоваров Из ТоварыДляСканирования Цикл
//     Если ВРег(СтрокаТоваров.КодЯчейки) = ВРег(ШтрихкодЯчейки) Тогда
//         Ячейка = СтрокаТоваров.Ячейка;
//         Прервать;
//     КонецЕсли;
// КонецЦикла;

// Стало:
Для Каждого СтрокаТоваров Из ТоварыДляСканирования Цикл
    Если ВРег(СтрокаТоваров.ШтрихкодЯчейки) = ВРег(ШтрихкодЯчейки) Тогда
        Ячейка = СтрокаТоваров.Ячейка;
        Прервать;
    КонецЕсли;
КонецЦикла;

Этот способ решает проблему «в лоб». Система начнет сопоставлять отсканированный длинный код со штрихкодом ячейки, который предварительно должен быть заполнен или рассчитан в табличной части товаров.

---

Вариант 2. Использование штатного механизма обратного декодирования (Рекомендуемый программный подход)

Более изящным и методологически верным решением является программное декодирование считанной строки обратно в ссылку на объект базы данных. Платформа 1С содержит готовые механизмы для обратной конвертации длинного десятичного кода в уникальный идентификатор UUID.

В общем модуле ШтрихкодированиеПечатныхФорм присутствует экспортная функция ПолучитьСсылкуПоШтрихкодуТабличногоДокумента. Мы можем использовать её в обработчике сканирования ячейки. Напишем универсальный код, который сначала попытается преобразовать штрихкод как GUID, а если это не удастся (например, если сканируется обычный короткий текстовый штрихкод), выполнит стандартный поиск по коду ячейки.

Рассмотрим пример реализации функции декодирования:

&НаСервереБезКонтекста
Функция НайтиЯчейкуПоШтрихкоду(Знач ШтрихкодЯчейки)
    
    ЯчейкаСсылка = Справочники.СкладскиеЯчейки.ПустаяСсылка();
    
    // Шаг 1. Пытаемся получить ссылку по GUID через штатный декодер
    МассивМенеджеров = Новый Массив;
    МассивМенеджеров.Добавить(Справочники.СкладскиеЯчейки.ПустаяСсылка());
    
    Попытка
        СсылкаДекодированная = ШтрихкодированиеПечатныхФорм.ПолучитьСсылкуПоШтрихкодуТабличногоДокумента(ШтрихкодЯчейки, МассивМенеджеров);
        Если ЗначениеЗаполнено(СсылкаДекодированная) И ТипЗнч(СсылкаДекодированная) = Тип("СправочникСсылка.СкладскиеЯчейки") Тогда
            ЯчейкаСсылка = СсылкаДекодированная;
        КонецЕсли;
    Исключение
        // Если при декодировании произошла ошибка (код не является десятичным представлением GUID)
        ЯчейкаСсылка = Справочники.СкладскиеЯчейки.ПустаяСсылка();
    КонецПопытки;
    
    // Шаг 2. Если по GUID ничего не нашли, ищем стандартным поиском по Коду (наименованию)
    Если Не ЗначениеЗаполнено(ЯчейкаСсылка) Тогда
        ЯчейкаСсылка = Справочники.СкладскиеЯчейки.НайтиПоКоду(ШтрихкодЯчейки);
    КонецЕсли;
    
    Возврат ЯчейкаСсылка;

КонецФункции

Преимущества данного подхода:

• Универсальность: программа корректно обрабатывает как уже расклеенные старые этикетки (с десятичным GUID), так и новые этикетки, на которых закодирован обычный адрес ячейки, а также ручной ввод с клавиатуры.
• Сохранение структуры данных: нам не требуется создавать дополнительные реквизиты в справочнике СкладскиеЯчейки для хранения длинных кодов и перегружать базу данных избыточными индексами.
• Чистота кода: логика базируется на штатных механизмах конфигурации 1С.

---

Вариант 3. Изменение шаблона этикетки на печать текстового Кода ячейки

Если ваш склад находится на этапе запуска или объем нерасклеенных ячеек позволяет выполнить перепечать, лучшим архитектурным решением будет отказ от кодирования ссылки (GUID) в штрихкод ячейки.

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

1. Перейдем в раздел администрирования шаблонов этикеток и ценников (обычно находится в настройках продаж или складского учета).
2. Откроем используемый макет этикетки для назначения «Складские ячейки».
3. Выделим графический элемент штрихкода и откроем его свойства. Вместо значения по умолчанию (которое кодирует ссылку на объект) установим заполнение из поля «Код» или «Наименование» ячейки (например, значение вида Л02-03-Я1-1).
4. Сохраним шаблон.

Штрихкоды, генерируемые по короткому коду ячейки, обладают неоспоримыми преимуществами при физической работе на складе:

• Высокая скорость сканирования: плотность штрихкода для значения «Л02-03-Я1-1» (11 символов) значительно ниже, чем для 38-значного цифрового GUID. Сканеры терминалов сбора данных (ТСД) распознают такой разреженный код мгновенно даже в условиях плохой освещенности или при частичном повреждении этикетки.
• Отсутствие ошибок переполнения: длина штрихкода гарантированно укладывается в стандартные ограничения полей ввода в любых складских обработках 1С без внесения изменений в код конфигурации.

---

Рекомендация по обновлению и переходу на КА 2.5 / ERP 2.5

Описанная проблема является классическим примером функционального расхождения в ранних релизах линейки 1С:ERP / Комплексная автоматизация 2.4. В последующих версиях конфигураций (начиная с релизов 2.5 и выше) разработчики фирмы 1С провели масштабную работу над ошибками:

• Было разработано новое технологичное решение «1С:Мобильное рабочее место кладовщика» (МРМК), функционирующее на платформе мобильного клиента.
• В новой архитектуре мобильного рабочего места обработчики сканирования изначально проектировались с поддержкой декодирования GUID-кодов «из коробки».

Если у вас есть возможность планового перехода на актуальные релизы конфигурации, это позволит полностью решить проблему в рамках поддержки стандартного функционала без необходимости поддержки нетипового программного кода.