Как реализовать автозаполнение реквизитов при создании документа в 1С

В процессе разработки на платформе 1С:Предприятие часто возникает задача автоматического заполнения определенных полей документа при его создании. Например, менеджеру нужно, чтобы при формировании нового «Заказа клиента» статус подготовки автоматически принимал значение «Ожидает подготовки». Это минимизирует количество ошибок, связанных с человеческим фактором, и ускоряет работу пользователей. В этой статье мы подробно разберем, какими способами можно добиться этой цели, проанализируем разницу между ними и выясним, какой подход будет наиболее правильным с точки зрения архитектуры системы.

Вариант 1. Использование свойства «Значение заполнения» в метаданных

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

Разберем этот процесс по шагам:

1. Откроем конфигуратор и найдем нужный нам документ (например, ЗаказКлиента).
2. Перейдем на закладку Данные и выберем интересующий нас реквизит (например, СтатусПодготовки).
3. В палитре свойств найдем строку Значение заполнения.
4. Нажмем на кнопку выбора и укажем конкретное значение из справочника, которое должно подставляться по умолчанию.

Важный нюанс: Этот механизм срабатывает автоматически при интерактивном создании нового объекта пользователем (когда он нажимает кнопку «Создать» в списке). Однако стоит учитывать, что при программном создании документа это значение может не заполниться, если разработчик явно не вызовет метод Заполнить(). Этот способ идеально подходит для простых случаев, когда логика заполнения не зависит от внешних условий.

Вариант 2. Программное заполнение в процедуре «ОбработкаЗаполнения»

Проанализируем более гибкий подход — использование обработчика события в модуле объекта. Этот метод позволяет реализовать сложную логику: например, устанавливать статус в зависимости от того, какая организация выбрана, какой текущий пользователь создает документ или на основании какого другого документа создается заказ. Для анализа порядка срабатывания процедур при создании и заполнении объектов можно использовать инструмент для изучения последовательности вызова событий 1С.

Процедура ОбработкаЗаполнения располагается в модуле объекта документа. Выясним, как правильно написать код:

Процедура ОбработкаЗаполнения(ДанныеЗаполнения, ТекстЗаполнения, СтандартнаяОбработка)
	
	// Проверяем, что это новый документ, а не создание на основании
	Если ДанныеЗаполнения = Неопределено Тогда
		// Устанавливаем значение статуса по умолчанию
		// Предположим, что СтатусПодготовки — это ссылка на справочник
		СтатусПодготовки = Справочники.СтатусыПодготовки.ОжидаетПодготовки;
	КонецЕсли;
	
КонецПроцедуры

Разберем, что здесь происходит. Параметр ДанныеЗаполнения содержит объект, на основании которого создается наш документ. Если он пустой (Неопределено), значит, пользователь просто создал новый документ «с нуля». В этом случае мы обращаемся к предопределенному элементу справочника и записываем его в наш реквизит.

Вариант 3. Использование подписки на события для типовых конфигураций

Рассмотрим ситуацию, когда вы работаете с типовой конфигурацией (например, УТ 11, ERP или Бухгалтерия предприятия), которая находится на поддержке. Прямое изменение модуля объекта крайне нежелательно, так как это затруднит последующие обновления программы. В таких случаях мы используем Подписки на события.

Алгоритм реализации через подписку:

1. Создадим новый общий модуль (например, _РаботаСДокументами_Кастом) и установим в его свойствах флаг Сервер.
2. Создадим в конфигураторе объект Подписка на событие.
3. В свойстве Источник выберем ДокументОбъект.ЗаказКлиента.
4. В свойстве Событие выберем ОбработкаЗаполнения.
5. В качестве Обработчика выберем нашу процедуру в общем модуле.

Пример кода в общем модуле будет выглядеть так:

Процедура ПриОбработкеЗаполненияЗаказаКлиента(Источник, ДанныеЗаполнения, ТекстЗаполнения, СтандартнаяОбработка) Экспорт
	
	// Источник — это и есть наш объект документа
	Если ДанныеЗаполнения = Неопределено Тогда
		Источник.СтатусПодготовки = Справочники.СтатусыПодготовки.ОжидаетПодготовки;
	КонецЕсли;
	
КонецПроцедуры

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

Вариант 4. Архитектурный подход: Регистр сведений вместо реквизита

В ходе обсуждения на форуме эксперты затронули важную тему: стоит ли вообще хранить статус в самом документе? Рассмотрим аргументы в пользу использования Регистра сведений для хранения статусов подготовки.

Проблема изменения реквизитов: Если вы храните статус в документе, то для его изменения менеджеру придется открывать документ и перепроводить его. Если документ «тяжелый» (сотни строк) или относится к закрытому периоду, это вызовет массу проблем: от блокировок базы до искажения данных в прошлых месяцах.

Преимущества регистра сведений:

• История изменений: Если сделать регистр периодическим, мы сможем отследить, когда заказ перешел из одного статуса в другой и кто это сделал.
• Скорость: Запись в регистр происходит мгновенно и не требует пересчета итогов по всему документу.
• Права доступа: Можно разрешить менеджерам менять статусы в регистре, но запретить редактировать уже проведенные документы.

Если вы все же решили использовать регистр, то автозаполнение будет происходить не в документе, а путем создания записи в регистре в момент первого проведения документа. Для этого используется процедура ОбработкаПроведения.

Сравнение методов: «Значение заполнения» vs «Обработка заполнения»

Многие начинающие разработчики задаются вопросом: в чем принципиальная разница, если результат в интерфейсе выглядит одинаково? Выясним ключевые отличия:

1. Статичность против динамики. Свойство в метаданных — статично. Оно всегда подставляет одно и то же. Процедура в коде позволяет вычислять значение программно.

2. Программное создание. Если вы создаете документ кодом (через обмен данными или обработку), свойство метаданных сработает только при явном вызове Документ.Заполнить(). Обработчик ОбработкаЗаполнения также вызывается этим методом, но он дает больше контроля над тем, что именно заполнять при разных сценариях загрузки.

3. Ввод на основании. Свойство метаданных часто игнорируется при вводе на основании, так как приоритет отдается данным из документа-основания. В коде ОбработкаЗаполнения вы можете четко прописать: «Если создаем на основании счета — статус такой, если просто создаем — статус сякой».

Рекомендации по реализации в современных конфигурациях

Посмотрим на ситуацию с точки зрения современных стандартов разработки (БСП — Библиотека стандартных подсистем). Если ваша задача — добавить новый статус, который не предусмотрен типовым решением, рекомендуется использовать Расширения конфигурации.

В расширении вы можете добавить свой реквизит к документу и перехватить процедуру заполнения с помощью аннотации &После. Это позволит вашей логике работать «поверх» стандартной, не мешая обновлению основной конфигурации.

Пример использования расширения:

&После("ОбработкаЗаполнения")
Процедура Расш1_ОбработкаЗаполнения(ДанныеЗаполнения, ТекстЗаполнения, СтандартнаяОбработка)
	
	Если ДанныеЗаполнения = Неопределено Тогда
		// Этот код выполнится ПОСЛЕ типового заполнения
		ЭтотОбъект.СтатусПодготовки = Справочники.СтатусыПодготовки.ОжидаетПодготовки;
	КонецЕсли;
	
КонецПроцедуры

Подведем итог. Для быстрой реализации простых задач в самописных базах достаточно свойства Значение заполнения в конфигураторе. Для типовых решений и сложной логики следует выбирать Подписки на события или Расширения. А если важна история изменений статуса без лишних перепроведений — смотрите в сторону Регистров сведений.