Многие технические специалисты сталкиваются с ситуацией, когда в системе 1С:Предприятие 8.3 внезапно нарушается последовательность номеров документов. Например, после номера ИП00006396 следующий документ неожиданно получает номер ИП00007001. Самое неприятное в этой ситуации то, что даже после ручного исправления номера на корректный (ИП00006397), система все равно продолжает предлагать ошибочное продолжение — ИП00007002. Рассмотрим подробнее, почему так происходит и как эффективно решить эту проблему.
Разберем причину такого поведения платформы. Начиная с версии 8.3, 1С использует механизм кэширования номеров на стороне сервера приложений. Это технологическое решение направлено на повышение производительности: чтобы не обращаться к базе данных при создании каждого нового документа, сервер «бронирует» для себя диапазон номеров (обычно по 10 или более штук).
Проанализируем ситуацию: как только в базе данных возник документ с номером ИП00007001, рабочий процесс сервера 1С (rphost) зафиксировал его как последний использованный. В памяти сервера уже подготовлен следующий свободный номер — ИП00007002. Исправление номера в самом документе или даже его удаление не очищает оперативную память сервера. Именно поэтому простая перезагрузка клиентского приложения «Альфа-Авто» или другой конфигурации не дает результата — кэш продолжает жить в серверном процессе.
Прежде чем сбрасывать кэш, нам необходимо убедиться, что в базе данных действительно нет документов, которые провоцируют прыжок нумерации. Выясним причину появления ошибочного номера. Часто это случается из-за человеческого фактора: пользователь мог случайно изменить номер вручную или создать документ в «далеком будущем» (например, 2089 год).
Для поиска такого документа рекомендуется использовать консоль запросов. Проанализируем последние записи с помощью несложного запроса:
ВЫБРАТЬ ПЕРВЫЕ 10
ЗаказНаряд.Ссылка,
ЗаказНаряд.Номер,
ЗаказНаряд.Дата
ИЗ
Документ.ЗаказНаряд КАК ЗаказНаряд
УПОРЯДОЧИТЬ ПО
ЗаказНаряд.Номер УБЫВ
Если этот запрос покажет документ с номером ИП00007001, его необходимо либо удалить, либо исправить его номер на правильный в соответствии с текущей последовательностью. Если же документов с большими номерами в базе уже нет, а система все равно предлагает 7002, значит, проблема исключительно в кэше сервера.
Для принудительного сброса закэшированных номеров и синхронизации счетчика платформы с реальными данными в базе существует специальный метод — ОбновитьНумерациюОбъектов. Этот метод заставляет сервер пересчитать текущий максимальный номер, исходя из фактически записанных объектов.
Рассмотрим, как его применить. Поскольку это программный метод, его нужно выполнить либо через консоль кода (внешнюю обработку), либо создав небольшую одноразовую обработку. Посмотрим на пример кода для вызова этого метода:
Вариант 1. Глобальное обновление (для всех типов документов):
ОбновитьНумерациюОбъектов();
Этот способ прост, но в больших базах данных может занять некоторое время, так как система будет проверять все типы метаданных.
Вариант 2. Точечное обновление (рекомендуется):
Если мы точно знаем, что проблема возникла только в документе ЗаказНаряд, лучше вызвать метод только для него. Это быстрее и безопаснее.
ОбновитьНумерациюОбъектов(Метаданные.Документы.ЗаказНаряд);
Если вы не являетесь разработчиком и у вас нет под рукой готовой консоли кода, выполним следующие шаги:
Проанализируем ситуацию глубже. Иногда ОбновитьНумерациюОбъектов помогает лишь временно, если не устранена фундаментальная причина. Обратите внимание на следующие моменты:
Подведем итог: в платформе 8.3 ручного исправления документа недостаточно из-за серверного кэширования. После того как вы нашли и исправили ошибочный номер в базе данных, обязательно выполните метод ОбновитьНумерациюОбъектов.
Важно помнить, что этот метод делает невалидными все номера, которые были выданы системой, но еще не записаны в базу на момент вызова. Поэтому процедуру восстановления лучше проводить в моменты низкой активности пользователей или монопольно.