Почему один товар может иметь несколько штрихкодов в «1С:Бухгалтерии 3.0» и как устроен регистр штрихкодов

При работе с клиентами каждый специалист может оказаться в неловкой ситуации, когда его теоретические представления о работе системы расходятся с практической реальностью. Классический пример — логика работы со штрихкодами в типовых конфигурациях семейства «1С:Предприятие 8». На первый взгляд кажется, что связь между товаром и его штрихкодом должна быть жесткой и взаимно-однозначной: один товар — один штрихкод. Однако в реальном бизнесе и в архитектуре 1С все устроено гораздо интереснее. Давайте подробно разберем, как спроектирован регистр штрихкодов в «1С:Бухгалтерии предприятия 3.0» (БП 3.0) и других конфигурациях, почему один товар может обладать целым списком штриховых кодов, и как технически это реализовано на уровне платформы.

Архитектура регистра сведений «Штрихкоды номенклатуры»

Для того чтобы понять логику работы штрихкодов, нам необходимо заглянуть в конфигуратор и проанализировать структуру метаданных. В «1С:Бухгалтерии предприятия 3.0» сведения о штрихкодах хранятся в независимом непериодическом регистре сведений ШтрихкодыНоменклатуры. Рассмотрим состав ключевых полей этого регистра:

• Измерения: основным и единственным ключевым измерением является Штрихкод (тип: Строка).
• Ресурсы: в качестве ресурса выступает Номенклатура (тип: СправочникСсылка.Номенклатура). В зависимости от конфигурации, в ресурсах также могут находиться Упаковка, Характеристика или Серия.

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

1. Один товар — много штрихкодов. В ресурсе Номенклатура может быть указан один и тот же элемент справочника для разных строк регистра. Так как штрихкоды в этих строках различаются (измерения уникальны), СУБД без проблем запишет эти строки. В результате мы получаем отношение «один ко многим»: для одной номенклатурной позиции в базе может существовать неограниченное количество штрихкодов.
2. Один штрихкод — только один товар. Мы физически не сможем записать в регистр две строки с абсолютно одинаковым штрихкодом для разных товаров. При попытке сделать это СУБД либо выдаст ошибку дублирования ключа, либо (при стандартной записи в 1С) старая запись с этим штрихкодом будет перезаписана новой номенклатурой. Таким образом, система «из коробки» защищает базу данных от ситуации, когда один и тот же штрихкод ссылается на разные физические товары.

Реальные бизнес-кейсы: когда одному товару нужно несколько штрихкодов

Давайте выясним, зачем разработчики фирмы «1С» заложили такую логику и почему конфигурация «1С:Бухгалтерия 3.0» поддерживает хранение нескольких штрихкодов для одной позиции номенклатуры. В реальной торговой и производственной практике постоянно возникают ситуации, требующие именно такого подхода:

• Различные заводы-изготовители и партии. Крупные производители часто выпускают один и тот же товар (например, газированную воду одного бренда и объема) на разных заводах. При этом штрихкоды на бутылках могут отличаться в зависимости от филиала производства. Для торговой компании это один и тот же товар с одинаковой ценой и артикулом, поэтому заводить под каждый завод отдельную карточку номенклатуры нецелесообразно. Гораздо удобнее привязать все штрихкоды к одной карточке.
• Повреждение заводской маркировки. Если штрихкод на упаковке товара затерся или порвался при транспортировке, кладовщики генерируют внутренний штрихкод системы и наклеивают его поверх поврежденного. В базе данных для этого товара теперь будет числиться два штрихкода: оригинальный заводской (для уцелевших экземпляров) и новый внутренний (для перемаркированных).
• Упаковки разного объема. Товар может продаваться поштучно, коробками по 10 штук или паллетами по 100 штук. В логистических процессах штука товара и коробка имеют разные штрихкоды (например, штука — EAN-13, а коробка — ITF-14). В системе «1С» это может быть одна карточка номенклатуры, к которой привязаны разные штрихкоды с указанием соответствующей упаковки в ресурсах регистра.
• Маркетинговые и промо-акции. Иногда производители выпускают специальные акционные серии товаров (например, «+20% бесплатно») с измененным штрихкодом, но продаются они по той же цене и учитываются на том же складе, что и регулярный товар. Чтобы не плодить дубли карточек в справочнике Номенклатура, маркетологи просто добавляют новый штрихкод к существующей карточке.

Различия в архитектуре штрихкодов в БП 3.0, УТ 11, Рознице и УНФ

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

В комплексных торговых решениях, таких как «1С:Управление торговлей 11» (УТ 11) или «1С:ERP Управление предприятием», учет устроен значительно сложнее. В регистре штрихкодов помимо номенклатуры присутствуют такие измерения и ресурсы, как Характеристика, Серия и Упаковка. Это позволяет идентифицировать не просто товар в целом, а его конкретное свойство (например, определенный цвет или размер обуви) по уникальному штрихкоду.

