← На главную

В процессе работы с информационными системами 1С часто возникает необходимость связать между собой конфигурации разных версий, например, «старую» УТ 11.4 и актуальную УНФ. Многим кажется, что обновление отдельных объектов Универсального формата обмена (EnterpriseData) — это быстрый способ решить задачу. Давайте проанализируем, почему этот путь является тупиковым и как правильно подойти к интеграции систем.

Почему не стоит обновлять объекты универсального формата точечно?

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

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

Реализация обмена с использованием КД 2.0

Наиболее надежный и инженерно верный способ решения задачи в условиях ограниченного бюджета или невозможности полного обновления — это использование механизма Конвертации Данных 2.0 (КД 2.0). В отличие от EnterpriseData, КД 2.0 позволяет гибко настраивать правила переноса для конкретных объектов.

Рассмотрим шаги для реализации этой стратегии:

1. Создание собственного плана обмена: Не пытайтесь использовать типовые планы обмена (например, РИБ или предопределенные обмены БСП), так как они имеют жесткую привязку к конфигурации. Лучшим решением будет создание нового плана обмена через конфигуратор. Это обеспечит чистоту данных и независимость от обновлений основной конфигурации.
2. Настройка состава обмена: В режиме 1С:Предприятие в новом плане обмена настройте регистрацию только необходимых объектов: справочников (контрагенты, номенклатура) и документов (Заказы клиентов, Заказы поставщиков). Это позволит избежать передачи лишней информации и уменьшить объем сообщений.
3. Разработка правил конвертации: Используйте внешнюю обработку Конвертация данных 2.1 для создания правил. Это позволит вам мапить реквизиты старой УТ на новую УНФ без изменения структуры метаданных самой конфигурации.

Передача файлов (PDF) между базами

Частый вопрос при обмене — как передать печатные формы. Важно помнить: не пытайтесь передавать файлы через сам план обмена. Это критически увеличит объем XML-сообщений и замедлит работу системы.

Рекомендуем придерживаться следующей архитектуры передачи PDF-файлов:

• Создайте в УТ 11.4 регламентное задание, которое после установки статуса Завершен для самописного документа формирует печатную форму и сохраняет её в справочник ПрисоединенныеФайлы.
• Передавайте через обмен только УникальныйИдентификатор файла или ссылку на него.
• Для физической передачи файла используйте механизм HTTP-сервисов. На стороне УНФ опубликуйте сервис, который будет принимать бинарные данные файла и записывать их в нужный заказ.

Подводим итоги

При интеграции систем разных версий всегда выбирайте путь, который сохраняет целостность конфигурации. Использование КД 2.0 и собственных планов обмена позволяет вам:

1. Сохранить работоспособность старой конфигурации без опасных правок метаданных.

2. Получить полный контроль над тем, какие данные передаются между базами.

3. Минимизировать риски возникновения ошибок при будущих обновлениях или техническом обслуживании систем.

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