При переходе с устаревших конфигураций на платформе 1С:Предприятие 8.2 (использующих обычные формы) на современные решения на платформе 8.3 (управляемые формы), специалисты часто сталкиваются с вопросом: какую версию программного продукта «Конвертация данных» (КД) использовать? Существует мнение, что более новая версия КД 3.0 предпочтительнее, однако технические реалии диктуют свои правила.
В этой статье мы подробно проанализируем ситуацию, разберем фундаментальные различия в технологиях обмена и выясним, почему для систем на базе 8.2 классическая версия КД 2.1 остается единственным рациональным выбором.
Для начала разберем, чем концептуально отличаются эти два инструмента. Понимание этих различий поможет избежать критических ошибок еще на этапе проектирования обмена.
СправочникСсылка.Номенклатура из старой базы должна превратиться в СправочникСсылка.Номенклатура в новой базе с соответствующим сопоставлением реквизитов. Это идеальный вариант для разового переноса остатков, документов и справочной информации.EnterpriseData. Здесь логика иная: база-источник преобразует свои данные в некий «общий язык» (универсальный формат), а база-приемник считывает этот формат и создает объекты у себя.Проанализируем ситуацию пользователя: имеется база на 8.2 (обычные формы), которую нужно выгрузить в 8.3. Использование КД 3.0 в данном случае наталкивается на серьезные технические барьеры.
Рассмотрим подробнее технические ограничения, которые делают использование третьей версии КД для старых систем практически невозможным или крайне трудозатратным:
1. Отсутствие поддержки EnterpriseData в старых конфигурациях.
Для того чтобы КД 3.0 заработала, в конфигурации-источнике должен быть реализован механизм работы с форматом EnterpriseData. В типовых решениях на 8.2 (таких как УПП 1.3 или Бухгалтерия предприятия 2.0) этого механизма «из коробки» не существует. Его внедрение потребует колоссальной доработки программного кода.
2. Зависимость от Библиотеки стандартных подсистем (БСП).
Механизмы КД 3.0 тесно интегрированы с современными версиями БСП (начиная с 2.3 и выше). В системах на 8.2 либо используется очень старая версия БСП, либо она отсутствует вовсе. Попытка «подружить» логику КД 3.0 со старой базой приведет к необходимости написания огромного количества кода вручную в Модуле менеджера обмена.
3. Программные интерфейсы и XDTO.
Платформа 8.2 имеет ограничения при работе с современными XDTO-пакетами. Многие методы, на которые полагается код, генерируемый КД 3.0, просто не реализованы в старых версиях платформы. Это вызовет ошибки времени выполнения при попытке выгрузки данных.
Выясним, почему для нашей задачи (выгрузка из 8.2 в 8.3) КД 2.1 является оптимальным решением. Процесс работы в этом случае выглядит следующим образом:
MD82Exp.epf.EnterpriseData, мы можем свободно описывать логику преобразования объектов в специальных обработчиках событий, таких как ПередВыгрузкой, ПриВыгрузке или ПоляПоиска.Рассмотрим пример кода, который часто используется в КД 2.1 для трансформации данных при переходе со старых систем. Например, если в базе 8.2 у нас был реквизит типа Число, а в 8.3 он стал типом ПеречислениеСсылка, мы легко можем написать обработчик в правилах (ПКО):
// Пример обработчика "Перед выгрузкой" в КД 2.1
Если Источник.Статус = 1 Тогда
Значение = "Активен";
ИначеЕсли Источник.Статус = 2 Тогда
Значение = "Заблокирован";
КонецЕсли;
Такая гибкость позволяет быстро адаптировать данные старой базы под структуру новой конфигурации без изменения программного кода самих баз. В случае с КД 3.0 весь этот код пришлось бы писать внутри конфигурации, что усложняет поддержку и обновление.
Проанализировав технические возможности обеих версий инструментария, мы можем дать следующие рекомендации:
EnterpriseData и ваша цель — выстроить постоянную синхронизацию в рамках единой экосистемы 1С.Таким образом, несмотря на то что прямой связи между версией КД и наличием управляемых форм нет, программная среда 8.2 диктует использование КД 2.1 как наиболее стабильного и экономически эффективного инструмента для миграции данных.