Ситуация, когда пользователь вручную меняет номер документа, нарушая последовательность (например, меняет номер с 0000-0015 на 0000-0900), знакома многим администраторам и программистам 1С. Часто такие действия приводят к тому, что при попытке записи нового объекта возникает ошибка «Значение поля Номер не уникально». Обычно проблема решается восстановлением правильных номеров в документах и вызовом метода обновления нумерации. Однако в современных конфигурациях, таких как "Управление торговлей 11", "ERP" или "Комплексная автоматизация", этот метод часто не срабатывает: система упорно продолжает подставлять следующий "кривой" номер (например, 0000-0901).
В этой статье мы подробно разберем, почему так происходит, изучим особенности механизма нумерации в Библиотеке Стандартных Подсистем (БСП) и рассмотрим гарантированный способ решения проблемы.
Для начала вспомним, как платформа 1С определяет следующий номер. Номер документа — это строка. Сортировка строк происходит посимвольно. Если формат номера нарушен (например, убрали лидирующие нули), строка "9" для системы будет "больше", чем строка "100" (так же, как буква "Я" стоит дальше, чем "А").
Когда пользователь вводит номер из будущего или меняет формат, платформа запоминает этот "максимальный" номер. Даже если вы исправите сам документ, внутренний счетчик (или кэш последовательностей СУБД) может помнить старое максимальное значение.
Прежде чем переходить к "секретному" ингредиенту, мы должны выполнить обязательную гигиеническую процедуру — исправить сами документы в базе данных. Без этого шага дальнейшие действия бессмысленны.
// Обычный подход, который часто не помогает в УТ 11
ОбновитьНумерациюОбъектов(Метаданные.Документы.РеализацияТоваровУслуг);
В старых конфигурациях (например, УТ 10.3 или БП 2.0) этого было достаточно. Но в УТ 11, ERP и КА вы можете столкнуться с тем, что даже после этого кода новый документ создается с номером 0901.
Главная причина неудач в современных конфигурациях кроется в архитектуре метаданных. В дереве конфигурации существует отдельная ветка — Нумераторы.
Многие документы в УТ 11 и ERP не имеют собственной стратегии нумерации, а ссылаются на общий объект Нумератор. Например, документы "Реализация товаров и услуг" и "Акт выполненных работ" могут использовать один и тот же нумератор ДокументыРеализацииТоваров.
Важный нюанс: Когда вы вызываете метод ОбновитьНумерациюОбъектов только для документа, платформа может не сбросить кэш для связанного с ним нумератора. Чтобы гарантированно исправить ошибку в нумерации объектов, мы должны обновить нумерацию именно для объекта "Нумератор".
Давайте напишем простую обработку, которая выполнит сброс корректно. Код должен выполняться на сервере.
&НаСервере
Процедура ИсправитьНумерациюНаСервере()
// 1. Сначала пробуем обновить сам документ (на всякий случай)
ОбновитьНумерациюОбъектов(Метаданные.Документы.РеализацияТоваровУслуг);
// 2. ГЛАВНЫЙ ШАГ: Обновляем нумерацию для НУМЕРАТОРА этого документа
// Необходимо посмотреть в конфигураторе, какой нумератор назначен документу.
// В УТ 11 для реализации это часто "ДокументыРеализацииТоваров".
НумераторДокумента = Метаданные.НумераторыДокументов.ДокументыРеализацииТоваров;
ОбновитьНумерациюОбъектов(НумераторДокумента);
Сообщить("Нумерация обновлена для нумератора: " + НумераторДокумента.Имя);
КонецПроцедуры
Если вы не знаете точное имя нумератора, можно получить его динамически через метаданные документа:
&НаСервере
Процедура УниверсальноеИсправление(ИмяДокумента)
МетаданныеДокумента = Метаданные.Документы[ИмяДокумента];
// Обновляем по документу
ОбновитьНумерациюОбъектов(МетаданныеДокумента);
// Проверяем, назначен ли документу нумератор
Если МетаданныеДокумента.Нумератор <> Неопределено Тогда
// Обновляем по нумератору
ОбновитьНумерациюОбъектов(МетаданныеДокумента.Нумератор);
Сообщить("Обновлен нумератор: " + МетаданныеДокумента.Нумератор.Имя);
КонецЕсли;
КонецПроцедуры
Поскольку нумераторы используются для организации сквозной нумерации, проблема может скрываться не в том типе документа, который вы лечите.
Пример из практики:
РеализацияТоваровУслуг и АктВыполненныхРабот.ДокументыРеализацииТоваров.АктВыполненныхРабот.РеализацияТоваровУслуг.Решение: Мы должны проверить все виды документов, которые привязаны к данному нумератору. Найдите объект "Нумератор" в конфигураторе, кликните правой кнопкой мыши и выберите "Поиск ссылок в объекте". Вы увидите список всех документов, влияющих на эту числовую последовательность. Проверьте номера во всех этих журналах.
Если обновление нумератора не помогло, рассмотрим менее очевидные причины.
В клиент-серверном варианте работы платформа захватывает пул номеров для быстродействия. Даже после программного обновления нумерации процесс rphost может держать в памяти старый диапазон. В этом случае полезно выполнить синхронизацию внутреннего кэша нумератора с реальными данными в базе.
Что делать: После выполнения программного кода по обновлению нумерации рекомендуется перезагрузить службу сервера 1С (или хотя бы перезапустить процессы), чтобы сбросить буфер последовательностей.
В конфигурациях УТ 11, КА и ERP существует регистр сведений РеестрДокументов. Хотя технически платформа берет номер из таблицы самого документа, логика прикладного решения при создании формы или префиксации может обращаться к этому регистру. Например, если в системе настроена установка префикса у документов по условию, некорректные данные в реестре могут влиять на алгоритм — для исправления есть диагностика и удаление поврежденных записей в регистрах.
Если номера в документах исправлены, а в регистре осталась старая запись с "кривым" номером (НомерДокументаИБ), это может сбивать алгоритмы. В таких ситуациях поможет чистка справочника «Ключи реестра документов» и восстановление целостности регистра. Также рекомендуется перепровести исправленные документы, чтобы запись в регистре обновилась.
Давайте резюмируем последовательность действий для гарантированного результата:
ОбновитьНумерациюОбъектов, передав туда Метаданные Нумератора.Следуя этой инструкции, вы сможете восстановить правильную последовательность номеров даже в самых сложных случаях.