Почему при обмене между УТ 10.3 и БП 3.0 каждый раз выгружаются все данные и как это исправить?

При настройке синхронизации между конфигурациями «Управление торговлей 10.3» и «Бухгалтерия предприятия 3.0» пользователи часто сталкиваются с проблемой «зацикливания» обмена. Суть проблемы заключается в том, что даже при отсутствии изменений в базе-источнике (УТ), система при каждом запуске обмена пытается выгрузить весь массив данных (например, десятки тысяч объектов). Это приводит к колоссальным временным затратам на загрузку в базе-приемнике (БП) и создает избыточную нагрузку на сервер.

В этой статье мы проанализируем основные причины такого поведения системы и разберем по шагам методы диагностики и решения данной технической проблемы.

Причина 1: Рассинхронизация номеров сообщений

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

Если по какой-то причине НомерПринятого сообщения в УТ остается меньше, чем НомерОтправленного, УТ считает, что данные не дошли до адресата, и продолжает включать их в каждый следующий файл обмена.

Как исправить:

1. В базе-источнике (УТ) откройте список узлов плана обмена, который используется для синхронизации.
2. Найдите узел, соответствующий базе БП.
3. Проверьте значения в полях «Номер отправленного» и «Номер принятого».
4. Если номер принятого сообщения значительно отстает, необходимо вручную выровнять их в базе-приемнике или источнике. Разберем пример программной корректировки:

// Пример для обработки или консоли запросов
УзелОбъекта = ПланыОбмена.ОбменУправлениеТорговлейБухгалтерияПредприятия.НайтиПоКоду("КодВашегоУзла").ПолучитьОбъект();
УзелОбъекта.НомерПринятого = УзелОбъекта.НомерОтправленного;
УзелОбъекта.Записать();

После этой операции при следующем обмене система увидит, что все предыдущие изменения «подтверждены», и выгрузит только новые данные.

Причина 2: Особенности правил регистрации объектов (ПРО)

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

Проанализируем следующие факторы в правилах регистрации:

1. Режим «Выгружать всегда»: В правилах для определенных справочников (например, «Цены номенклатуры» или «Валюты») может стоять признак принудительной выгрузки. В этом случае объект попадает в план обмена при каждом сеансе, независимо от наличия изменений.
2. Связанные объекты: Часто при регистрации документа система автоматически регистрирует всю связанную с ним номенклатуру, контрагентов и договоры. Если в правилах прописан сложный код в обработчике ПриРегистрации, это может вызывать цепную реакцию регистрации тысяч объектов.

Для диагностики рекомендуем использовать типовую обработку «Регистрация изменений для обмена данными». Посмотрим на колонку «Номер сообщения»: если у объектов там стоит «0», значит, они были только что зарегистрированы и еще ни разу не включались в пакет обмена.

Причина 3: Технические сбои при использовании COM-соединения

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

В этом случае рекомендуется:

• Проверить журнал регистрации в БП 3.0 на наличие ошибок в момент загрузки (ищите события «Данные.Запись»).
• Попробовать выполнить обмен через файловый ресурс (выгрузка в XML), чтобы исключить влияние нестабильного COM-соединения.

Причина 4: Влияние фоновых и регламентных заданий

В УТ 10.3 могут работать регламентные задания, которые программно перезаписывают объекты без изменения их визуальных реквизитов. Например, это может быть обработка последовательностей, пересчет итогов или обновление дополнительных свойств. Даже если значение реквизитов не поменялось, метод Записать() инициирует срабатывание механизма регистрации изменений.

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

Методы радикального решения («Очистка очереди»)

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

Пошаговый алгоритм:

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

Для программной очистки можно использовать следующий код:

Узел = ПланыОбмена.ОбменУправлениеТорговлейБухгалтерияПредприятия.НайтиПоКоду("БП");
ПланыОбмена.УдалитьРегистрациюИзменений(Узел);

Альтернативные форматы обмена

Если вы используете старые релизы УТ 10.3, работающие на классических XML-правилах, рассмотрите возможность перехода на формат EnterpriseData (универсальный формат обмена данными). Этот механизм более современный, он лучше обрабатывает подтверждения и менее чувствителен к мелким техническим сбоям платформы. Большинство современных редакций БП 3.0 и последних релизов УТ 10.3 поддерживают этот формат «из коробки».