Как правильно настроить удаление регистрации изменений после обмена данными в 1С?

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

Разберем проблему: почему регистрация не удаляется сама?

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

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

Правильный алгоритм: механизм квитирования

Для надежного обмена используется механизм подтверждения (квитирования). Проанализируем стандартную схему взаимодействия двух узлов:

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

Где разместить код для удаления регистрации?

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

1. Использование типовой обработки обмена. Если вы используете самописный обмен на базе обработки, логику подтверждения следует добавить в блок, отвечающий за чтение ответного сообщения от узла-корреспондента.

2. События правил обмена (Конвертация данных 2.1). Если обмен идет через правила обмена, можно использовать событие ПослеЗагрузкиДанных на стороне источника (когда он читает файл-ответ). Однако правильнее всего это делать перед началом новой выгрузки, когда анализируется номер сообщения, пришедший от партнера.

3. Механизмы БСП. В современных конфигурациях рекомендуется использовать функции общего модуля ОбменДаннымиСервер. Например, процедура ЗаписатьПодтверждениеПолученияДанных берет на себя всю рутину по работе с номерами сообщений.

Программная реализация удаления регистрации

Выясним, как выглядит код для удаления регистрации изменений по конкретному узлу. Для этого используется метод УдалитьРегистрациюИзменений(). Рассмотрим пример кода, который должен выполняться на стороне отправителя после получения номера подтверждения от приемника:

// Предположим, УзелОбмена - это ссылка на узел плана обмена
// НомерПодтверждения - число, полученное от принимающей стороны

ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена, НомерПодтверждения);

Этот метод крайне эффективен, так как он не просто удаляет всё подряд, а очищает только те записи, чей НомерСообщения в таблице регистрации не превышает указанное значение. Новые изменения, возникшие в процессе самого обмена, не пострадают, так как у них номер сообщения еще не определен (равен 0 или NULL).

Особенности отладки обмена данными

Проанализируем ситуацию, когда отладчик «не заходит» в код обмена. В 1С:Предприятие 8 большинство процедур обмена выполняется в фоновых заданиях на сервере. Чтобы отладить такой код, выполните следующие шаги:

• В конфигураторе откройте «Отладка» -> «Подключение».
• Нажмите кнопку «Автоматическое подключение» и установите флажок «Фоновые задания».
• Убедитесь, что сервер 1С запущен в режиме отладки (параметр -debug).
• Если используется файловая база, убедитесь, что в настройках не стоит запрет на выполнение регламентных заданий.

Риски принудительной очистки

Иногда возникает соблазн очистить регистрацию полностью, например, если очередь сообщений стала слишком большой. Рассмотрим, как это сделать программно для всех типов данных, входящих в план обмена:

// Полная очистка регистрации для узла без учета номеров сообщений
// ВНИМАНИЕ: это приведет к тому, что изменения не будут переданы!
ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена);

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

Использование инструментов разработчика

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

• Визуально оценить количество зарегистрированных объектов по каждому метаданному.
• Посмотреть конкретные ссылки на объекты, ожидающие выгрузки.
• Удалить регистрацию выборочно или по фильтру номеров сообщений.

В типовых конфигурациях (ERP, УТ 11, БП 3.0) эту обработку можно найти через раздел «Администрирование» — «Синхронизация данных» — «Состав отправляемых данных».

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