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