Как автоматически заполнить поле Менеджер в реализации на основании заказа клиента

При работе в типовых конфигурациях 1С, таких как «Управление торговлей 11», «ERP» или «Комплексная автоматизация», пользователи часто сталкиваются с тем, что при создании Реализации товаров и услуг на основании Заказа клиента поле Менеджер (или Ответственный) заполняется текущим пользователем, который создает документ. Однако бизнес-процессы многих компаний требуют, чтобы ответственность за сделку сохранялась за тем сотрудником, который вел заказ. В этой статье мы подробно разберем, как автоматизировать этот процесс программными средствами.

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

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

Вариант 1: Простое решение через ОбработкаЗаполнения

Рассмотрим самый быстрый способ реализации задачи. Для этого нам необходимо открыть модуль объекта документа РеализацияТоваровУслуг и найти (или создать) процедуру ОбработкаЗаполнения. Эта процедура принимает параметр ДанныеЗаполнения, который содержит ссылку на документ-основание (в нашем случае — Заказ клиента).

Для реализации простейшей передачи значения пропишем следующий код:

Процедура ОбработкаЗаполнения(ДанныеЗаполнения, СтандартнаяОбработка)
    // Проверяем, что заполнение происходит на основании заказа
    Если ТипЗнч(ДанныеЗаполнения) = Тип("ДокументСсылка.ЗаказКлиента") Тогда
        // Устанавливаем менеджера из документа-основания
        ЭтотОбъект.Менеджер = ДанныеЗаполнения.Менеджер;
    КонецЕсли;
КонецПроцедуры

Разберем, что здесь происходит. Мы используем функцию ТипЗнч, чтобы убедиться, что документом-основанием является именно заказ. Это критически важно, так как реализация может создаваться и на основании других документов (например, соглашений или заданий на перевозку), где поля Менеджер может просто не быть, что приведет к ошибке.

Вариант 2: Использование расширений конфигурации (рекомендуемый способ)

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

1. Создадим новое расширение конфигурации.
2. Добавим в расширение документ РеализацияТоваровУслуг.
3. В модуле объекта документа создадим обработчик «После» для процедуры ОбработкаЗаполнения.

Проанализируем пример кода в расширении:

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

Использование аннотации &После гарантирует, что сначала выполнится вся типовая логика 1С (включая заполнение по умолчанию), а затем наш код перезапишет поле Менеджер нужным нам значением из заказа. Это самый безопасный и корректный путь для кастомизации системы.

Важные нюансы и проверки

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

1. Различие между реквизитами: В некоторых конфигурациях поле называется Ответственный, а в других — Менеджер. Перед написанием кода обязательно проверьте имя реквизита в метаданных (через Конфигуратор).
2. Создание по нескольким заказам: Выясним ситуацию, когда одна реализация создается сразу по нескольким заказам (через рабочее место «Накладные к оформлению»). В этом случае в ДанныеЗаполнения может передаваться не ссылка, а структура или массив. В такой ситуации логика «в лоб» не сработает. Нам потребуется проанализировать содержимое массива и решить: брать менеджера из первого заказа или оставить текущего пользователя.
3. Права доступа: Проанализируем права доступа. Если у пользователя, создающего реализацию, нет прав на просмотр того менеджера, который указан в заказе, система может выдать ошибку. Рекомендуется добавлять проверку на заполненность: ЗначениеЗаполнено(ДанныеЗаполнения.Менеджер).
4. Дополнительные реквизиты: Если поле «Менеджер» реализовано через механизм дополнительных сведений (БСП), то обращение через точку ДанныеЗаполнения.Менеджер не сработает. В этом случае потребуется обращаться к табличной части ДополнительныеРеквизиты документа-основания.

Альтернатива через механизм «Дополнительные отчеты и обработки»

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

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

Заключение и рекомендации

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