Работа с механизмом «1С:Конвертация данных 2.0» (КД 2.0) обычно подразумевает использование специализированной конфигурации. Однако в практике программиста 1С нередко возникают ситуации, когда необходимо оперативно внести изменения в файл правил xml без возможности загрузки их в базу КД. Разберем подробно, какие теги в структуре файла отвечают за логику синхронизации, замещения и создания объектов, и как правильно их корректировать в текстовом редакторе. В качестве альтернативы ручной правке XML можно использовать специализированный редактор правил обмена КД 2.
Все настройки, касающиеся того, как объект должен вести себя при загрузке в базу-приемник, хранятся внутри узла ПравилаКонвертацииОбъектов (ПКО). Если мы откроем файл правил через «Блокнот» или Notepad++, мы увидим блоки, описывающие каждый справочник или документ. Проанализируем основные теги, которые регулируют обновление данных:
НеЗамещать. Этот тег определяет, будут ли обновлены реквизиты объекта в приемнике, если он был найден.
true — система найдет объект, но не будет перезаписывать его поля (загрузка «только для новых»).false или тег отсутствует — система полностью обновит объект данными из источника.НеСоздаватьЕслиНеНайден. Отвечает за появление новых записей.
true полезно, когда нужно обновить только те элементы, которые уже существуют в приемнике, не засоряя справочник новыми данными.false (по умолчанию) — если поиск не дал результатов, будет создан новый объект.Посмотрим на пример структуры ПКО в XML-файле, где включено замещение и разрешено создание новых элементов:
<Правило>
<Код>Номенклатура</Код>
<Наименование>Справочник: Номенклатура</Наименование>
<Порядок>50</Порядок>
<НеЗамещать>false</НеЗамещать>
<НеСоздаватьЕслиНеНайден>false</НеСоздаватьЕслиНеНайден>
...
</Правило>
Одной из самых частых проблем при ручной правке является настройка идентификации. Проанализируем, как система понимает, какой объект перед ней. В КД 2.0 существует два основных пути: поиск по внутреннему идентификатору (GUID) и поиск по полям (например, по Коду или ИНН). За это отвечают следующие теги:
СинхронизироватьПоИдентификатору: Если стоит true, 1С в первую очередь попытается сопоставить объекты по их уникальному идентификатору UUID. Это самый надежный способ, если базы имеют общую историю.
ПродолжитьПоискПоПолямПоискаЕслиПоИдентификаторуНеНашли: Этот флаг критически важен. Если поиск по GUID провалился, система перейдет к анализу полей, у которых в ПКС (Правилах Конвертации Свойств) установлен атрибут Поиск="true". Подробнее о тонкостях такого сценария можно прочитать в материале с нюансами сопоставления объектов в КД 2 без поиска по идентификатору.
Разберем ситуацию из практики: вам нужно, чтобы поиск шел исключительно по Коду, игнорируя GUID. В этом случае в XML необходимо выставить:
СинхронизироватьПоИдентификатору — false.ПродолжитьПоискПоПолямПоискаЕслиПоИдентификаторуНеНашли — true.Поиск="true".Рассмотрим важный аспект, который часто путает разработчиков при анализе не файлов правил, а файлов выгрузки данных. В сообщениях форума упоминался атрибут Нпп (Номер по порядку). Это внутренний механизм оптимизации 1С:
Когда объект (например, Контрагент) выгружается в файл первый раз, ему присваивается уникальный номер Нпп. Если этот же Контрагент встречается в файле еще раз (как реквизит документа или владелец карты), система не пишет его данные снова. Она записывает короткую ссылку вида:
<Ссылка Нпп="12">
Важное предостережение: Никогда не пытайтесь вручную менять номера Нпп в файле данных. Это приведет к тому, что загрузчик либо не найдет объект, либо подставит вместо него другой, который шел под этим номером ранее в потоке XML. Если при загрузке вы видите, что «ВладелецКарты» у всех объектов становится одинаковым, скорее всего, в файле данных сбита логика ссылок по Нпп или неверно настроены правила поиска владельца.
Хотя правка «блокнотом» кажется быстрой, мы рекомендуем придерживаться стандартной методики, чтобы избежать нарушения структуры XML. Выясним причины, по которым правила могут «не лезть обратно» в Конвертацию данных: это либо нарушение вложенности тегов, либо отсутствие служебных узлов с описанием метаданных.
Рассмотрим шаги для безопасного редактирования:
MD82Exp.epf.Если же доступа к КД нет, и вы правите XML вручную, обязательно проверяйте закрывающие теги. Например, тег <НеЗамещать>true</НеЗамещать> должен быть удален полностью или изменен на false. Простое удаление значения внутри тега может привести к ошибке чтения файла.
Существует еще один тег, который редко упоминается, но бывает крайне полезен: ЗамещатьТолькоПустыеРекурсивно. Если установить его в true, система будет работать в «щадящем» режиме: она заполнит только те реквизиты объекта в приемнике, которые на данный момент не заполнены (равны пустой ссылке или нулю). Это позволяет дополнять данные, не затирая ручные правки пользователей в базе-приемнике.
Проанализировав эти параметры, мы видим, что гибкость КД 2.0 позволяет настроить практически любой сценарий синхронизации. Главное — четко понимать, какой именно приоритет поиска выбран (GUID или поля) и какой флаг замещения установлен в правилах. Когда правила обмена на основе XML-файлов полностью подготовлены, для автоматического выполнения синхронизации по расписанию без изменения конфигураций можно задействовать программу для регулярного обмена данными между базами 1С.