← На главную

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

Анализируем правила регистрации данных (ПРД)

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

В типовых решениях регистрация данных управляется не только интерфейсными настройками, но и программными правилами регистрации. Рассмотрим основные причины «невидимости» объекта:

1. Фильтрация по организациям: Если в настройках узла обмена указан список конкретных организаций, система будет проверять принадлежность контрагента к этим организациям. В УТ 11 контрагент может не иметь прямой связи с организацией, пока по нему не проведены документы. Проверьте, не ограничивают ли фильтры выгрузку «пустых» справочников.
2. Связка Партнер — Контрагент: Это критически важный момент для УТ 11. В этой конфигурации разделены понятия Партнер (управленческая сущность) и Контрагент (юридическое лицо). Часто правила настроены так, что триггером для выгрузки является именно создание Партнера с заполненным юридическим лицом. Если логическая связь нарушена или объект создан некорректно, регистрация может не сработать.
3. Дата начала синхронизации: Проверим дату, указанную в настройках обмена. Если объект по какой-то причине считается «старым» (например, был перенесен из другой базы с сохранением старой даты создания), он может игнорироваться правилами регистрации.

Разбираемся с ситуацией «Обработано объектов: 1», но данных нет

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

Проанализируем процесс загрузки в БП 3 по шагам:

Мэтчинг (Поиск дублей): Универсальный формат ищет соответствия по ключевым полям. Для контрагентов это обычно ИНН + КПП. Если в БП 3 уже существует контрагент с таким ИНН (возможно, помеченный на удаление или созданный вручную сто лет назад), система найдет его и попытается обновить. Если в пакете из УТ 11 данных меньше, чем уже есть в БП, или если сработал запрет на редактирование реквизитов, визуально изменений не будет. Объект «обработан», но новый не создан.

Проверка обязательных полей: БП 3 предъявляет жесткие требования к заполнению реквизитов перед записью. Если в УТ 11 не заполнены такие поля как:

• Вид контрагента (Юридическое / Физическое лицо);
• Страна регистрации;
• Группа (если настроена иерархия);

...то при попытке записи в БП 3 сработает отказ. Проблема в том, что в коде обмена через EnterpriseData ошибки записи часто перехватываются как «некритичные» и не выводятся в основной журнал регистрации в виде ярких красных записей.

Проверяем технические регистры и настройки

Если визуальный осмотр не помог, перейдем к «тяжелой артиллерии» — проверке внутренних регистров 1С. Выясним, нет ли конфликтов в идентификаторах.

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

Также проверим версии формата EnterpriseData. В настройках синхронизации обеих баз должна быть выбрана идентичная версия (например, 1.15). Если одна база отправляет данные в версии, которую приемник еще не понимает (например, база БП давно не обновлялась), часть тегов XML будет просто проигнорирована парсером XDTO.

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

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

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

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

Радикальный метод диагностики: Односторонний обмен

Как советовали коллеги на форуме, иногда полезно создать временную одностороннюю синхронизацию. Рассмотрим этот процесс:

1. Создаем новую настройку синхронизации только «на выход» из УТ в БП.
2. В правилах выгрузки указываем только справочник «Контрагенты».
3. При первом обмене отменяем всю автоматическую регистрацию и добавляем только одного «проблемного» контрагента.

Если в таком режиме объект «пролезет», значит, в основном двустороннем обмене существует конфликт правил (например, БП «перебивает» данные УТ или срабатывает приоритет баз). Если же и в новом обмене объект не создается — ищем незаполненные обязательные реквизиты в карточке контрагента в УТ 11.

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