В стандартных конфигурациях 1С для большинства документов установлена периодичность нумерации «Год». Это означает, что с наступлением 1 января каждого нового года счетчик обнуляется, и первый созданный документ получает номер «1». Однако бизнес-процессы многих компаний требуют ведения сквозной нумерации, которая не прерывается десятилетиями. Попытка просто изменить настройки в конфигураторе часто приводит к техническим сбоям. В этой статье мы подробно разберем, почему возникают ошибки при смене периодичности и как реализовать сквозную нумерацию правильно и безопасно.
Когда мы открываем конфигуратор и меняем свойство документа Периодичность с значения «Год» на «Непериодический», платформа 1С инициирует реструктуризацию базы данных. Проанализируем ситуацию: в режиме «Год» уникальность номера контролируется только в рамках текущего календарного периода. Это значит, что в базе могут законно существовать документы «№1 от 2023 года» и «№1 от 2024 года».
Как только мы отключаем периодичность, платформа пытается создать единый индекс уникальности по полю Номер для всей таблицы документа за все года. Если в базе обнаруживаются документы с одинаковыми номерами (а они там точно есть, так как нумерация обнулялась ранее), возникает критическая ошибка: «Несовместимость таблиц» или сообщение о невозможности создания уникального индекса. Именно поэтому «штатный» метод изменения метаданных в уже работающей базе практически всегда неосуществим без полной перенумерации архива документов, что зачастую запрещено правилами учета.
Рассмотрим наиболее современный и безопасный метод — программное переопределение логики нумерации. Этот способ позволяет оставить в метаданных периодичность «Год» (чтобы не ломать структуру таблиц и индексов), но фактически заставить систему выдавать сквозные номера. Реализуем это через расширение конфигурации, чтобы не снимать основную конфигурацию с поддержки.
Нам потребуется перехватить событие ПриУстановкеНовогоНомера. Проанализируем алгоритм: нам нужно найти максимальный номер документа данного типа во всей базе данных, вне зависимости от даты, и прибавить к нему единицу. Посмотрим на пример кода, который можно разместить в модуле расширения:
&После("ПриУстановкеНовогоНомера")
Процедура Расш_ПриУстановкеНовогоНомера(СтандартнаяОбработка, Префикс)
// Отключаем стандартный механизм генерации номера
СтандартнаяОбработка = Ложь;
// Формируем запрос для поиска максимального номера в истории
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ 1
| Т.Номер КАК ПоследнийНомер
|ИЗ
| Документ.РеализацияТоваровУслуг КАК Т
|УПОРЯДОЧИТЬ ПО
| ПоследнийНомер УБЫВ";
РезультатЗапроса = Запрос.Выполнить();
Если Не РезультатЗапроса.Пустой() Тогда
Выборка = РезультатЗапроса.Выбрать();
Выборка.Следующий();
// Извлекаем числовую часть номера и увеличиваем на 1
// Здесь важно учитывать наличие префиксов организации/базы
ТекНомер = Выборка.ПоследнийНомер;
// Логика функции ОбщегоНазначения.ПолучитьСледующийНомер
ЭтотОбъект.Номер = РаботаСНомерамиОбъектов.СформироватьСледующийНомер(ТекНомер, Префикс);
Иначе
// Если документов еще нет, устанавливаем начальный номер
ЭтотОбъект.Номер = Префикс + "000000001";
КонецЕсли;
КонецПроцедуры
Важный нюанс: использование запроса УПОРЯДОЧИТЬ ПО Номер УБЫВ является критически важным для производительности. Платформа 1С оптимизирует такие запросы на уровне СУБД, используя существующие индексы, что позволяет мгновенно находить последний номер даже в таблицах с миллионами записей.
Если вы не хотите вносить изменения в программный код, существует «полуавтоматический» способ. Выясним, как работает встроенный механизм автонумерации: платформа ищет последний номер в текущем периоде (году) и инкрементирует его. Если 1 января вы создадите первый документ и вручную присвоите ему номер, следующий за последним номером прошлого года, система «подхватит» эту последовательность.
Разберем на примере:
Внимание: этот метод крайне нестабилен. Если кто-то из пользователей случайно удалит документ с «переходным» номером или собьет префикс, автонумерация может снова вернуться к единице. Кроме того, этот метод требует ежегодного ручного вмешательства администратора.
Проанализируем ситуацию, когда в базе данных включен жесткий контроль уникальности номеров. Если вы решили пойти по пути отключения периодичности (предварительно очистив дубли номеров в прошлых годах), вы можете столкнуться с тем, что обновление базы данных все равно будет выдавать ошибки. Это происходит из-за того, что свойство КонтрольУникальности в метаданных требует абсолютной чистоты данных в колонке Номер.
Если ваша задача — просто продолжить нумерацию, но при этом в базе объективно должны остаться старые документы с совпадающими номерами, единственным верным решением будет оставить периодичность «Год», но использовать программный код для подмены номера, как было описано в Методе 1. Это позволит «обмануть» систему: с точки зрения структуры данных это будут разные периоды, а с точки зрения пользователя — единая непрерывная лента номеров.
При переходе на сквозную нумерацию следует учитывать несколько технических факторов:
Подведем итог: наиболее корректным техническим решением задачи является использование расширений конфигурации с перехватом события ПриУстановкеНовогоНомера. Это сохраняет целостность типовой конфигурации, не требует сложной реструктуризации базы данных и гарантирует стабильную работу нумератора вне зависимости от смены календарного года.