Часто в процессе разработки на платформе 1С:Предприятие 8 возникает необходимость адаптировать нумерацию документов под нужды бизнеса. Однако попытки программного вмешательства в процедуру ПриУстановкеНовогоНомера нередко приводят к ошибкам контроля уникальности. Давайте разберемся, почему это происходит и как правильно организовать нумерацию, не вступая в конфликт с механизмами платформы.
При использовании расширений разработчики часто сталкиваются с тем, что их код ПриУстановкеНовогоНомера не учитывает логику периодичности, заданную в метаданных. Важно понимать, что контроль уникальности — это встроенная проверка платформы, которая срабатывает при записи объекта в базу данных. Когда вы принудительно задаете номер, платформа сравнивает его с уже существующими значениями в разрезе установленной периодичности (например, «В пределах года»). Если ваш алгоритм не учитывает структуру префиксации и год, платформа «видит» конфликт, даже если номер относится к другому периоду.
Основные причины проблем с кодом:
Дата документа, работают нестабильно. Если документы создаются «задним числом», логика поиска последнего номера ломается, так как номер может оказаться меньше уже существующих в базе.ПрефиксацияОбъектовКлиентСервер, что приводит к разрыву цепочки нумерации.Рассмотрим несколько подходов, которые помогут вам избежать ошибок и обеспечить корректную работу нумерации.
Самый надежный способ — позволить платформе самой управлять нумерацией. Если бизнес требует продолжения нумерации с определенного числа в новом году, не нужно писать сложный код. Достаточно создать в начале года первый документ с нужным вам номером.
Этот подход полностью исключает риск дублирования и ошибки «такой номер уже существует», так как вся логика остается на уровне платформы.
Если требуется жесткое разделение нумерации по годам для нескольких организаций, оптимальным решением будет использование префикса года. Вы можете настроить префиксацию так, чтобы каждый год документы начинались с нового префикса (например, «БП24-», «БП25-»). В таком случае периодичность будет соблюдаться автоматически, а контроль уникальности будет работать внутри каждого префикса независимо.
Для крупных внедрений, где ручная установка первого номера неудобна, можно настроить регламентное задание. Давайте разберем пример логики для такого задания:
// Пример логики регламентного задания для установки начала нумерации
Процедура УстановкаНачальногоНомераГода()
// Задание выполняется 1 раз в год 01.01 в 00:00
// Выполняем создание технического документа или установку параметров
// для каждой организации через метаданные или регистр сведений
КонецПроцедуры
При написании собственного кода обработки события ПриУстановкеНовогоНомера часто допускаются критические ошибки. Например, использование запросов, сортирующих документы по Дата и выбирающих ПЕРВЫЕ 1, крайне опасно. Если у вас документы создаются вне хронологического порядка (задним числом), ваш запрос всегда будет выбирать неверный «последний» документ, что приведет к дублям номеров.
Рекомендации для разработчика:
Таким образом, лучший способ решения вашей задачи — отказаться от жесткого переопределения номера через ПриУстановкеНовогоНомера и перейти к использованию префиксов или штатного механизма инициализации первого номера года. Это сделает вашу конфигурацию стабильной, а работу пользователей — предсказуемой.