Как настроить постоянный обмен данными между 1С:Управление торговлей 10.3 и 11?

← На главную

Синхронизация данных между 1С:Управление торговлей версии 10.3 и версии 11 является одной из самых сложных задач интеграции. Это связано с принципиальным различием архитектур: УТ 10.3 построена на обычных формах и классическом партионном учете, в то время как УТ 11 использует управляемые формы, сложную систему «Партнеры-Контрагенты» и иную логику складского учета. Рассмотрим основные подходы и технические решения, которые позволяют организовать стабильный двусторонний обмен.

Архитектурные вызовы и подготовка данных

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

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

Вариант 1: Использование механизмов БСП и планов обмена

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

Шаг 1: Настройка планов обмена. Создадим в обеих базах планы обмена с одинаковым составом объектов. Включим в них документы товародвижения: ЗаказПокупателя, РеализацияТоваровУслуг, ПоступлениеТоваровУслуг и соответствующие справочники.

Шаг 2: Регистрация изменений. Чтобы не передавать всю базу целиком, будем использовать механизм регистрации. Проанализируем ситуацию: нам нужно передавать только измененные объекты. Для этого в УТ 10.3 можно использовать подписку на события ПриЗаписи.

Рассмотрим пример кода для регистрации изменений в кастомном регистре, если типовой механизм планов обмена кажется слишком тяжеловесным:


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

Шаг 3: Написание правил в Конвертации данных 2.0. Поскольку мы имеем дело с разными структурами, стандартные правила не перенесут документы корректно. Необходимо прописать обработчики ПослеЗагрузки для документов в УТ 11, чтобы они автоматически заполняли обязательные реквизиты, такие как ВидЦены, СкладскаяГруппа или ХозяйственнаяОперация.

Вариант 2: Обмен через Веб-сервисы и очередь сообщений

Если требуется высокая оперативность («событийный обмен»), рассмотрим реализацию через Web-сервисы. Этот метод позволяет передавать данные мгновенно при проведении документа в базе-источнике.

Разберем алгоритм работы такой системы:

В базе-приемнике (например, УТ 11) создается Web-сервис с методом ReceiveData(XMLData).
В базе-отправителе (УТ 10.3) настраивается подписка на событие проведения документа.
При срабатывании события объект сериализуется в XML (по правилам конвертации) и отправляется через SOAP или HTTP-запрос.
Если связь разорвана, объект помещается в локальную очередь (специальный регистр сведений) для повторной отправки.

Посмотрим на пример функции отправки данных через Web-сервис:


Функция ОтправитьДанныеВУТ11(СтрокаXML)
    Определение = Новый WSОпределения(URL_ВебСервиса, Логин, Пароль);
    Прокси = Новый WSПрокси(Определение, "http://www.uri.org", "ExchangeService", "ExchangePort");
    
    Попытка
        Результат = Прокси.ReceiveData(СтрокаXML);
        Возврат Истина;
    Исключение
        ЗаписатьВЛогОшибок(ОписаниеОшибки());
        Возврат Ложь;
    КонецПопытки;
КонецФункции

Решение проблемы коллизий и дублей

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

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

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

Оптимизация производительности

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

Вынос в фоновое задание: Весь процесс выгрузки и загрузки должен выполняться через РегламентныеЗадания. В УТ 10.3 для этого потребуется настроить отдельный сеанс под служебным пользователем, если используется файловый режим.
Пакетная передача: Не отправляйте каждый чих по отдельности. Сгруппируйте изменения за последние 1-2 минуты и передавайте их одним пакетом XML.
Использование Fast-XML: При написании правил в КД 2.0 старайтесь избегать сложных запросов внутри обработчиков ПередВыгрузкой. Лучше заранее подготовить данные в структуре и передать их в параметры.

Подводя итог, можно сказать, что связка УТ 10.3 и УТ 11 через механизмы БСП с глубокой кастомизацией правил конвертации является наиболее жизнеспособной. Хотя это требует значительных трудозатрат на этапе тестирования, в долгосрочной перспективе такая система обеспечит прозрачность учета между офисом и складом без необходимости полного переписывания исторических наработок в старой конфигурации.