Работа с инструментом «1С:Конвертация данных 2.1» (КД 2.1) часто преподносит сюрпризы, особенно когда речь идет о переносе данных через планы обмена. Одной из самых распространенных проблем является ситуация, когда основной объект (например, документ) переносится корректно, а связанные с ним справочники создаются в базе-приемнике «пустыми» — заполнен только код или наименование, а остальные реквизиты отсутствуют. Кроме того, часто возникает вопрос: почему документы после загрузки остаются непроведенными, хотя в источнике они имели статус «Проведен»?
В этой статье мы подробно разберем внутренние механизмы КД 2.1, выясним причины такого поведения системы и научимся правильно настраивать правила обмена и регистрации данных.
Проанализируем ситуацию, описанную пользователями: справочник сам по себе перегружается полностью, но при переносе в составе документа создается лишь «заглушка». Рассмотрим, почему так происходит.
В типовых обменах, работающих через планы обмена, реализована оптимизация трафика. Когда вы регистрируете документ к выгрузке, система анализирует его реквизиты. Если справочник (например, Контрагенты или Номенклатура), на который ссылается документ, не зарегистрирован на узле плана обмена отдельно, платформа выгружает его «по ссылке». Это означает, что в файл обмена попадает только Уникальный Идентификатор (GUID) и поля поиска (код, ИНН), но не весь набор реквизитов.
Основные причины частичного переноса:
Решение задачи: Чтобы справочники всегда переносились полностью вместе с документами, можно использовать так называемый «финт ушами» — настроить Правила регистрации данных. В них для документа прописывается алгоритм, который при регистрации документа автоматически добавляет в очередь на выгрузку и все связанные с ним справочники. Таким образом, в пакет данных попадет полная информация об объекте.
Многие разработчики сталкиваются с тем, что документы загружаются в статусе «Записан», но не «Проведен». Выясним причину этого поведения, скрытую в недрах платформы 1С.
При загрузке данных через стандартные обработки обмена (например, ОбменДаннымиXML) для загружаемых объектов устанавливается свойство: Объект.ОбменДанными.Загрузка = Истина;. Рассмотрим последствия установки этого флага:
ПередЗаписью и ПриЗаписи игнорируются практически все проверки.ОбработкаПроведения не вызывается вовсе.Чтобы заставить документы проводиться, мы можем пойти двумя путями. Первый — проведение в обработчике ПКО «После загрузки». Это выглядит так:
Если Объект.Проведен Тогда
Попытка
Объект.Записать(РежимЗаписиДокумента.Проведение);
Исключение
Сообщить("Ошибка проведения: " + ОписаниеОшибки());
КонецПопытки;
КонецЕсли;
Однако этот метод имеет существенный минус: если документ ссылается на другой объект, который еще не загружен в текущем потоке, проведение завершится ошибкой.
Рекомендуемый подход: использование глобального обработчика правил конвертации «После загрузки всех объектов». Рассмотрим алгоритм:
ПослеЗагрузки мы не проводим документ, а добавляем его ссылку в специальный массив (параметр).ПослеЗагрузкиВсехОбъектов мы перебираем этот массив и программно проводим все накопленные документы.Пример кода в обработчике «После загрузки всех объектов»:
// Предположим, ссылки на документы мы собирали в таблицу значений или массив "СписокДокументовНаПроведение"
Для Каждого СсылкаДок Из Параметры.СписокДокументовНаПроведение Цикл
ДокОбъект = СсылкаДок.ПолучитьОбъект();
Если ДокОбъект <> Неопределено И ДокОбъект.Проведен Тогда
ДокОбъект.Записать(РежимЗаписиДокумента.Проведение, РежимПроверкиЗаполнения.НеПроверять);
КонецЕсли;
КонецЦикла;
Рассмотрим еще один важный аспект, упомянутый в обсуждении — использование НомерВариантаПоиска. Это крайне полезная функция, когда данные в двух базах «грязные» и сопоставить их по одному лишь коду невозможно.
Посмотрим на пример реализации поиска по разным наборам полей в обработчике «Поля поиска»:
Если НомерВариантаПоиска = 1 Тогда
// Пытаемся найти по уникальному сочетанию ИНН + КПП + Код
СтрокаИменСвойствПоиска = "ИНН,КПП,Код";
ИначеЕсли НомерВариантаПоиска = 2 Тогда
// Если не нашли, пробуем по ИНН и Наименованию
СтрокаИменСвойствПоиска = "ИНН,Наименование";
ИначеЕсли НомерВариантаПоиска = 3 Тогда
// Крайний случай - только по коду
СтрокаИменСвойствПоиска = "Код";
КонецЕсли;
Проанализируем ситуацию: платформа запускает цикл поиска (до 10 итераций). На каждой итерации переменная НомерВариантаПоиска увеличивается на 1. Как только СсылкаНаОбъект становится заполненной, цикл прекращается. Это позволяет гибко настроить логику «схлопывания» дублей при обмене.
Некоторые опытные специалисты предпочитают править XML-файл правил напрямую в блокноте. Рассмотрим, почему это опасно для структуры КД 2.1:
CDATA. При случайном удалении тегов или нарушении кодировки правила перестанут загружаться в обработку обмена.ID для связи ПКО и ПВД. При ручном копировании узлов легко создать дубликаты ID, что приведет к непредсказуемому поведению: например, данные будут пытаться записаться не в те реквизиты.Если...Тогда, и ошибка выяснится только в момент выполнения обмена на реальных данных.Вывод: Для стабильной работы обмена всегда используйте конфигурацию «Конвертация данных» для внесения изменений. Если нужно найти «кусочек кода», как выразился автор темы, загрузите правила в КД, воспользуйтесь поиском и выгрузите их обратно.
ПослеЗагрузкиВсехОбъектов, чтобы избежать ошибок блокировок и отсутствующей НСИ.НомерВариантаПоиска для настройки надежного сопоставления объектов.Помните, что качественная настройка обмена требует понимания жизненного цикла объекта от момента выгрузки до финальной записи в базу-приемник. Тщательно проанализируйте каждый этап, и ваши данные всегда будут в актуальном и проведенном состоянии.