Почему не снимаются объекты с регистрации при выполнении обмена в 1С?

Ситуация, когда объекты в базе-источнике остаются «висеть» в регистрации изменений даже после успешного, на первый взгляд, обмена, знакома многим специалистам. Давайте разберем, почему это происходит, как работает механизм квитирования и как исправить эту проблему, чтобы обмен работал стабильно.

Как работает механизм регистрации изменений

Для понимания проблемы необходимо вспомнить принцип, по которому 1С понимает, что данные успешно переданы. Этот процесс называется квитированием. Разберем его по шагам:

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

Таким образом, зависание объектов — это признак того, что источник не получил от приемника подтверждение (квитанцию) о том, что данные были успешно загружены.

Основные причины отсутствия квитирования

Прежде чем приступать к «хирургическим» методам, проанализируем, почему цепочка подтверждения может рваться:

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

Методы исправления ситуации

Рассмотрим конкретные действия, которые помогут восстановить обмен.

1. Проверка «зацикливания» номеров

Иногда возникает ошибка «Номер сообщения меньше либо равен ранее принятому». Это происходит, когда базы «не понимают», кто какой пакет должен прислать следующим. Чтобы решить эту проблему, можно временно обнулить счетчики, но делать это нужно осторожно.

Рекомендуемый алгоритм действий:

1. Убедитесь, что в обоих узлах обмена (в обеих базах) выставлены корректные настройки путей обмена.
2. Если произошла рассинхронизация, попробуйте временно установить в параметрах обмена обоих узлов (в базе-источнике и базе-приемнике) номер сообщения на достаточно большое число, например, 1 000 000.
3. Выполните обмен несколько раз в обе стороны. Это позволит «протолкнуть» очередь сообщений и выровнять счетчики.

2. Ручная очистка регистрации

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

Используйте следующий подход в консоли кода:

// ВАЖНО: Выполняйте это только после проверки целостности данных!
// Получаем узел, для которого нужно очистить регистрацию
Узел = ПланыОбмена.ВашПланОбмена.НайтиПоКоду("КодУзла");

// Очищаем регистрацию изменений для конкретного узла
ПланыОбмена.УдалитьРегистрациюИзменений(Узел);

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

Важные рекомендации по диагностике

Чтобы в будущем не сталкиваться с подобными вопросами, придерживайтесь следующих правил:

• Следите за Журналом регистрации: Если обмен завершается с ошибками, всегда ищите записи в ЖурналеРегистрации с уровнем «Ошибка». Часто там указана причина, по которой объект не был загружен (например, нарушение прав доступа или запрет записи объекта).
• Проверяйте состав планов обмена: Убедитесь, что метаданные объекта включены в ПланОбмена и что правила обмена (КД 2.0) корректно настроены для миграции этих объектов.
• Чередуйте обмен: Старайтесь настроить регламентные задания так, чтобы обмен в обе стороны чередовался: сначала выгрузка из источника, затем загрузка в приемнике и отправка ответного квитка обратно.

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