Как исправить сбившуюся сквозную нумерацию заявок и расчетно-платежных документов в 1С?

← На главную

Сбой автонумерации документов — распространенная проблема, с которой сталкиваются пользователи и администраторы 1С. Ситуация часто развивается по типовому сценарию: пользователь вручную редактирует номер документа, убирает ведущие лидирующие нули (например, вместо номера 0000000123 записывает 123), после чего программа продолжает инкрементировать укороченный номер до значения 999 и полностью блокирует создание новых документов с сообщением о невозможности присвоить уникальный номер. Ситуация осложняется, когда для группы связанных документов (например, заявки на кассовый расход, заявки на возврат, заявки на получение наличных денег) назначен единый сквозной нумератор. Разберем детально механизм возникновения этой ошибки и пошаговые методы ее устранения.

Почему сбивается нумерация и происходит остановка на номере 999

Проанализируем логику работы платформы 1С при формировании номеров:

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

Оценка рисков перед началом исправления

Прежде чем приступать к исправлению номеров, обязательно выполним подготовительные действия и проанализируем смежные бизнес-процессы:

Создание резервной копии. Любые групповые манипуляции с номерами документов необходимо сначала протестировать на копии информационной базы.
Проверка выгрузок в казначейство и банк. Если заявки за прошлые дни уже были успешно отправлены в органы Федерального казначейства или банковские системы и по ним получены протоколы исполнения, менять их номера в учетной базе категорически нельзя. Это приведет к расхождениям между данными учета и банковскими выписками. В такой ситуации исправляют только те документы, которые еще не передавались во внешние системы.
Контроль узлов РИБ. В распределенных информационных базах изменение номеров уже синхронизированных документов вызовет регистрацию изменений и повторную отправку данных в узлы, что может привести к коллизиям.

Способ 1. Ручное исправление через журнал документов

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

Разберем по шагам порядок действий:

Открываем общий журнал документов (например, «Журнал расчетно-платежных документов»). В общем журнале все документы сквозного нумератора отображаются в едином хронологическом списке.
Находим последний документ с корректным номером, содержащим правильный префикс и все лидирующие нули (например, АА00-000456).
Последовательно открываем каждый ошибочный документ, начиная с самого раннего по дате, и вручную вводим номер в строгом соответствии с шаблоном (например, АА00-000457, АА00-000458 и так далее).
Записываем исправленные документы.

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

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

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


// Создадим процедуру для исправления номеров группы документов
Процедура ИсправитьСквознуюНумерацию()
    
    // Получаем документы, входящие в общий нумератор, за нужный период
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |    Док.Ссылка КАК Ссылка,
        |    Док.Дата КАК Дата,
        |    Док.Номер КАК Номер
        |ИЗ
        |    Документ.ЗаявкаНаКассовыйРасход КАК Док
        |ГДЕ
        |    Док.Дата МЕЖДУ &ДатаНачала И &ДатаКонца
        |
        |ОБЪЕДИНИТЬ ВСЕ
        |
        |ВЫБРАТЬ
        |    ДокВозврат.Ссылка,
        |    ДокВозврат.Дата,
        |    ДокВозврат.Номер
        |ИЗ
        |    Документ.ЗаявкаНаВозврат КАК ДокВозврат
        |ГДЕ
        |    ДокВозврат.Дата МЕЖДУ &ДатаНачала И &ДатаКонца
        |
        |УПОРЯДОЧИТЬ ПО
        |    Дата ВОЗРАСТАНИЕ";
        
    Запрос.УстановитьПараметр("ДатаНачала", НачалоДня(Дата("20240101")));
    Запрос.УстановитьПараметр("ДатаКонца", КонецДня(ТекущаяДата()));
    
    Результат = Запрос.Выполнить().Выгрузить();
    
    // Начальный порядковый номер для восстановления
    БазовыйСчетчик = 457;
    ПрефиксНомера = "АА00-";
    
    Для Каждого Стр Из Результат Цикл
        
        // Формируем строковый номер фиксированной длины с лидирующими нулями
        ФорматированныйНомер = ПрефиксНомера + Формат(БазовыйСчетчик, "ЧЦ=6; ЧВН=; ЧГ=0");
        
        ДокОбъект = Стр.Ссылка.ПолучитьОбъект();
        ДокОбъект.Номер = ФорматированныйНомер;
        
        Попытка
            // Записываем документ в режиме проведения или обычной записи
            Если ДокОбъект.Проведен Тогда
                ДокОбъект.Записать(РежимЗаписиДокумента.Проведение);
            Иначе
                ДокОбъект.Записать(РежимЗаписиДокумента.Запись);
            КонецЕсли;
            
            БазовыйСчетчик = БазовыйСчетчик + 1;
        Исключение
            Сообщить("Ошибка при записи документа: " + Стр.Ссылка + " - " + ОписаниеОшибки());
        КонецПопытки;
        
    КонецЦикла;
    
КонецПроцедуры

Обязательный шаг: Сброс кэша нумератора через ОбновитьНумерациюОбъектов

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

Разберем варианты использования этого метода:


// Вариант 1. Принудительный сброс кэша для всех объектов информационной базы
ОбновитьНумерациюОбъектов();

// Вариант 2. Сброс кэша по конкретному общему нумератору
МассивНумераторов = Новый Массив;
МассивНумераторов.Добавить(Метаданные.Нумераторы.РасчетноПлатежныеДокументы);
ОбновитьНумерациюОбъектов(МассивНумераторов);

Вызов метода без параметров очищает кэш нумерации абсолютно для всех справочников, документов и нумераторов базы данных. Данное действие можно выполнить через внешнюю обработку, консоль кода или обработку «Групповое изменение реквизитов».

Профилактика повторных сбоев

Чтобы исключить повторение ситуации в будущем, применим административные и программные ограничения:

Типовые настройки запрета редактирования номеров. В конфигурациях на базе Библиотеки стандартных подсистем (БСП) перейдем в раздел администрирования и активируем флаг запрета ручного редактирования номеров документов для пользователей.
Ограничение прав на уровне ролей. Исключим у пользователей с типовыми правами право интерактивного изменения номера документов.
Подписка на событие ПередЗаписью. При необходимости строгого контроля программно проверяем соответствие длины номера и структуры маски при записи документа, блокируя сохранение номеров с обрезанными нулями.