Двусторонний HTTP-обмен между УТ 10.3 и УТ 11.5: поэтапная миграция без остановки бизнеса

Введение

При переходе на новую платформу многие сталкиваются с проблемой: "старая" система (УТ 10.3) обросла уникальными доработками под складские и бизнес-процессы, и мгновенный перенос всего функционала в УТ 11 невозможен или слишком рискован.

Видел много материалов по обмену между идентичными конфигурациями. Однако наш случай — потребовал нестандартного подхода. Готовых правил обмена КД не нашли, а разработка и тестирование новых правил обмена в КД с нуля представлялась гораздо более трудоемкой, чем написать представленный механизм, который позволил:

1. Запустить розницу на УТ 11.5 + РМК без остановки продаж.

2. Сохранить управление складом и интеграцию с сайтом в доработанной УТ 10.3.

3. Обеспечить единство НСИ и остатков в обеих системах.

Это решение — не готовая коробка, а подробный кейс с архитектурой, кодом и "граблями", который будет полезен разработчикам:

• которым нужен рабочий пример HTTP-обмена.

• планирующим поэтапную миграцию между разными версиями конфигураций 1С.

Предпосылки и постановка задачи

В торговой организации (розница + распределительный склад + интернет-магазин) исторически сложился учет на базе УТ 10.3. За годы эксплуатации конфигурация была серьезно доработана под нужды торговли и складской логистики.

Было принято решение:

• Новую розницу разворачиваем на УТ 11.5 с использованием РМК. Отказ от УТ10.3 в розничных магазинах не предвещал проблем. 

• Складские процессы и обмен с сайтом оставляем на проверенной временем УТ 10.3.

Ключевые требования к обмену:

• Двусторонняя синхронизация. Данные должны передаваться в обе стороны.

• Единая НСИ. Ввод всей нормативно-справочной информации (справочники) должен производиться в УТ 10.3 и автоматически мигрировать в УТ 11.5.

• Актуальные остатки. Остатки товаров на складах должны быть идентичны в обеих системах.

• Поэтапность. Возможность постепенно переносить наработанный в функционал из старой системы (УТ 10.3. ) в новую (УТ 11.5.).

Архитектура обмена

Обмен построен на прямой передаче данных через HTTP-сервисы. Это позволило избежать промежуточных файлов и обеспечить приемлемую скорость.

Ключевые принципы:

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

2. HTTP-сервисы как транспорт. В каждой из конфигураций опубликован свой HTTP-сервис (/hs/api/), который принимает данные от системы-источника.

3. Регламентные задания. Обмен инициируется по расписанию из обеих ИБ.

4. УТ10. была давно снята с поддержки, поэтому изменения делал непосредственно в ней (Общий модуль, План обмена, Http-Сервис, Регламентное задание).

5. Расширение для УТ 11. Так как вмешательство в типовой код УТ 11 не предполагалось, вся логика вынесена в расширение.

Логика работы:

• УТ 10.3 выступает в роли мастера по НСИ. Справочники создаются и изменяются здесь, после чего отправляются в УТ 11.5.

• УТ 10.3 - основной источник товародвижения. Приход, перемещения итд. формируется в УТ10.3. и так же отправляется в УТ 11.5.

• УТ 11.5 выступает в роли источника розничных продаж(ОРП, возвраты, реализации, заказы клиентов, заказы на перемещение с ЦС) и отправляет их в УТ 10.3.

Состав обмениваемых данных

Бизнес процесс построен так, что есть возможность разделить потоки данных, чтобы избежать циклических зависимостей и корректно отражать специфику учета в каждой системе.

Из УТ 10.3 (источник НСИ и складских документов) в УТ 11.5

НСИ (Справочники):
Банки, Валюты, Виды контактной информации, Кассы, Кассы ККМ, Контрагенты, Договоры контрагентов, Виды номенклатуры, Номенклатура, Классификатор единиц измерения, Единицы измерения, Типоразмеры упаковки, Классификатор стран мира, Организации, Подразделения, Пользователи, Физические лица, Склады, Типы цен номенклатуры.

Товародвижение (Приход):

• Поступление товаров и услуг

• Перемещение товаров

• Оприходование товаров

• Возврат товаров от покупателя

Товародвижение (Расход) и Заказы:

• Реализация товаров и услуг

• Отчет о розничных продажах (из УТ 10, если были возвраты или продажи)

• Кассовая смена

• Списание товаров

• Возврат товаров поставщику

• Комплектация номенклатуры

