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