В «1С:Бухгалтерии 3.0» детальный учет серий и характеристик в базовом варианте отсутствует, так как задача бухгалтерской программы — это регламентированный учет, а не складская логистика. Тем не менее, базовая структура регистра сведений «Штрихкоды номенклатуры» спроектирована по тем же принципам уникальности штрихкода в измерении. Это делает интеграцию между БП 3.0 и УТ 11 максимально бесшовной: при переносе данных штрихкоды легко сопоставляются.

Стоит отметить конфигурации «1С:Розница» и «1С:Управление нашей фирмой» (УНФ). В этих программах разработчики предусмотрели специальную опцию: «Использовать неуникальные штрихкоды». Если этот флаг включен, система позволяет присваивать один штрихкод разным товарам (что часто практикуется производителями дешевой продукции). При сканировании такого неуникального штрихкода на кассе программа предлагает пользователю интерактивный выбор из списка найденных товаров.

Технические нюансы: слияние дублей и программная работа с регистром

Рассмотрим важную проблему, с которой сталкиваются программисты и администраторы баз данных при наведении порядка в справочнике Номенклатура. Допустим, в базе образовались две дублирующие друг друга карточки товара: «Товар А» и «Товар Б». У каждой из них в регистре сведений зарегистрирован свой штрихкод (у «Товара А» — код 1111, у «Товара Б» — код 2222).

Если мы воспользуемся стандартной обработкой «Поиск и замена дублей» для объединения этих карточек в «Товар А», система автоматически перепишет ссылки в регистре сведений. Владельцем обеих записей штрихкодов станет «Товар А». Никаких ошибок не возникнет, у товара просто станет два рабочих штрихкода.

Однако проанализируем другую ситуацию: из-за ошибок интеграции или некорректного ручного ввода в регистре штрихкодов для разных карточек («Товар А» и «Товар Б») оказался записан одинаковый штрихкод 5555 (например, если контроль уникальности был временно отключен при загрузке или запись производилась напрямую через СУБД/запросы). При попытке объединить эти дубли обработка попытается изменить владельца для записи штрихкода 5555 у «Товара Б» на «Товар А». В этот момент платформа «1С» попытается записать в базу данных вторую строку с ключевым измерением 5555, что приведет к ошибке транзакции:

Ошибка при записи в регистр сведений ШтрихкодыНоменклатуры. Запись с такими ключевыми полями уже существует!

Для предотвращения подобных коллизий при разработке собственных обработок загрузки штрихкодов необходимо предварительно проверять наличие штрихкода в базе. Давайте посмотрим на пример правильной программной записи штрихкода с предварительной проверкой уникальности:

// Функция безопасной записи штрихкода для номенклатуры
Процедура ЗаписатьШтрихкодНоменклатуры(ТекущаяНоменклатура, ЗначениеШтрихкода) Экспорт
    
    // 1. Проверим, не зарегистрирован ли уже этот штрихкод в системе
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |	Штрихкоды.Номенклатура КАК ТекущийВладелец
        |ИЗ
        |	РегистрСведений.ШтрихкодыНоменклатуры КАК Штрихкоды
        |ГДЕ
        |	Штрихкоды.Штрихкод = &Штрихкод";
    
    Запрос.УстановитьПараметр("Штрихкод", ЗначениеШтрихкода);
    РезультатЗапроса = Запрос.Выполнить();
    
    Если Не РезультатЗапроса.Пустой() Тогда
        Выборка = РезультатЗапроса.Выбрать();
        Выборка.Следующий();
        
        Если Выборка.ТекущийВладелец = ТекущаяНоменклатура Тогда
            // Штрихкод уже привязан к этому товару, ничего делать не нужно
            Возврат;
        Иначе
            // Штрихкод принадлежит другому товару! Выводим предупреждение
            ВызватьИсключение "Штрихкод " + ЗначениеШтрихкода + " уже зарегистрирован за товаром: " + Выборка.ТекущийВладелец;
        КонецЕсли;
    КонецЕсли;
    
    // 2. Если штрихкод свободен, производим запись в регистр
    МенеджерЗаписи = РегистрыСведений.ШтрихкодыНоменклатуры.СоздатьМенеджерЗаписи();
    МенеджерЗаписи.Штрихкод = ЗначениеШтрихкода;
    МенеджерЗаписи.Номенклатура = ТекущаяНоменклатура;
    
    Попытка
        МенеджерЗаписи.Записать(Истина); // Параметр Истина означает замещение существующей записи
        Сообщить("Штрихкод " + ЗначениеШтрихкода + " успешно привязан к номенклатуре " + ТекущаяНоменклатура);
    Исключение
        Сообщить("Не удалось записать штрихкод: " + ОписаниеОшибки());
    КонецПопытки;

КонецПроцедуры

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