Почему при записи документа возникает ошибка «Номер не уникальный» и как восстановить автонумерацию?

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

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

Причины сбоя автонумерации

Выясним причину некорректного поведения системы. Механизм генерации номеров в платформе 1С опирается на строковое представление номера, разделяя его на две составляющие: префиксную (слева) и числовую часть (справа).

1. Смещение границы префикса и числа. Если документы нумеровались по шаблону с одним лидирующим нулем (например, 099998, 099999), платформа может воспринять лидирующий ноль как часть текстового префикса, а не как разряд числа. При попытке сформировать следующий номер 100000 разрядность увеличивается, ноль вытесняется, из-за чего шаблон префикса меняется. Платформа пытается продолжить инкремент по старому шаблону с префиксом 0, упирается в максимальное значение 099999 и повторяет его.
2. Ограничение длины реквизита «Номер». Если в метаданных конфигурации длина номера документа жестко ограничена (например, ровно 6 символов), система физически не может добавить дополнительный разряд для формирования корректной строки с сохранением лидирующих нулей.
3. Кэширование номеров рабочими процессами сервера. В клиент-серверном режиме работы кластер серверов 1С (процессы rphost) кэширует в оперативной памяти последний выданный номер. Если кэш зафиксировал последний номер некорректно, система будет выдавать ошибку вплоть до принудительного обновления.
4. Наличие скрытых или удаленных документов. Номер может быть занят помеченным на удаление объектом, документом другой организации или документом другого типа (если используется общий объект метаданных Нумератор).
5. Случайные символы и буквы. Проверьте, не была ли вместо цифры 0 случайно введена русская или латинская буква О/o, либо скрытые неразрывные пробелы, искажающие строковую сортировку.

Способ 1. Программное обновление нумерации объектов

Проанализируем базовый программный метод платформы. Если нумерация сбилась из-за кэша или ручного ввода номеров, администратор системы может выполнить принудительное обновление пространства номеров с помощью функции ОбновитьНумерациюОбъектов().

Посмотрим на пример вызова метода для конкретного вида документов:

// Обновление нумерации для конкретного типа документа
ОбъектыМетаданных = Новый Массив;
ОбъектыМетаданных.Добавить(Метаданные.Документы.РеализацияТоваровУслуг);
ОбновитьНумерациюОбъектов(ОбъектыМетаданных);

Если требуется обновить нумерацию абсолютно для всех объектов информационной базы, вызовем метод без передачи параметров:

// Полное обновление нумерации по всей информационной базе
ОбновитьНумерациюОбъектов();

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

Способ 2. Выравнивание разрядности и добавление лидирующих нулей

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

1. Проверьте длину реквизита Номер в конфигураторе (рекомендуемая длина — от 9 до 11 символов).
2. Если длина позволяет, вручную переименуйте последний документ, добавив дополнительный лидирующий ноль: вместо 099999 и 100000 задайте формат 0099999 и 0100000.
3. После ручной корректировки повторно выполните процедуру ОбновитьНумерациюОбъектов(). В этом случае механизм автонумерации четко распознает числовую часть и сможет корректно сформировать следующий номер 0100001.

Способ 3. Перезапуск рабочих процессов сервера

В ряде случаев в клиент-серверном режиме удерживаемый процессом rphost диапазон номеров не сбрасывается штатной процедурой. В такой ситуации разберем действия системного администратора:

1. Завершите сеансы пользователей в информационной базе.
2. Выполните перезапуск службы кластера серверов ragent (или перезапустите рабочие процессы кластера).
3. После перезапуска оперативная память очистится, и платформа заново рассчитает следующий номер на основании максимального записанного значения в базе данных.

Способ 4. Поиск конфликтов и проверка общего нумератора

Если ошибка сохраняется, выполним поиск скрытых документов-дублей:

1. Проверьте, не привязан ли документ к объекту метаданных Нумератор. Если общий нумератор используется несколькими видами документов, конфликтующий номер 099999 может принадлежать документу совершенно другого типа.
2. Откройте обработку Удаление помеченных объектов и выполните окончательное удаление всех удаленных документов данного вида, так как помеченные объекты продолжают резервировать свои номера в системе.