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

Программист 1С v8.3 (Управляемые формы) 1C:Бухгалтерия Бухгалтерский учет IT и автоматизация бизнеса
← На главную

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

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

Почему контрагенты помечаются на удаление: технические причины

Проанализируем архитектуру обмена данными между обычными формами (УТ 10.3 на базе планов обмена) и конфигурацией на базе Библиотеки стандартных подсистем (БП 3.0):

  1. Регистрация записей типа «Удаление объекта». Если в УТ 10.3 ранее выполнялось физическое удаление лишних элементов (например, стандартной обработкой «Удаление помеченных объектов» или сторонней чисткой дублей после первой тестовой выгрузки), платформа 1С автоматически фиксирует в таблице регистрации изменений узла обмена служебную запись типа УдалениеОбъекта с уникальным идентификатором (GUID). Когда формируется XML-сообщение, в него помещается команда на удаление. Приемник на базе БСП, получив команду удаления объекта, на который уже ссылаются проводки или документы, в целях безопасности не стирает запись физически (что привело бы к появлению «Объект не найден»), а вызывает метод УстановитьПометкуУдаления(Истина).
  2. Ошибки сопоставления в регистре «Соответствия объектов информационных баз». При переходе с двустороннего на односторонний обмен или при повторной синхронизации сопоставление по GUID или ключевым полям (ИНН/КПП) может привязаться к устаревшему или помеченному дублю в базе-источнике.
  3. Перенос свойства ПометкаУдаления в правилах конвертации (ПКО). В типовых правилах обмена конвертация свойства ПометкаУдаления часто настроена напрямую. Если контрагент в базе-источнике попадает в выборку из удаленной папки или ошибочно сопоставлен, флаг синхронно перезаписывает реквизит в базе-приемнике.

Шаг 1. Анализ выгруженного сообщения обмена

Выясним причину проблемы, проанализировав данные, которые фактически передает УТ 10.3. Переведем обмен во временный файловый режим и выгрузим данные в файл.

Откроем полученный XML-файл в любом текстовом редакторе и выполним поиск по наименованию или ИНН проблемного контрагента:

  1. Если элемент представлен тегом <УдалениеОбъекта>, значит, в плане обмена источника зарегистрировано удаление этой ссылки.
  2. Если контрагент выгружен как полноценный объект справочника <СправочникСсылка.Контрагенты>, но внутри присутствует строка <ПометкаУдаления>true</ПометкаУдаления>, значит, реквизит передается напрямую из базы-источника (проверяем группы и дубли).

Шаг 2. Очистка зарегистрированных удалений в УТ 10.3

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

  1. Откроем в УТ 10.3 обработку Регистрация изменений для обмена.
  2. Выберем узел плана обмена, настроенный для синхронизации с БП 3.0.
  3. Развернем справочник Контрагенты.
  4. Найдем строки, помеченные как удаление объекта.
  5. Выделим ошибочные позиции и нажмем Отменить регистрацию.

Шаг 3. Проверка регистра соответствий в БП 3.0

Проанализируем правильность связки идентификаторов в базе-приемнике:

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

Шаг 4. Корректировка правил обмена (КД 2.0)

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

  1. В конфигурации «Конвертация данных 2.1» откроем правила обмена между УТ 10.3 и БП 3.0.
  2. В ПКО справочника Контрагенты найдем правило конвертации свойства (ПККС) ПометкаУдаления и установим флаг Не замещать значение у существующих объектов в приемнике. В этом случае существующие в БП элементы не будут помечаться на удаление, даже если из источника поступит такое значение.
  3. В обработчике события При получении удаления добавим проверку, запрещающую установку пометки на удаление для контрагентов:
    
    Если ТипЗнч(Объект) = Тип("СправочникОбъект.Контрагенты") Тогда
        Отказ = Истина;
    КонецЕсли;
    
  4. Сохраним измененные правила и загрузим их в узел обмена.

Шаг 5. Защита данных через расширение конфигурации в БП 3.0

Если правила обмена вшиты в конфигурацию или обновляются автоматически и их редактирование нежелательно, защитим данные от перезаписи с помощью расширения в БП 3.0 без снятия базы с поддержки.

Создадим расширение и добавим подписку на событие ПередЗаписью для справочника Контрагенты со следующим программным кодом:


Если ОбменДанными.Загрузка И Не Источник.ЭтоНовый() И Источник.ПометкаУдаления Тогда
    // Если в базе контрагент не был помечен, блокируем изменение признака удалением из обмена
    Если Не Источник.Ссылка.ПометкаУдаления Тогда
        Источник.ПометкаУдаления = Ложь;
    КонецЕсли;
КонецЕсли;

Рассмотренный подход позволяет полностью исключить случайную пометку контрагентов на удаление при фоновых сеансах синхронизации и сохраняет целостность бухгалтерской базы.

← На главную