Как перехватить запись объектов при обмене данными через план обмена в 1С

При организации периодического обмена данными между 1С и внешними системами (например, PLM-системами или другими базами) часто возникает необходимость протоколировать изменения: фиксировать, какие именно объекты загружаются, создаются или меняют свои реквизиты. Рассмотрим, как правильно отслеживать моменты перед записью и после записи объектов при загрузке через план обмена.

Почему событие ОбработкаЗаполнения не подходит

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

Способ 1. Подписка на событие с проверкой свойства ОбменДанными.Загрузка

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

Когда платформа 1С записывает объект в рамках процедуры обмена данными, она автоматически устанавливает свойство объекта Источник.ОбменДанными.Загрузка = Истина. Это позволяет чётко отделить записи, выполняемые фоновым обменом, от ручных действий пользователей.

Разберем по шагам порядок настройки подписки:

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

Проанализируем пример кода для сопоставления изменяемых реквизитов:

Процедура ПодпискаПередЗаписьюПриОбменеПередЗаписью(Источник, Отказ) Экспорт

    // Проверяем, выполняется ли запись в процессе обмена данными
    Если НЕ Источник.ОбменДанными.Загрузка Тогда
        Возврат;
    КонецЕсли;

    // Если объект новый, фиксируем создание
    Если Источник.ЭтоНовый() Тогда
        // Логика обработки создания нового объекта
        Возврат;
    КонецЕсли;

    // Для существующего объекта считываем его состояние из базы данных до записи
    СтарыеДанные = Источник.Ссылка.ПолучитьОбъект();
    Если СтарыеДанные <> Неопределено Тогда
        // Сравниваем значения реквизитов
        Если Источник.Наименование <> СтарыеДанные.Наименование Тогда
            // Фиксируем изменение реквизита "Наименование"
        КонецЕсли;
    КонецЕсли;

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

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

Способ 2. Отслеживание сеанса выделенного пользователя обмена

Если обмен данными происходит автоматически по расписанию под специальной служебной учетной записью (например, «Пользователь Обмена PLM»), мы можем определять факт обмена по текущему авторизованному пользователю информационной базы. Это удобно, если требуется привязать протоколирование к конкретной подсистеме или автору изменений.

В подписке на событие ПриЗаписи проверяется логин текущего пользователя (ПользователиИнформационнойБазы.ТекущийПользователь()) или значение реквизита Ответственный/Автор, если он заполняется службой обмена.

Способ 3. Использование штатного версионирования объектов

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

Важные технические нюансы при записи протокола

Посмотрим на практические аспекты, с которыми сталкиваются разработчики при написании собственных логов:

1. Контекст выполнения на сервере: Обмен данными чаще всего выполняется на стороне сервера 1С. Попытка записать текстовый файл по локальному пути вроде E:\отчеты\ приведет к ошибке, если у службы сервера 1С (пользователя ОС usr1cv8) нет прав на создание файлов в этом каталоге.
2. Работа внутри транзакции: Загрузка данных планом обмена происходит в единой транзакции. Если при загрузке произойдет ошибка, вся транзакция откатится. Если писать лог в файл прямо во время транзакции, файл сохранится, но данные в базе не обновятся. Поэтому протокол изменений рекомендуется записывать в независимый Регистр сведений либо накапливать во временной структуре и сохранять в файл после полного завершения обмена.