Почему не заполняется реквизит при создании документа на основании и как найти «скрытую» логику заполнения?

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

При разработке в крупных типовых конфигурациях, таких как 1С:Управление торговлей 11.4, ERP 2.5 или Комплексная автоматизация, программисты часто сталкиваются с ситуацией, когда стандартные механизмы заполнения документов ведут себя неочевидно. Рассмотрим типичную проблему: при создании «Реализации товаров и услуг» на основании «Заказа клиента» один кастомный реквизит заполняется успешно, а второй — созданный аналогично — остается пустым. При этом поиск по коду не дает результатов, а привычные точки останова в модуле объекта не фиксируют момент заполнения.

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

Анализ процедуры ОбработкаЗаполнения в модуле объекта

Первым делом мы всегда обращаемся к модулю объекта документа. Именно здесь находится стандартный обработчик ОбработкаЗаполнения, который вызывается платформой при создании нового объекта на основании другого. Проанализируем типичную структуру этого обработчика в УТ 11:


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

КонецПроцедуры

Если при проходе отладчиком в самом конце этой процедуры ваши реквизиты всё еще пусты, но при открытии формы один из них уже заполнен — значит, логика выполняется позже или параллельно через другие механизмы. Рассмотрим, где именно это может происходить.

Влияние расширений и аннотация &Вместо

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

Для поиска таких «перехватов» выполним следующие действия:

  1. Откроем список расширений в конфигураторе.
  2. Проверим наличие формы документа «РеализацияТоваровУслуг» в каждом расширении.
  3. Если форма есть, проверим модуль этой формы на наличие процедур с аннотациями &Вместо, &Перед или &После.
  4. Используем специализированные инструменты, такие как обработка PowerTools, которая позволяет увидеть все изменения метаданных, внесенные расширениями, в одном окне.

Механизмы БСП «Заполнение объектов»

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

Попробуем выполнить глобальный поиск по всей конфигурации (включая расширения) по имени реквизита, который заполняется успешно. Если поиск по ссылке не дает результатов, выполним поиск по строке (в кавычках), так как к реквизитам могут обращаться через конструкцию Объект["ИмяРеквизита"] или через ЗаполнитьЗначенияСвойств.

Автоматическое заполнение платформой (по именам)

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

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

Параметры формы и структура «ДанныеЗаполнения»

Иногда логика переносится в модуль формы. Когда мы нажимаем кнопку «Создать на основании», платформа открывает форму нового документа и передает в нее структуру параметров. Рассмотрим, как это можно проверить в процедуре ПриСозданииНаСервере:


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

Если вы видите, что реквизит заполняется именно в момент открытия формы, обязательно проверьте подписки на события. Хотя автор темы указал, что все подписки типовые, стоит обратить внимание на универсальные подписки, такие как ПриКопировании или ОбработкаЗаполнения, которые могут быть назначены на тип ДокументОбъект целиком.

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

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

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

Проблема кэширования конфигурации

В редких случаях, особенно при активной разработке в расширениях, вы можете столкнуться с тем, что точка останова игнорируется из-за неактуального кэша. Если вы уверены, что код должен работать, но этого не происходит, попробуйте очистить кэш пользователя или запустить базу с параметром /ClearCache. Это гарантирует, что клиентская часть загрузит последние изменения метаданных и модулей.

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

← На главную