В процессе работы с планами обмена в 1С часто возникает задача: понять, в какой именно момент и по какой причине объект регистрируется для выгрузки в тот или иной узел. Особенно актуален этот вопрос, когда стандартная авторегистрация отключена, и регистрация происходит программно в разных частях конфигурации. Прямого события в платформе, такого как `ПриРегистрацииИзменений`, к сожалению, не существует. Давайте вместе разберемся, какими способами можно "поймать" этот момент и получить контроль над процессом.
Проанализируем ситуацию: у нас есть план обмена, и мы хотим перехватить регистрацию элемента справочника, например, "ДокументыПредприятия" в конфигурации "1С:Документооборот", используя дополнительный обработчик для бизнес-события "Поступление входящей почты" — для этой задачи есть универсальная обработка регистрации изменений для планов обмена.
Этот способ можно назвать самым прямолинейным и действенным, если ваша цель — найти уже существующие точки регистрации в коде типовой или доработанной конфигурации. Идея проста: найти все места, где вызывается метод, непосредственно отвечающий за регистрацию изменений.
Откройте конфигурацию в режиме "Конфигуратор".
Запустите глобальный поиск по всей конфигурации (обычно через меню "Правка" -> "Глобальный поиск" или сочетание клавиш Ctrl+Shift+F).
В строке поиска введите имя системного менеджера планов обмена и метода регистрации: ПланыОбмена.ЗарегистрироватьИзменения, в чем эффективно поможет статический анализатор кода проектов — для этого подойдёт автоматический статический анализатор кода 1С.
В результате поиска вы получите полный список всех модулей и строк кода, где происходит принудительная регистрация объектов. Это даст вам точное понимание алгоритмов, заложенных разработчиками. Проанализировав эти участки кода, вы сможете:
Понять логику регистрации. Вы увидите, при каких условиях система регистрирует объект, используя анализ конфигураций на наличие ошибок.
Поставить точки останова. Установив условные точки останова в найденных местах, вы сможете в режиме отладки отследить, какой именно объект регистрируется и в какой узел — в этом поможет инструмент для пошаговой отладки кода 1С.
Внести изменения. Если конфигурация не на полной поддержке, вы можете модифицировать эту логику, предварительно выполнив анализ изменений конфигурации.
Этот метод, хоть и кажется "жестким", является самым надежным способом найти источник регистрации в сложной, разветвленной конфигурации.
Если ваша задача — не найти существующую логику, а добавить свою собственную логику условной регистрации, то идеальным инструментом будут подписки на события. Этот подход не требует изменения типового кода и прекрасно работает через механизм расширений, что крайне важно для конфигураций на поддержке.
Основная идея — "подписаться" на событие записи интересующего нас объекта и внутри обработчика этой подписки решить, нужно ли его регистрировать в плане обмена.
ПередЗаписьюЭто наиболее предпочтительное событие, так как оно срабатывает до того, как объект будет фактически записан в базу данных. Это дает нам максимум контроля.
Разберем по шагам, как это реализовать:
Создайте в конфигурации (или в расширении) новую подписку на событие.
В качестве источника укажите нужный объект, например, СправочникОбъект.ДокументыПредприятия.
В качестве события выберите ПередЗаписью.
Создайте процедуру-обработчик для этой подписки. Внутри этой процедуры и будет наша логика.
Внутри обработчика нам нужно сравнить текущие данные объекта с теми, что хранятся в базе, чтобы понять, произошли ли значимые для нас изменения. Посмотрим на примерный код:
Процедура ЗарегистрироватьИзмененияДокументаПредприятияПередЗаписью(Источник, Отказ)
// Если это новый объект, его старой версии в базе нет.
// Если он помечается на удаление, логика может быть другой.
Если Источник.ЭтоНовый() Или Источник.ПометкаУдаления Тогда
Возврат;
КонецЕсли;
// Получаем "старую" версию объекта из базы данных, чтобы сравнить с "новой".
// Важно: Источник - это объект, который мы записываем, со всеми новыми данными.
СтарыйОбъект = Источник.Ссылка.ПолучитьОбъект();
// Проверяем, изменился ли важный для нас реквизит, например, "Состояние".
Если СтарыйОбъект.Состояние <> Источник.Состояние Тогда
// Если состояние изменилось на "Утвержден", регистрируем его в узле обмена.
Если Источник.Состояние = Перечисления.СостоянияДокументов.Утвержден Тогда
// Получаем узел плана обмена, для которого нужно зарегистрировать изменения.
// Узел можно получить по коду, наименованию или другим признакам.
ВыборкаУзла = ПланыОбмена.МойПланОбмена.Выбрать(Новый Структура("Код", "001"));
Если ВыборкаУзла.Следующий() Тогда
УзелОбмена = ВыборкаУзла.Ссылка;
// Выполняем регистрацию изменений для конкретного узла.
ПланыОбмена.ЗарегистрироватьИзменения(УзелОбмена, Источник.Ссылка);
КонецЕсли;
// Если нужно отменить регистрацию при определенном условии.
ИначеЕсли Источник.Состояние = Перечисления.СостоянияДокументов.Аннулирован Тогда
// Логика отмены регистрации
ВыборкаУзла = ПланыОбмена.МойПланОбмена.Выбрать(Новый Структура("Код", "001"));
Если ВыборкаУзла.Следующий() Тогда
УзелОбмена = ВыборкаУзла.Ссылка;
// Выполняем отмену регистрации изменений.
ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена, Источник.Ссылка);
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Таким образом, мы получаем полный контроль над процессом: регистрация происходит только тогда, когда выполнены наши уникальные бизнес-условия.
На первый взгляд может показаться, что для нашей задачи должны подойти встроенные обработчики самого объекта ПланОбмена. Давайте разберемся, почему это не так.
У объекта ПланОбменаОбъект есть ряд событий, таких как:
ПриОтправкеДанныхПодчиненномуПриПолученииДанныхОтГлавногоПередЗаписьюПриЗаписиЭти события предназначены для других целей:
События ПриОтправке... и ПриПолучении... срабатывают в момент формирования и загрузки сообщения обмена. К этому моменту регистрация уже давно произошла. Эти обработчики используются для фильтрации данных "на лету" или для модификации данных перед отправкой/после получения.
События ПередЗаписью и ПриЗаписи самого плана обмена относятся к записи объекта-узла, а не к регистрации изменений какого-либо справочника или документа в этом узле.
Вывод: Стандартные обработчики плана обмена не предназначены для перехвата момента регистрации изменений других объектов. Этот процесс происходит отдельно и управляется либо платформой (при авторегистрации), либо программно вызовами метода ПланыОбмена.ЗарегистрироватьИзменения.
Итак, подведем итог. Несмотря на отсутствие прямого события регистрации изменений, платформа 1С предоставляет мощные косвенные механизмы для решения нашей задачи.
Если вам нужно разобраться в существующей логике обмена в сложной конфигурации, ваш лучший инструмент — глобальный поиск по строке ПланыОбмена.ЗарегистрироватьИзменения.
Если вам нужно добавить свою кастомную логику регистрации, не изменяя типовой код, используйте подписки на события (ПередЗаписью или ПриЗаписи) для нужных объектов. Этот способ идеально подходит для реализации через расширения.
Комбинируя эти два подхода, вы сможете не только отследить, но и гибко управлять процессом регистрации данных для обмена, адаптируя его под любые требования вашего проекта.