Перенос данных из классических конфигураций, таких как УПП 1.3 или КА 1.3, в современные системы на базе 1С:ERP или КА 2.5 — это сложная техническая задача. В процессе миграции часто возникают ошибки, связанные с изменением структуры данных, архитектурой управляемых форм и жесткими проверками при записи объектов. Рассмотрим, как систематизировать работу с правилами конвертации и устранить типичные проблемы.
Главная трудность при поддержке обменов — это попытка объединить правила поставщика со своими доработками. Когда вы используете обработку «Сравнение и объединение правил обмена», помните, что она ориентирована на сравнение XML-структур. Ошибки вида Значение поля \"Код\" не уникально возникают из-за конфликта внутренних идентификаторов GUID в метаданных КД. Рекомендуем использовать эту обработку только для анализа изменений, а для переноса своих наработок — создавать новую конвертацию, постепенно перенося в нее нужные ПКО и ПКС.
Ошибки при выполнении кода в обработчиках конвертации часто связаны с попыткой проверить объект, который не поддерживает проверку на заполненность (мутабельные типы). Избегайте использования ЗначениеЗаполнено(Объект) для ссылок. Вместо этого всегда обращайтесь к свойству Ссылка:
Если ЗначениеЗаполнено(Объект.Ссылка) Тогда
// Действия с объектом
КонецЕсли;
Если вы работаете с COM-соединением, проверяйте его доступность через идентификаторы или методы, возвращающие булево значение, не пытаясь вызвать стандартные функции платформы для проверки ссылочных типов.
Для корректной передачи подчиненных документов, таких как СчетФактураПолученный, недостаточно просто создать правило. Необходимо управлять моментом выгрузки из ПКО документа-основания. В обработчике «Перед выгрузкой» используйте следующий подход:
Значение = мвДоработки.НайтиПодчиненныйДокумент(Источник, "СчетФактураПолученный");
Если Значение = Неопределено Тогда
Отказ = Истина;
КонецЕсли;
Этот код гарантирует, что Счет-фактура будет выгружен только в том случае, если он существует для конкретного документа-основания ПриобретениеТоваровУслуг.
В КА 2.5 логика учета серий значительно усложнилась. Если в интерфейсе недоступны галочки Серии или Есть индивидуальные настройки политики учета серий, проверьте настройки «НСИ и администрирование». Часто ограничение связано с использованием Маркировки или Ордерной схемы. Не пытайтесь принудительно менять свойства через запись объекта, так как конфигурация сбросит их при проверке валидности.
Чтобы избежать создания дублей Видов номенклатуры при миграции, используйте механизм поиска по части наименования в ПКС:
Если НомерВариантаПоиска = 1 тогда
СтрокаИменСвойствПоиска = "Наименование";
Иначе
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ первые 1 Ссылка ИЗ Справочник.ВидыНоменклатуры ГДЕ Наименование ПОДОБНО &Параметр";
Запрос.УстановитьПараметр("Параметр", "%НаименованиеБезПостфикса%");
// Обработка результатов...
КонецЕсли;
Объект.Ссылка при работе с данными в ПКО.КА 2.5 многие документы были заменены регистрами расчетов или справочниками ОбъектыРасчетов.Товары и фильтруя записи по наличию серий в реквизитах.Ошибка преобразования данных XDTO, убедитесь, что вы не передаете ТаблицуЗначений напрямую — преобразуйте её в массив структур перед передачей в ИсходящиеДанные.Работа с КД 2.0 в связке с КА 2.5 требует внимательного отношения к обработчикам событий. Вместо изменения типовых правил, лучше использовать события «Перед выгрузкой» для изменения параметров выгружаемого объекта «на лету» — это обеспечит стабильность при будущих обновлениях конфигурации.