Рассмотрим частую задачу при интеграции баз на платформе 1С, когда в самописной или устаревшей базе-источнике данные хранятся в виде обычного текста, а в современной конфигурации-приемнике (например, 1С:Управление торговлей) для этого предусмотрен ссылочный тип. Проанализируем ситуацию: в источнике есть строковый реквизит Бухгалтер, а в приемнике — реквизит с типом ссылка на справочник ФизическиеЛица. Выясним причину, почему стандартная выгрузка здесь не работает, и разберем по шагам несколько надежных способов трансформации примитивного типа в ссылочный с помощью конфигурации «Конвертация данных 2.0» (КД 2.0).
Разберем самый стабильный и на 100% рабочий вариант, который позволяет передать строку и корректно инициализировать поиск элемента справочника. В этом методе мы программно сформируем структуру с нужными полями и передадим её в правило конвертации.
ФизическиеЛица).Наименование. Оставим источник пустым, а в настройках ПКС установим флажок Получить из входящих данных и укажем, что по этому полю нужно выполнять поиск.Контрагенты). Источником укажем строковый реквизит, а приемником — реквизит с типом справочник. Укажем созданное на первом шаге ПКО.
Значение = СокрЛП(Источник); // Убираем лишние пробелы из строки
ИсходящиеДанные = Новый Структура("Наименование", Значение);
Для повышения отказоустойчивости правил дополним наш код проверками типов. Посмотрим на пример, который предотвращает ошибки, если глобальная переменная уже была инициализирована:
Значение = СокрЛП(Источник);
Если ТипЗнч(ИсходящиеДанные) <> Тип("Структура") Тогда
ИсходящиеДанные = Новый Структура;
КонецЕсли;
ИсходящиеДанные.Вставить("Наименование", Значение);
Рассмотрим более простой подход, который не требует создания структур. Он подойдет для базовых задач, где поиск ведется строго по одному строковому полю.
Наименование (источник пустой) в обработчик Перед выгрузкой поместим код прямого присвоения:
Значение = Источник;
Обратим внимание, что в данном случае платформа попытается напрямую подставить пришедшую строку в реквизит наименования создаваемого или искомого объекта.
Разберем еще один изящный метод, позволяющий избежать написания обработчиков. В настройках ПКС (где вы передаете строку в ссылку) можно использовать встроенное поле Выражение. Пропишем в него следующее:
Выражение = "Источник";
Алгоритм КД автоматически вычислит это выражение при формировании узла XML и передаст результат как значение реквизита. Это иногда помогает обойти ограничения встроенных обработок.
Проанализируем частые ошибки, из-за которых элементы не создаются, задваиваются или перезаписывают друг друга.
1. Очистка строки от скрытых символов. Если в исходной базе пользователи ввели строку с лишними пробелами (например, «Иванов И.И. »), алгоритм не найдет совпадение в приемнике и создаст дубль. Всегда используйте функцию СокрЛП() для форматирования текстового значения перед передачей в Значение или ИсходящиеДанные.
2. Защита от создания пустых элементов. Если реквизит-строка в источнике не заполнен, КД отработает правило и создаст в базе-приемнике пустую карточку справочника (без наименования). Чтобы избежать появления "мусора", обязательно проверяйте входящие данные. В обработчике ПКС пропишем защиту:
Если ПустаяСтрока(Источник) Тогда
Отказ = Истина; // Прерываем конвертацию этого свойства
КонецЕсли;
3. Отключение приоритета поиска по уникальному идентификатору (УИД). Это самая распространенная проблема (описана в сообщении 13 исходной темы). По умолчанию алгоритмы КД всегда пытаются искать объекты по внутреннему идентификатору. Так как у обычной строки нет УИДа, система может генерировать некорректные ссылки, из-за чего записи, например, в регистрах сведений начинают перезаписывать друг друга (из 10 000 записей остается только 10). Запомните правило: для ПКО конвертации строки в справочник обязательно снимайте флажок поиска по уникальному идентификатору. Поиск должен идти исключительно по строковому полю (наименованию).
4. Ограничения зарезервированных имен. При передаче структур в ИсходящиеДанные избегайте использования ключа Имя. В типовой обработке УниверсальныйОбменДаннымиXML есть системный код, который некорректно перехватывает это свойство, что ломает алгоритм поиска. Всегда используйте стандартные имена реквизитов (например, Наименование, Код, Артикул).
5. Проблема полных тезок. Поиск физических лиц или контрагентов только по ФИО (по одной строке) рискован. Если в базе попадутся полные тезки, при загрузке система склеит их в одну карточку справочника. Если в источнике есть дополнительные идентификаторы (табельный номер, ИНН, дата рождения, хранящиеся в соседних реквизитах), передавайте их в структуру ИсходящиеДанные совместно с наименованием и настраивайте поиск по нескольким полям. Правила КД автоматически объединят условия поиска оператором логического «И».
Рассмотрим применение описанных подходов, если вашей базой-приемником является современная редакция УТ 11, ERP или КА, где настроен обмен в формате EnterpriseData (КД 3.0). Учтем, что логика, построенная на ПКО и ПКС из КД 2.0, здесь работать не будет напрямую.
В универсальном формате обмена конвертация строки в ссылку реализуется программно на стороне базы-приемника. Строка из источника помещается в универсальный XDTO-пакет как обычный строковый параметр. А уже в самой базе УТ 11, в общих модулях загрузки данных (например, ОбменДаннымиXDTOСервер), мы пропишем алгоритм, который прочитает пришедшую строку, выполнит запрос к базе (поиск по наименованию справочника) и подставит найденную ссылку в нужный реквизит документа или справочника. Если элемент не найден — код должен будет инициировать программное создание нового объекта.