При разработке собственных механизмов интеграции или настройке типового обмена данными в среде 1С:Предприятие программисты часто сталкиваются с ситуацией, когда, несмотря на включенную авторегистрацию в плане обмена, таблица изменений остается пустой. Мы можем изменять объекты, записывать их, но при попытке программно получить список измененных данных запрос возвращает пустой результат. Давайте подробно разберем, почему это происходит, как работает механизм регистрации «под капотом» и какие нюансы конфигурации ERP могут влиять на этот процесс.
Рассмотрим самую распространенную ситуацию, с которой столкнулся автор темы. Механизм планов обмена в 1С спроектирован для передачи данных другим информационным системам. Платформа оптимизирует нагрузку на базу данных: если в плане обмена не создано ни одного узла, кроме предопределенного ЭтотУзел, то регистрация изменений просто не производится.
Проанализируем логику системы: зачем платформе тратить ресурсы и записывать ссылки в служебные таблицы изменений, если нет ни одного получателя, которому эти данные нужно отправить? Система «понимает», что передавать изменения некому, и игнорирует правила авторегистрации.
Выясним причину на программном уровне. Когда мы пишем код для проверки изменений, мы часто используем запрос к виртуальной таблице:
НашУзел = ПланыОбмена.МойПланОбмена.ЭтотУзел();
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
| КонтрагентыИзменения.Ссылка КАК Ссылка
|ИЗ
| Справочник.Контрагенты.Изменения КАК КонтрагентыИзменения
|ГДЕ
| КонтрагентыИзменения.Узел = &Узел";
Запрос.УстановитьПараметр("Узел", НашУзел);
Результат = Запрос.Выполнить();
Если в параметре &Узел передан ЭтотУзел, результат практически всегда будет пустым. Платформа 1С не регистрирует изменения «сама на себя». Чтобы механизм заработал, необходимо создать в плане обмена хотя бы один элемент (узел), который будет представлять стороннюю базу или внешнюю систему. Как только в базе появится второй узел (получатель) и для него будет включена регистрация, платформа начнет наполнять таблицу .Изменения.
Второй важный аспект, который следует рассмотреть, — это использование свойства ОбменДанными.Загрузка. В процессе разработки или при массовых корректировках данных программисты часто отключают лишние проверки и механизмы регистрации, устанавливая этот флаг в Истина перед записью объекта.
Разберем, как это влияет на регистрацию:
Объект.ОбменДанными.Загрузка = Истина, платформа полностью игнорирует настройки авторегистрации в метаданных.Если вы изменяете контрагентов программно, убедитесь, что вы не подавляете регистрацию этим флагом, если ваша цель — увидеть их в плане обмена.
В современных конфигурациях, таких как ERP Управление предприятием или Комплексная автоматизация, механизмы обмена сильно завязаны на Библиотеку стандартных подсистем (БСП). Проанализируем дополнительные барьеры, которые могут мешать регистрации:
Функциональные опции: В настройках системы существует глобальная опция «Использовать синхронизацию данных». Если флаг снят, многие программные подписки на события, отвечающие за регистрацию изменений, просто не будут выполняться. Проверьте НСИ и администрирование — Настройка интеграции — Синхронизация данных.
Подписки на события: В ERP регистрация часто управляется не только свойством «Авторегистрация» в метаданных, но и программным кодом в подписках. Например, подписка ОбменДанными[НазваниеПланаОбмена]ЗарегистрироватьИзменение может содержать логику фильтрации. Если объект не соответствует условиям фильтра (например, по организации или подразделению), регистрация может быть удалена программно в той же транзакции.
Посмотрим на ситуацию со стороны базы данных. Регистрация изменений происходит в рамках той же транзакции, в которой записывается сам объект. Если вы пытаетесь проверить наличие изменений в той же самой обработке, где только что вызвали метод Записать(), но транзакция еще не зафиксирована (например, код выполняется внутри другой транзакции), запрос к таблице .Изменения может вернуть неактуальные данные в зависимости от уровня изоляции транзакций в СУБД.
Рассмотрим правильную последовательность действий для тестирования:
ЭтотУзел).Контрагенты.Если автоматический механизм по каким-то причинам не подходит, мы можем использовать ручное управление. Для этого в метаданных плана обмена для конкретного справочника можно установить авторегистрацию в значение «Запретить» и управлять процессом самостоятельно.
Рассмотрим пример программной регистрации изменений для конкретного узла:
// Получаем ссылку на узел, для которого хотим зарегистрировать изменения
УзелПолучатель = ПланыОбмена.МойПланОбмена.НайтиПоКоду("002");
Если НЕ УзелПолучатель.Пустая() Тогда
// Регистрируем конкретный объект
ПланыОбмена.ЗарегистрироватьИзменения(УзелПолучатель, СсылкаНаКонтрагента);
// Или можно зарегистрировать изменения для всего типа данных сразу
// ПланыОбмена.ЗарегистрироватьИзменения(УзелПолучатель, Тип("СправочникСсылка.Контрагенты"));
КонецЕсли;
Этот метод гарантированно добавляет запись в таблицу изменений, обходя платформенные алгоритмы авторегистрации. Однако стоит помнить, что в высоконагруженных системах злоупотребление ручной регистрацией может привести к избыточному росту таблиц _ChngR (служебные таблицы регистрации изменений в SQL), что замедлит работу всей базы.
Подведем итоги. Если у вас не регистрируются изменения:
ОбменДанными.Загрузка = Ложь.Следуя этим шагам, вы сможете настроить надежный обмен данными и контролировать регистрацию изменений на каждом этапе жизненного цикла объекта.