Почему возникает ошибка «Значение поля Номер не уникально» при установке номера реализации и как её исправить?

← На главную

При автоматизации учета в типовых конфигурациях (например, «1С:Управление торговлей», «1С:Комплексная автоматизация» или «1С:ERP») нередко возникает задача синхронизировать номера документов — например, присвоить документу РеализацияТоваровУслуг такой же номер, как у исходного документа ЗаказКлиента. Попытка переопределить номер через подписку на событие ПриУстановкеНовогоНомера часто приводит к ошибке времени выполнения: Значение поля "Номер" не уникально, даже если в видимом списке документов реализация с таким номером отсутствует.

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

Причины возникновения ошибки контроля уникальности

Проанализируем основные технические факторы, из-за которых платформа 1С блокирует запись документа:

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

Особенности работы события ПриУстановкеНовогоНомера

Рассмотрим, как работает процедура установки номера. Обработчик подписки на событие ПриУстановкеНовогоНомера вызывается только в момент штатной генерации нового номера:


Процедура Авэкс_ПриУстановкеНовогоНомера(Источник, СтандартнаяОбработка, Префикс) Экспорт
    Если ТипЗнч(Источник) = Тип("ДокументОбъект.РеализацияТоваровУслуг") Тогда
        Если Источник.ЭтоНовый()
            И ЗначениеЗаполнено(Источник.ЗаказКлиента)
            И ТипЗнч(Источник.ЗаказКлиента) = Тип("ДокументСсылка.ЗаказКлиента") Тогда
            СтандартнаяОбработка = Ложь;
            Источник.Номер = Источник.ЗаказКлиента.Номер;
        КонецЕсли;
    КонецЕсли;
КонецПроцедуры

Отключение стандартной обработки (СтандартнаяОбработка = Ложь) отменяет лишь платформенный алгоритм формирования очередного номера по порядку, но не отменяет контроль уникальности при физической транзакции записи в СУБД. Если номер уже занят, исключение неизбежно.

Пошаговый алгоритм поиска проблемы и исправления

Разберем по шагам, как диагностировать и устранить ошибку.

Проверяем наличие дубликата прямым запросом без учета RLS. Выполним запрос в консоли запросов или через обработку в привилегированном режиме, чтобы найти документ, скрытый от текущего пользователя:


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |   Док.Ссылка КАК Ссылка,
    |   Док.Проведен КАК Проведен,
    |   Док.ПометкаУдаления КАК ПометкаУдаления,
    |   Док.Организация КАК Организация,
    |   Док.Дата КАК Дата
    |ИЗ
    |   Документ.РеализацияТоваровУслуг КАК Док
    |ГДЕ
    |   Док.Номер = &ИскомыйНомер";

Запрос.УстановитьПараметр("ИскомыйНомер", "МФ00-037239");
Результат = Запрос.Выполнить().Выгрузить();

Сбрасываем кэш нумерации. Если запрос не вернул строк, но ошибка сохраняется, выполним программное обновление пространства номеров с помощью метода глобального контекста: ОбновитьНумерациюОбъектов(Метаданные.Документы.РеализацияТоваровУслуг);

Добавляем проверку занятости номера перед присвоением. Чтобы исключить аварийное завершение транзакции, модернизируем логику заполнения. Перенесем установку номера в обработчик ПередЗаписью или ОбработкаЗаполнения с предварительной проверкой:


// Проверяем, свободен ли номер перед записью реализации
Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ ПЕРВЫЕ 1
    |   Док.Ссылка
    |ИЗ
    |   Документ.РеализацияТоваровУслуг КАК Док
    |ГДЕ
    |   Док.Номер = &Номер
    |   И Док.Дата МЕЖДУ &НачалоГода И &КонецГода
    |   И Док.Ссылка <> &ТекущаяСсылка";

Запрос.УстановитьПараметр("Номер", Источник.ЗаказКлиента.Номер);
Запрос.УстановитьПараметр("НачалоГода", НачалоГода(Источник.Дата));
Запрос.УстановитьПараметр("КонецГода", КонецГода(Источник.Дата));
Запрос.УстановитьПараметр("ТекущаяСсылка", Источник.Ссылка);

Если Запрос.Выполнить().Пустой() Тогда
    Источник.Номер = Источник.ЗаказКлиента.Номер;
Иначе
    // Если номер занят (например, вторая отгрузка по заказу), 
    // оставляем автонумерацию или добавляем суффикс
    Источник.УстановитьНовыйНомер();
КонецЕсли;

Почему возникает ошибка «Значение поля Номер не уникально» при установке номера реализации и как её исправить?

Причины возникновения ошибки контроля уникальности

Особенности работы события ПриУстановкеНовогоНомера

Пошаговый алгоритм поиска проблемы и исправления

Рекомендуемый подход к отображению номеров

Читайте также