Как отследить, как объект попал в таблицу изменений плана обмена?

← На главную

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

Особенности механизма регистрации изменений на уровне платформы

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

Кроме того, в платформе 1С отсутствует системный триггер или предопределенное событие вроде «ПриРегистрацииИзменения», которое позволяло бы перехватить момент физической записи в таблицу на встроенном языке. Поэтому выявление первопричины требует комплексного анализа механизмов конфигурации.

Основные причины появления объектов в таблице изменений

Рассмотрим типовые сценарии, из-за которых документы могут регистрироваться к обмену:

Интерактивная перезапись или проведение документов. При записи документа стандартно срабатывают подсистемы регистрации БСП или типовые подписки на события ПриЗаписи, настроенные для автоматической фиксации изменений узлов. Если пользователь или внешняя обработка перезаписали старый документ, он неизбежно попадет в план обмена.
Программный вызов метода ПланыОбмена.ЗарегистрироватьИзменения(). Данный метод добавляет запись напрямую в таблицу регистрации изменений узла. При этом сам объект в информационной базе не модифицируется: события ПередЗаписью и ПриЗаписи не инициируются, дата модификации объекта не меняется, а стандартный Журнал регистрации не фиксирует никаких действий над объектом.
Каскадная регистрация связанных данных в БСП. В конфигурациях на базе Библиотеки стандартных подсистем изменение одного объекта может повлечь регистрацию целой цепочки связанных сущностей. Например, при изменении реквизитов договора, контрагента или ставки налога механизмы правил регистрации данных могут автоматически отправить на регистрацию все первичные документы, где они задействованы.
Регламентные и фоновые задания. Если пачка документов появляется ночью или рано утром, источником часто выступают фоновые процедуры: актуализация границ последовательностей, регламентное закрытие месяца, фоновая нормализация нормативно-справочной информации, переоценка валютных остатков или загрузка данных из внешних API.
Транзитный обмен в РИБ. Если текущая база выступает центральным узлом распределенной информационной базы, то при приеме пакета данных от одного периферийного узла полученные изменения автоматически регистрируются платформой к отправке во все остальные периферийные узлы.

Способ 1. Анализ Журнала регистрации по конкретному объекту

Разберем первый и самый простой шаг расследования — проверку прямой модификации документа. Если документ попал в обмен из-за фактической записи, это отразится в системном журнале регистрации.

Откроем Журнал регистрации в меню «Администрирование» — «Обслуживание» — «Журнал регистрации».
Установим отбор по полю Данные, указав ссылку на конкретный проблемный старый документ.
Зададим интервал времени, охватывающий период (например, прошедшую ночь или утро), когда документ появился в таблице регистрации.
Проанализируем события Данные. Изменение или Данные. Проведение: посмотрим имя пользователя, запустившего процесс, приложение и имя регламентного задания, если запись выполнялась в фоновом сеансе.

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

Способ 2. Анализ фоновых заданий в период массовой регистрации

Если прямой след объекта в Журнале регистрации отсутствует, сопоставим время появления записей в обмене с расписанием системных задач. Отфильтруем Журнал регистрации за утренние часы без отбора по конкретным данным, но с отбором по уровню важности «Ошибка, Предупреждение, Информация» и событиям выполнения регламентных заданий. Это позволит выяснить, какие регламентные процедуры выполнялись непосредственно перед массовым заполнением таблиц обмена.

Способ 3. Расследование через Технологический журнал (ТЖ)

Наиболее точный и низкоуровневый способ поймать источник программной регистрации объекта без внесения изменений в конфигурацию — настройка Технологического журнала 1С на стороне сервера.

В момент вызова метода ПланыОбмена.ЗарегистрироватьИзменения() платформа выполняет операцию INSERT в соответствующую таблицу СУБД. В зависимости от типа СУБД таблица изменений документа имеет имя вида _Document<N>_ChngR<N> или _NodeChangeRec<N>. Настроив сбор событий обращения к СУБД с отбором по подстроке имени таблицы, мы сможем зафиксировать полный контекст исполнения.

Посмотрим на пример конфигурационного файла logcfg.xml для сбора событий СУБД:


<config xmlns="http://v8.1c.ru/v8/tech-log">
    <dump create="false"/>
    <log location="C:\LOGS\PlanExchange" history="24">
        <event>
            <eq property="name" value="DBMSSQL"/>
            <like property="sql" value="%_Document%_ChngR%"/>
        </event>
        <property name="all"/>
    </log>
</config>

В событии ТЖ будут зафиксированы параметры Context (стек вызовов на встроенном языке с указанием модулей и номеров строк), имя пользователя (usr) и имя процесса, что позволит однозначно установить фрагмент программного кода, вызвавший добавление записей.

Способ 4. Проверка правил регистрации данных (ПРД)

Если обмен построен на типовой библиотеке БСП, проанализируем правила регистрации данных (ПРД). Откроем типовую обработку «Регистрация изменений для обмена данными» и проверим настройки автоматической регистрации для подозрительного документа. Нередко причиной лавинообразной регистрации старых документов становятся некорректные выборки в обработчиках правил регистрации данных, когда при обновлении периодического регистра сведений или связанного справочника алгоритм пытается заново перерегистрировать документы за закрытые периоды.

Профилактика: даты запрета загрузки и изменения

В процессе обсуждения часто возникает вопрос о влиянии даты запрета. Важно разделять два механизма:

Дата запрета изменения данных. Предотвращает интерактивное и программное редактирование документов пользователями в закрытом периоде, снижая риск случайного перезаписывания старых документов.
Дата запрета загрузки данных. Настраивается непосредственно в правилах синхронизации и предотвращает прием устаревших данных из других узлов, защищая закрытые учетные периоды даже в том случае, если изменения были зарегистрированы и отправлены узлом-источником.

Используя комбинацию анализа Журнала регистрации и технологического журнала, можно гарантированно локализовать участок кода, отвечающий за неожиданную регистрацию объектов в плане обмена.