Почему программно созданный договор не подставляется в документы и как работать с реквизитами формы в расширениях 1С

Программист 1С v8.3 (Управляемые формы) 1С:Управление торговлей Управленческий учет Торговля и дистрибуция
← На главную

При разработке в среде 1С:Предприятие 8.3 программисты часто сталкиваются с ситуацией, когда объект (например, ДоговорКонтрагента), созданный программно, ведет себя иначе, чем созданный интерактивно через интерфейс. В этой статье мы разберем конкретный кейс из практики работы с УТ 11.5: почему обращение к реквизиту формы из расширения не дает результата при программном создании объекта и какие скрытые механизмы мешают автоматической подстановке договора в заказы клиентов.

Реквизит формы против реквизита объекта: в чем принципиальная разница?

Рассмотрим ситуацию, когда в форме договора существует поле РежимНалогообложения. Программист заимствует его в расширение, но при программном создании элемента справочника не может к нему обратиться. Давайте выясним причину этого поведения.

В платформе 1С существует четкое разделение между данными объекта (которые хранятся в таблицах базы данных) и данными формы (которые существуют только в контексте открытого окна). Реквизит РежимНалогообложения в типовых конфигурациях часто является именно реквизитом формы. Если у такого реквизита установлено свойство «Сохраняемые данные», платформа сохраняет его значения не в таблицу справочника, а в системное хранилище настроек.

Проанализируем последствия: когда мы пишем код Справочники.ДоговорыКонтрагентов.СоздатьЭлемент(), мы работаем с объектом базы данных. Форма при этом не инициализируется, ее контекст не создается, а значит, и реквизиты формы физически не существуют в памяти. Попытка обратиться к ним из модуля объекта или через переменную созданного элемента закономерно приведет к ошибке или отсутствию данных.

Как правильно заимствовать реквизиты в расширение

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

  1. Откроем дерево объектов основной конфигурации и найдем нужную форму.
  2. Нажмем правой кнопкой мыши и выберем «Добавить в расширение».
  3. Перейдем в расширение, откроем редактор формы.
  4. На вкладке «Реквизиты» найдем нужный нам элемент. Обратите внимание на пиктограмму в виде «коряги» (разветвления) — она означает, что объект успешно заимствован.
  5. Если реквизит не подсвечен как заимствованный, расширение не будет «видеть» его на уровне компиляции кода, даже если визуально он присутствует в списке.

Почему договор не подставляется автоматически в Заказ клиента?

Часто программисты полагают, что проблема в незаполненном «налогообложении», но на практике в УТ 11.5 механизмы фильтрации договоров гораздо строже. Рассмотрим ситуацию: договор создан программно, записан, но в ЗаказКлиента он не подставляется, пока мы не зайдем в него интерактивно и не нажмем «Провести и закрыть».

Выясним причину. При интерактивном сохранении срабатывают обработчики формы (ПриЗаписиНаСервере, ПослеЗаписиНаСервере), которые могут дозаполнять скрытые реквизиты объекта, критически важные для системы. Проанализируем основные параметры, по которым УТ 11.5 фильтрует подходящие договоры:

Использование истории изменений для поиска проблемы

Если программно созданный объект ведет себя «неправильно», воспользуемся проверенным методом отладки — сравнением версий через историю изменений. Рассмотрим алгоритм действий:

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

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

Пример правильного программного создания договора

Посмотрим на пример кода, который учитывает важные параметры для корректной работы в УТ 11.5. Мы не пытаемся заполнить реквизиты формы, а фокусируемся на обязательных реквизитах объекта:


НовыйДоговор = Справочники.ДоговорыКонтрагентов.СоздатьЭлемент();
НовыйДоговор.Заполнить(Неопределено); // Инициализация стандартных значений

НовыйДоговор.Наименование = "Основной договор программный";
НовыйДоговор.Организация  = СсылкаНаОрганизацию;
НовыйДоговор.Контрагент   = СсылкаНаКонтрагента;
НовыйДоговор.Партнер      = СсылкаНаПартнера;

// Обязательные параметры для УТ 11.5:
НовыйДоговор.Статус = Перечисления.СтатусыДоговоровКонтрагентов.Действует;
НовыйДоговор.ВалютаВзаиморасчетов = СсылкаНаВалюту; // Важно!
НовыйДоговор.ТипДоговора = Перечисления.ТипыДоговоров.СПокупателем;

// Если нужно программно эмулировать налогообложение,
// ищем, в какой реальный реквизит объекта или регистра оно записывается.
// В типовых это может зависеть от УчетнойПолитики организации.

НовыйДоговор.Записать();

Подведем итоги

Разберем основные выводы нашего исследования:

  1. Реквизиты формы недоступны при программном создании объекта. Если вам нужно заполнить данные, которые на форме отображаются через сохраняемые реквизиты, ищите механизмы их хранения в ХранилищеОбщихНастроек или связанных регистрах сведений.
  2. Проверяйте заполнение валюты. В 90% случаев автоматическая подстановка договора в 1С ломается из-за несоответствия валют.
  3. Используйте метод Заполнить(). Это позволяет платформе отработать логику модуля объекта ОбработкаЗаполнения, что минимизирует количество «пустых» важных полей.
  4. Контролируйте заимствование в расширении. Всегда проверяйте наличие «коряги» у реквизита в дереве объектов расширения, прежде чем обращаться к нему в коде.

Таким образом, понимание жизненного цикла формы и структуры данных объекта позволяет избежать ошибок при программной работе с документами и справочниками в расширениях 1С.

← На главную