• Заказ покупателя

• Заказ поставщику

Денежные документы и прочее:

• Платежные поручения (входящие/исходящие)

• Кассовые ордера (приходные/расходные)

• Установка цен номенклатуры

• Счета-фактуры (выданные/полученные)

• Требование-накладная

Из УТ 11.5 (источник розничных данных) в УТ 10.3

• Отчет о розничных продажах

• Отчет о розничных возвратах

• Кассовая смена

• Заказ на перемещение

• Заказ клиента

• Реализация товаров и услуг (если она была оформлена в розничной базе)

Важно: Состав документов, передаваемых из УТ 11, может быть расширен. В нашем случае он диктовался потребностями складского учета в "старой" системе, количество объектов обмена продолжает наращиваться.

Детали реализации

Разработанный код не претендует на эталонную чистоту, но полностью работоспособен. Версии платформы и конфигураций, на которых текущий механизм работает сейчас: УТ 10.3.75.2 и УТ 11.5.25.85.

Для УТ 10.3:

1. План обмена: Создан план обмена "ОбменУправлениеТорговлейУТ10_11". Для всех участвующих объектов установлена авторегистрация = Истина.

2. HTTP-Сервис: "API" с двумя методами:

   • version — возвращает версию сервиса (используется для проверки доступности).

   • load_ut10 — точка входа для загрузки данных из УТ 11 в УТ 10.

3. Общий модуль: "ОбщегоНазначенияОбменУТ10_УТ11" — содержит всю логику выгрузки и загрузки данных.

4. Регламентное задание: "ОбменУТ11" — по расписанию отправляет зарегистрированные изменения в УТ 11.

5. Внешняя обработка: "УТ10_в_УТ11_ОтправкаДанных.epf" — для тестирования и ручной отправки.

Для УТ 11.5:

• Создано расширение с зеркально-симметричной логикой. В нем также реализованы HTTP-сервис для приема данных из УТ 10 и регламентное задание для отправки розничных данных обратно.

Настройка подключения

Предполагается, что веб-сервер (Apache или IIS) уже настроен, и обе базы опубликованы стандартным образом.

Общий принцип: Настройки подключения (адрес, пользователь, пароль, метод) указываются в элементах плана обмена.

Настройка в УТ 10.3

1. Откройте план обмена "ОбменУправлениеТорговлейУТ10_11".

2. Центральный узел: должен иметь код UT10 (менять нельзя).

3. Создайте или откройте периферийный узел с кодом UT11.

4. Заполните настройки для этого узла:

   • Адрес сервера, пользователь, пароль для доступа к базе УТ 11.

   • Имя метода: /<имя_вашей_публикации_УТ11>/hs/api/load_ut10 (например, /ut11_base/hs/api/load_ut10).

   • При необходимости укажите фильтр по организации и размер пакета.

Рис.1. Пример настройки узла обмена в УТ 10.3

Настройка в УТ 11.5

1. В расширении откройте настройки плана обмена.

2. Центральный узел: код UT11.

3. Периферийный узел: код UT10.

4. Укажите параметры подключения к базе УТ 10.3:

   • Адрес, пользователь, пароль.

   • Имя метода: /<имя_вашей_публикации_УТ10>/hs/api/load_ut11.

Рис.2. Пример настройки узла обмена в расширении для УТ 11

Управление обменом

Для отладки и разовых отправок можно использовать созданные обработки.

• Ручная отправка данных из УТ 10.3. 

(Рис.3)

• Ручная отправка данных из УТ 11.5. 

(Рис.4)

 

Особенности эксплуатации и выводы

Предложенное решение успешно эксплуатируется уже долгое время. Это позволило перевести розничные магазины с УТ10.3. на УТ11.5., не останавливая работу магазинов, основного склада и интернет-магазина.

Плюсы подхода:

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

• Гибкость. Легко добавлять новые документы и справочники в обмен по мере необходимости.

• Прозрачность. Использование HTTP-запросов упрощает мониторинг и отладку.

Минусы и ограничения:

• Код развивался эволюционно, поэтому его чистота далека от идеала. Это скорее рабочая лошадка, чем эталонный код.

• Требует аккуратности при доработках в обеих системах.

• Как шаблон подойдет под другие конфигурации, адаптация выглядит не сложной.

Материалы распространяются "как есть" (AS IS). Обновления и исправления будут выкладываться по мере дальнейшей эксплуатации. Претензии из серии "зачем это нужно" не принимаются, но конструктивная критика и предложения по улучшению приветствуются.