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

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

При работе со связкой конфигураций «Управление торговлей 10.3» (УТ) и «Бухгалтерия предприятия 3.0» (БП) специалисты часто сталкиваются с ситуацией, когда после внесения изменений в настройки обмена (например, добавления новой организации или изменения даты начала выгрузки) синхронизация перестает работать. Особенно критичной является ситуация, когда данные в базе УТ 10.3 зарегистрированы, файл выгрузки формируется, но в БП 3.0 ничего не загружается или возникает ошибка «Сообщение обмена было принято ранее».

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

Разберем причину возникновения проблемы

Когда мы меняем настройки обмена в УТ 10.3, система часто требует пересоздать узел или очистить текущую регистрацию изменений. Основная сложность заключается в том, что механизм обмена основан на планах обмена и строгой последовательности номеров сообщений. Если мы сбрасываем регистрацию в одной базе, счетчик отправленных сообщений может обнулиться, в то время как база-приемник (БП 3.0) все еще ожидает сообщение с номером, следующим за последним успешно принятым (например, №151).

Проанализируем ситуацию: если УТ 10.3 присылает файл с номером «1», а БП 3.0 помнит, что последнее сообщение было «150», она просто проигнорирует этот пакет данных, считая его устаревшим. Именно поэтому в БП «пусто», хотя файл обмена физически может содержать данные.

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

В УТ 10.3 (на обычных формах) для регистрации изменений используется либо стандартная обработка Регистрация изменений для обмена, либо Групповая обработка справочников и документов. Если в базе ведется учет по 50 организациям, а нам нужно выгрузить только 2, регистрация всех объектов приведет к огромному файлу и дублированию данных.

Рассмотрим, как сделать это точечно через стандартную обработку регистрации:

  1. Откроем обработку Регистрация изменений для обмена.
  2. Выберем нужный Узел обмена (нашу настройку синхронизации с БП).
  3. Нажмем кнопку «Добавить» и выберем пункт «Зарегистрировать объекты с помощью отбора».
  4. В появившемся окне выберем типы документов (например, Реализация товаров и услуг, Поступление товаров и услуг).
  5. В поле отбора укажем Организация и выберем только нужные нам юридические лица.
  6. Установим период (дату начала выгрузки).

Важный технический момент: Справочники (Контрагенты, Номенклатура) в УТ 10.3 часто не имеют реквизита Организация. Чтобы они попали в обмен, их нужно зарегистрировать целиком или они подтянутся «по ссылке» вместе с документами. Если вы регистрируете документы по фильтру, система автоматически добавит в файл обмена все справочники, на которые ссылаются эти документы.

Шаг 2: Устранение ошибки «Сообщение обмена было принято ранее»

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

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

Чтобы БП 3.0 приняла файл из УТ 10.3, который начался заново с номера «1», нам нужно вручную изменить номер принятого сообщения в БП на «0» (или «1»).

Для программного сброса номеров в коде 1С (если нет доступа к интерфейсному изменению) можно использовать следующий фрагмент:


// Пример для запуска во внешней обработке
УзелОбмена = ПланыОбмена.ОбменУправлениеТорговлейБухгалтерияПредприятия.НайтиПоКоду("КодВашегоУзла");
ОбъектУзла = УзелОбмена.ПолучитьОбъект();
ОбъектУзла.НомерОтправленного = 0;
ОбъектУзла.НомерПринятого = 0;
ОбъектУзла.Записать();

После того как номера в обеих базах будут согласованы (в УТ отправленное = 1, в БП ожидаемое принятое = 1), загрузка данных пройдет успешно.

Шаг 3: Проверка правил обмена

Поскольку БП 3.0 регулярно обновляется, а УТ 10.3 остается на старой архитектуре, типовые правила обмена могут устаревать. Рассмотрим, как актуализировать правила:

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

Это гарантирует, что структура XML-файла, которую генерирует УТ 10.3, будет соответствовать ожиданиям БП 3.0. Если база УТ 10.3 сильно кастомизирована (изменены типы данных, удалены стандартные реквизиты), правила придется дорабатывать в конфигурации Конвертация данных 2.1.

Шаг 4: Анализ результата и отладка

Если регистрация выполнена и номера сообщений исправлены, но данные все равно не видны в БП, проанализируем следующие моменты:

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

Итоги совместной работы

Мы проанализировали основные причины сбоя обмена между УТ 10.3 и БП 3.0. Главное решение кроется в двух действиях: точечной регистрации изменений через отборы в стандартной обработке и синхронизации номеров сообщений в узлах обмена обеих баз. Не забывайте также проверять актуальность правил обмена, выгружая их непосредственно из обновленной версии Бухгалтерии.

Следуя этим шагам, вы сможете восстановить работоспособность обмена даже в сильно измененных конфигурациях, избежав при этом дублирования данных по ненужным организациям.

← На главную