Проблема с автоматической регистрацией изменений в планах обмена — одна из самых коварных в разработке на платформе 1С. Вроде бы все настройки в метаданных выполнены верно: объекты включены в состав, флаг Авторегистрация установлен в положение Разрешить, но при записи данных таблица изменений остается пустой. Разберем по шагам, почему это происходит и как провести глубокую диагностику системы.
Прежде чем грешить на программный код, необходимо исключить самую простую ошибку: проверку регистрации не на том узле. В платформе 1С существует предопределенный элемент плана обмена — ЭтотУзел. Важно понимать, что система никогда не регистрирует изменения для текущего узла информационной базы. Регистрация всегда происходит только для сторонних узлов.
Проанализируем ваш запрос для проверки изменений:
ВЫБРАТЬ
ПользователиИзменения.Ссылка КАК Ссылка,
ПользователиИзменения.Узел КАК Узел
ИЗ
Справочник.Пользователи.Изменения КАК ПользователиИзменения
ГДЕ
ПользователиИзменения.Узел = &Узел
Если в параметр &Узел вы передаете значение, полученное методом ПланыОбмена.ВашПланОбмена.ЭтотУзел(), результат всегда будет пустым. Убедитесь, что в справочнике узлов создан как минимум один дополнительный узел (получатель), и вы проверяете регистрацию именно по нему.
Платформа позволяет программно управлять процессом регистрации изменений. Даже если в метаданных стоит «Разрешить», разработчик может отключить регистрацию для конкретного объекта в коде. Чаще всего это делается через свойство ОбменДанными.
Рассмотрим основной механизм блокировки. В обработчиках ПередЗаписью или ПриЗаписи может присутствовать строка:
ЭтотОбъект.ОбменДанными.Получатели.АвтоЗаполнение = Ложь;
Эта установка полностью отключает стандартный механизм платформы по заполнению таблицы получателей для текущей транзакции записи. Проанализируем ситуацию: как найти этот код, если конфигурация большая? Используйте глобальный поиск по всей конфигурации (Ctrl+Shift+F) по строке .АвтоЗаполнение = Ложь или просто .АвтоЗаполнение.
Также проверьте свойство ОбменДанными.Загрузка. Если объект записывается с установленным флагом Загрузка = Истина, платформа по умолчанию не выполняет авторегистрацию, чтобы избежать зацикливания при обмене. Это актуально, если пользователи или данные загружаются из внешних систем (например, Active Directory или мобильное приложение).
В современных конфигурациях (особенно в решениях от CRM-вендоров) логика регистрации часто вынесена в Подписки на события. Даже если в самом модуле объекта пусто, подписка может срабатывать «тихо».
Выясним причину через замер производительности:
Пользователи).ОбменДанными.Это позволит увидеть все процедуры, которые обращаются к коллекции получателей. Особое внимание уделите подпискам с именами вроде ПриЗаписиОбъектаДляОбмена или ПередЗаписьюРегистрацияИзменений. Если вы обнаружили, что коллекция Получатели очищается принудительно, необходимо внести правки в логику этих подписок или добавить ваш новый план обмена в исключения.
Проанализируем настройки самого плана обмена. Если в свойствах объекта установлен флаг Распределенная информационная база, механизмы регистрации работают иначе. В РИБ-планах данные автоматически регистрируются только для узлов, которые являются «соседними» в топологии. Если вы создали обычный план обмена, а потом включили флаг РИБ, это могло нарушить логику. Для обычного обмена данными (не РИБ) этот флаг должен быть выключен.
Платформа 1С оптимизирует запись данных. Если вы открыли форму объекта и нажали «Записать», но фактически ни одно поле не изменилось, платформа может проигнорировать запись в таблицу изменений Chng. Попробуйте изменить какое-нибудь значимое поле (например, комментарий или наименование) и проверьте регистрацию снова.
Также выясним, не происходит ли откат транзакции. Если запись объекта встроена в сложную цепочку действий, и в конце возникает ошибка (даже обработанная), транзакция откатывается. Вместе с ней удаляются и записи из таблиц регистрации изменений. Проверьте Журнал регистрации на предмет скрытых ошибок в момент записи.
Иногда проблема кроется в физическом повреждении вспомогательных таблиц базы данных. Таблицы регистрации изменений имеют суффикс Chng в СУБД. Если ничего из вышеперечисленного не помогло, выполним следующие действия:
Этот цикл действий заставит платформу пересоздать внутренние таблицы регистрации. Также рекомендуется запустить стандартную процедуру Тестирование и исправление с включенными пунктами «Проверка логической целостности» и «Реиндексация таблиц».
Чтобы окончательно понять, виновата ли платформа или настройки метаданных, попробуйте зарегистрировать объект вручную. Напишите простую обработку:
УзелСсылка = ПланыОбмена.ВашПланОбмена.НайтиПоКоду("КодУзла");
ОбъектСсылка = Справочники.Пользователи.НайтиПоНаименованию("Иванов");
ПланыОбмена.ЗарегистрироватьИзменения(УзелСсылка, ОбъектСсылка);
Если после выполнения этого кода ваш запрос из Сообщения 0 начал показывать изменения, значит:
В этом случае проблема 100% заключается в механизме авторегистрации, который либо блокируется в коде (см. Шаг 2), либо некорректно настроен в метаданных (состав плана обмена).
Помните, что для справочника Пользователи в CRM-системах часто используются специализированные механизмы синхронизации с сотрудниками и физическими лицами. Проверьте, не изменяете ли вы «пустой» объект, который программно перезаписывается при открытии или закрытии формы, что может мешать стандартной логике регистрации.