Почему 1С:УНФ генерирует уже существующие штрихкоды и как это исправить?

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

Как работает алгоритм генерации штрихкода в 1С:УНФ

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

1. Программа обращается к регистру сведений ШтрихкодыНоменклатуры.
2. Система ищет записи, соответствующие установленному внутреннему префиксу.
3. Выбирается максимальное строковое значение штрихкода.
4. К полученному числу прибавляется единица.
5. Рассчитывается контрольное число (13-й разряд EAN-13).

Проблема кроется в том, что штрихкод в 1С — это строка, а не число. Рассмотрим подробнее, к чему это приводит.

Причина 1: Сбой сортировки и «мусорные» записи

Проанализируем ситуацию: если в базу вручную был введен штрихкод, который выбивается из общей логики (например, слишком длинный или со странным префиксом), функция МАКСИМУМ в запросе может вернуть некорректный результат. Если в последовательности есть код 209999999999, система может решить, что лимит исчерпан, или начать отсчет заново с 200000000001, который уже давно занят.

Что нужно сделать:

Откроем регистр сведений «Штрихкоды номенклатуры» (через «Все функции» или «Функции для технического специалиста»). Отсортируем список по колонке «Штрихкод» по возрастанию. Прокрутим список в самый низ и внимательно изучим последние 20–30 записей. Если мы видим там коды, введенные вручную, которые нарушают числовую последовательность, их необходимо исправить или удалить.

Причина 2: Настройка уникальности штрихкодов

Выясним, разрешено ли в вашей базе в принципе создавать дубли. В 1С:УНФ существует функциональная опция, которая управляет этим поведением.

Рассмотрим путь к настройке:

1. Перейдем в раздел Настройки.
2. Выберем Еще больше возможностей.
3. Зайдем в подраздел Продажи.
4. Найдем флаг Использовать неуникальные штрихкоды.

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

Причина 3: Конфликты в распределенных базах (РИБ)

Если вы работаете в распределенной информационной базе, причина дублей почти всегда кроется в настройках узлов. Представим, что Магазин №1 и Магазин №2 генерируют коды независимо. Без специальных настроек они оба начнут с кода 200000000001. При синхронизации возникнет коллизия.

Чтобы этого избежать, необходимо для каждого узла РИБ задать свой уникальный префикс штрихкода. Например:

• Узел офиса: префикс 201
• Узел магазина 1: префикс 202
• Узел магазина 2: префикс 203

В этом случае диапазоны никогда не пересекутся.

Причина 4: Программная ошибка в поиске «дырок»

Иногда штатный механизм 1С не просто ищет «максимальный + 1», а пытается найти свободный номер внутри существующего диапазона (так называемые «дырки» после удаления старых товаров). Если этот алгоритм работает некорректно, он может выдать номер, который числится «свободным» в индексе, но фактически занят в таблице данных (проблема кэширования или итогов).

Для решения этой проблемы на уровне кода можно использовать следующий подход (пример для разработчика):

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

Пошаговая инструкция по исправлению ситуации

Рассмотрим алгоритм действий, который поможет вам восстановить корректную генерацию:

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

Проанализировав ситуацию, можно сделать вывод: в 90% случаев проблема решается либо удалением одного-единственного «кривого» штрихкода (например, 2099999999999), который кто-то ввел ради шутки или по ошибке, либо настройкой уникальных префиксов для разных узлов базы данных. Помните, что EAN-13 требует строгого соблюдения структуры, и любое отклонение в длине строки в регистре сбивает штатные механизмы 1С.