Каждый практикующий специалист по 1С или бухгалтер рано или поздно сталкивается с проблемой сбившейся автонумерации — для её решения подойдёт обработка настройки префиксов и восстановления нумерации. Типичный сценарий выглядит следующим образом: в информационной базе были созданы документы с номерами 1, 3 и 5. Ответственный пользователь решил привести базу в порядок и вручную переименовал их, выстроив красивую последовательность: 1, 2 и 3. Однако при попытке создать следующий (четвертый по счету) документ система почему-то упорно предлагает присвоить ему номер 6 вместо логичного номера 4.
В этой статье мы подробно разберем, почему так происходит, как устроена логика автонумератора платформы «1С:Предприятие 8.3», и рассмотрим несколько эффективных способов решения этой проблемы — от быстрого программного сброса кэша до использования встроенных интерактивных инструментов конфигурации «1С:Бухгалтерия 3.0» (БП 3.0).
Прежде чем переходить к активным действиям, давайте проанализируем, почему ручное переименование документов не приводит к мгновенному исправлению автонумерации. Дело в том, что в целях повышения производительности платформа 1С не обращается к таблице базы данных для поиска максимального номера каждый раз, когда пользователь нажимает кнопку «Создать». Вместо этого на стороне сервера приложений функционирует специальный внутренний механизм — кэш нумератора.
Когда в системе создается новый документ, сервер считывает последний выданный номер, увеличивает его на единицу, фиксирует это значение в памяти (кэше) и выдает его новому объекту. Если пользователь вручную меняет номера (например, заменяет цепочку «1, 3, 5» на «1, 2, 3»), для платформы максимальным использованным номером в текущем периоде все равно остается «5» (даже если физически документа с номером 5 в базе больше нет). Кэш сервера «помнит» число 5, поэтому для следующего документа рассчитывает номер как 5 + 1 = 6.
В старых редакциях конфигураций (например, в «1С:Бухгалтерия 2.0» на обычных формах) существовала специализированная обработка «Настройка стратегии редактирования номеров объектов», которая позволяла централизованно управлять правами на изменение номеров. В БП 3.0 на управляемых формах этой настройки больше нет. Изменить номер может любой пользователь с правами на редактирование документа, предварительно согласившись с предупреждением системы: «Номер заполняется при записи автоматически. Продолжить редактирование?». Именно это упрощение часто становится причиной хаоса в нумерации документов.
Если нам необходимо быстро и безболезненно сбросить внутренний кэш автонумерации для конкретного типа документов или для всей базы в целом, лучшим решением будет использование метода глобального контекста ОбновитьНумерациюОбъектов(). Этот метод заставляет платформу очистить текущий кэш в оперативной памяти сервера, заново просканировать физическую таблицу базы данных, найти реально существующий максимальный номер и в дальнейшем отталкиваться именно от него.
Рассмотрим синтаксис данного метода:
ОбновитьНумерациюОбъектов(<ОписаниеМетаданных>)
В качестве параметра метод может принимать массив описаний метаданных или одно описание метаданных конкретного типа объектов (например, документов или справочников). Если вызвать метод без параметров, система принудительно обновит кэш по абсолютно всем объектам конфигурации. Обратите внимание, что данный метод выполняется исключительно на стороне сервера и требует прав Администратора.
Давайте посмотрим на практические примеры использования этого метода в коде. Для запуска кода вы можете воспользоваться внешней обработкой, консолью кода (поможет консоль кода для выполнения программных команд) или встроенным групповым изменением реквизитов (в режиме выполнения произвольного алгоритма).
Если нам нужно обновить нумерацию абсолютно всех документов и справочников в базе данных, мы используем вызов без параметров:
ОбновитьНумерациюОбъектов();
Если проблема возникла локально, например, только в документах реализации товаров и услуг, крайне рекомендуется обновлять кэш точечно. Это сэкономит системные ресурсы и не затронет другие процессы. Разберем пример кода для выборочного обновления:
МассивМетаданных = Новый Массив;
МассивМетаданных.Добавить(Метаданные.Документы.РеализацияТоваровУслуг);
МассивМетаданных.Добавить(Метаданные.Документы.ПоступлениеТоваровУслуг);
ОбновитьНумерациюОбъектов(МассивМетаданных);
После выполнения данного кода платформа заново проанализирует физические номера существующих документов реализации и поступления, найдет актуальный максимум и запишет его в кэш. В нашем примере с номерами 1, 2, 3 новым максимальным номером станет 3, а следующий документ гарантированно получит корректный номер 4.
Далеко не все пользователи имеют навыки программирования или доступ к консоли кода. Для этой задачи есть экспресс-проверка состояния базы и исправления нумерации. Разработчики «1С:Бухгалтерия 3.0» предусмотрели этот момент и встроили в конфигурацию штатный интерактивный инструмент для исправления нумерации самых критически важных документов (кассовых документов ПКО/РКО и счетов-фактур), где хронология жестко контролируется законодательством.
Давайте разберем по шагам, как запустить автоматическую перенумерацию:
Для всех остальных видов документов, которые не охвачены экспресс-проверкой (например, «Акты выполненных работ», «Накладные», «Требования-накладные»), мы можем применить стандартную административную обработку «Групповое изменение реквизитов» (удобно через групповая обработка для массового исправления номеров). Этот способ требует предельной концентрации и аккуратности.
Рассмотрим пошаговый алгоритм работы с обработкой:
Реализация товаров и услуг).Номер.Проводя ручную или автоматическую корректировку номеров, мы обязательно должны помнить о структуре номера в современных конфигурациях 1С. В БП 3.0 номер любого документа имеет строго заданный формат, который выглядит следующим образом: ХХХХ-000000.
Разберем эту структуру подробнее:
БП01-) — это префиксы. Они включают в себя префикс конкретной организации и префикс распределенной информационной базы (если настроен обмен данными).Основная ошибка пользователей заключается в том, что при ручном редактировании они удаляют эти лидирующие нули. Например, вместо номера ОБ00-000025 записывают просто ОБ00-25 или вовсе 25.
Посмотрим, к каким последствиям это приводит. Платформа анализирует длину измененного номера. Если длина строки уменьшилась, автонумератор автоматически сокращает разрядность для всех последующих документов. Как только система дойдет до конца этой короткой разрядности (например, мы ввели номер 99 без нулей, и следующим должен быть 100, который физически не помещается в усеченный шаблон), программа заблокирует создание новых документов и начнет выдавать критическую ошибку: «Значение поля "Номер" не уникально».
Чтобы исправить подобную ситуацию, нам придется вручную найти в списке все документы текущего периода, у которых была нарушена длина номера, и кропотливо дописать недостающие лидирующие нули. Только после восстановления правильной длины номера и последующего вызова метода ОбновитьНумерациюОбъектов() система вернется в штатный режим автоматической генерации номеров — для контроля качества учёта есть мониторинг ошибок в учете с уведомлением в Telegram.