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

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

Понимание механизма временных объектов в XDTO

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

1. Когда в потоке данных встречается ссылка на объект, который еще не был прочитан или не существует в системе, платформа создает так называемый «временный объект».
2. Этот «временный объект» выступает в роли заглушки, чтобы избежать ошибки нарушения ссылочной целостности.
3. В процессе загрузки всех данных система ожидает, что этот объект будет «наполнен» реальными значениями (пройдет процесс полной загрузки).
4. Если по завершении транзакции объект так и не получил полноценные данные, система удаляет его, чтобы не оставлять в базе «битые» или пустые записи.

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

Где искать причину удаления

Основную логику обработки таких объектов можно найти в модуле ОбменДаннымиXDTOСервер. Рассмотрим ключевой фрагмент кода, который отвечает за управление временными объектами:

// Объекты, создаваемые по ссылке, запоминаем в таблицу,
// чтобы после загрузки всех данных удалить объекты,
// которые так и не были загружены полностью ("временные объекты").
// При загрузке объектов "целиком" удаляем объекты из таблицы,
// переводя их из состояния "временных" в "постоянные".

Если ваш объект (в нашем случае — договор) был создан как временный, но не был корректно «дозаполнен» в рамках одного обмена, он попадает под процедуру автоматической очистки. Вот основные причины, почему это происходит:

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

Методика диагностики и решения

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

1. Проверка прав доступа: Убедитесь, что пользователь, под которым выполняется обмен, имеет полные права на запись объектов. Иногда RLS или базовые ограничения прав препятствуют записи конкретных справочников, в результате чего объект создается в памяти, но не фиксируется в базе.
2. Отладка обработчиков: Проверьте правила конвертации на наличие кода в обработчиках ПослеЗагрузки или ПриЗагрузке. Часто разработчики программно отменяют запись объекта, если он не соответствует бизнес-логике.
3. Анализ технологического журнала: Настройте технологический журнал на событие DBPOST (запись в базу) для конкретного типа метаданных. Это позволит увидеть момент, когда транзакция записи прерывается или откатывается.
4. Проверка соответствия типов: Убедитесь, что правила обмена актуальны для текущей конфигурации. Любые изменения в структуре метаданных (например, добавление обязательного реквизита) могут приводить к тому, что старые правила перестают корректно «наполнять» объект данными.

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