Можно ли использовать метод ОбновитьНумерациюОбъектов в регулярных обработках 1С?

← На главную

Часто при автоматической загрузке документов, например, заказов покупателей, система начинает выдавать ошибки нарушения уникальности номеров: часть документов создается корректно, а часть отклоняется. В таких ситуациях у программистов возникает соблазн вставить вызов ОбновитьНумерациюОбъектов непосредственно в код обработки загрузки. Однако Синтакс-помощник предупреждает: данный метод разрешено вызывать только администратору системы. Давайте подробно разберем ситуацию, выясним причину такого ограничения и проанализируем, к чему приведет использование этого метода на постоянной основе.

Как работает нумерация объектов "под капотом"

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

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

Критические риски для многопользовательской работы

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

Когда вы вызываете метод обновления нумерации, все выданные, но еще не записанные в базу номера становятся невалидными. Их уникальность больше не гарантируется. Рассмотрим на примере:

Другой пользователь (или фоновое задание) начинает создавать документ. Система выдает ему новый номер из кэша.
Пользователь заполняет документ. Номер уже "занят" в кэше, но физически документ еще не записан в базу.
В этот момент срабатывает ваша обработка и вызывает ОбновитьНумерациюОбъектов. Кэш очищается.
Ваша обработка запрашивает новый номер. Так как документа другого пользователя в базе еще нет, 1С выдает вашей обработке тот же самый номер, который ранее был выдан пользователю.
В итоге, кто запишет документ вторым, получит ошибку уникальности или перезапишет данные, что приведет к катастрофической путанице (например, при отправке писем с номерами накладных).

Именно поэтому использование данного метода требует прав администратора и осознанного, разового применения при монопольной (или близкой к ней) работе.

Истинные причины сбоев нумерации

Проанализируем ситуацию дальше: почему номера вдруг "заканчиваются"? Обычно нумерация ломается не из-за глюков платформы, а из-за нарушения формата номера в уже созданных документах.

Алгоритм автонумерации берет максимальный номер в базе как строку и пытается увеличить его числовую часть. Если кто-то из пользователей или некорректно написанный код вручную удалил лидирующие нули (например, записал номер 1234 вместо 000001234), платформа попытается продолжить нумерацию от этого короткого значения. Когда длина доступной строки исчерпывается (например, достигается номер 9999), система физически не может выдать номер 10000 без изменения длины и начинает сыпать ошибками при попытке создать новые заказы.

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

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

1. Устранение первопричины (Поиск битых номеров)

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

2. Использование метода УстановитьНовыйНомер

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


НовыйДокумент = Документы.ЗаказПокупателя.СоздатьДокумент();
НовыйДокумент.Дата = ТекущаяДата();
// ... заполнение реквизитов ...
НовыйДокумент.УстановитьНовыйНомер();
НовыйДокумент.Записать();

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

3. Включение привилегированного режима (если сброс всё же необходим разово)

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


УстановитьПривилегированныйРежим(Истина);
ОбновитьНумерациюОбъектов(Метаданные.Документы.ЗаказПокупателя);
УстановитьПривилегированныйРежим(Ложь);

Важно: использование УстановитьПривилегированныйРежим во внешних обработках ограничено настройками безопасности (безопасный режим). Данный подход рекомендуется применять только во встроенных серверных процедурах.

4. Использование типовых обработок

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

Подводя итог: постоянное применение метода обновления нумерации не устранит ошибку в логике работы базы или обработки. Лечите причину (некорректные номера в базе), а не симптомы.