Как исправить появление битых ссылок "(GUID из источника)" при обмене данными в 1С?

← На главную

При настройке синхронизации данных между различными конфигурациями 1С (например, между «Управление нашей фирмой» и «Бухгалтерия предприятия») разработчики и администраторы часто сталкиваются с неприятной ситуацией. Мы создаем новый элемент справочника (например, Номенклатура), добавляем его в табличную часть нового документа (например, РасходнаяНакладная), запускаем обмен, но в базе-приемнике вместо правильного наименования номенклатуры видим пустую ссылку с текстом: (GUID из источника) или <Объект не найден> (GUID). При этом сам справочник в базу-приемник перенесся успешно, а повторный обмен полностью решает проблему. Почему так происходит и как исправить этот сбой раз и навсегда? Разберем эту проблему подробно по шагам.

Физика процесса: почему возникают битые ссылки первого прохода?

Давайте проанализируем, как устроен механизм сериализации и десериализации данных при стандартном обмене XML. База-источник формирует единый файл выгрузки, в который последовательно записывает XML-узлы объектов. База-приемник читает этот файл последовательно, сверху вниз.

Рассмотрим сценарий, когда в XML-файле документ идет раньше, чем справочник:

Приемник считывает узел документа РасходнаяНакладная. В табличной части он видит ссылку на элемент справочника Номенклатура с определенным уникальным идентификатором (GUID).
Приемник пытается найти эту номенклатуру в своей базе данных (включая регистр сведений СоответствиеОбъектовДляОбмена). Но так как этот элемент еще не был загружен из файла, поиск завершается неудачей.
Платформа 1С не прерывает загрузку документа из-за отсутствующей ссылки. Вместо этого она создает так называемую «битую» (или фиктивную) ссылку. Документ записывается в базу данных с этой битой ссылкой.
Затем парсер XML спускается ниже по файлу и доходит до узла справочника Номенклатура. Номенклатура успешно создается, её GUID прописывается в регистре соответствия. Но документ уже записан, и платформа автоматически не обновляет его табличную часть в этот момент.
При повторном обмене, когда мы снова регистрируем и выгружаем документ, база-приемник на шаге 1 уже находит созданную ранее номенклатуру в своей базе и успешно подставляет её.

Если же объекты выгружаются в правильном порядке (сначала справочник Номенклатура, а затем документ РасходнаяНакладная), приемник сначала создает номенклатуру, а при чтении документа мгновенно находит её и подставляет без каких-либо ошибок. Именно поэтому с ПриходнойНакладной у автора сообщения проблем не возникало — ее правила или регистрация обеспечивали верный порядок выгрузки.

Как исправить порядок выгрузки в Конвертации данных 2.1

Рассмотрим несколько эффективных способов решения этой проблемы, начиная с настройки правил обмена и заканчивая программными методами.

Способ 1. Изменение порядка Правил выгрузки данных (ПВД)

В конфигурации «Конвертация данных 2.1» последовательность выгрузки объектов в XML-файл напрямую зависит от порядка расположения правил в дереве ПВД. Выполним следующие действия:

Откроем правила обмена в конфигурации «Конвертация данных».
Перейдем на вкладку Правила выгрузки данных (ПВД).
Найдем в списке правило для справочника Номенклатура и правила для документов РасходнаяНакладная и ПриходнаяНакладная.
С помощью стрелок «Переместить вверх» на панели инструментов поднимем правило выгрузки номенклатуры как можно выше. Рекомендуется располагать все ПВД справочников (особенно базовых: Номенклатура, Контрагенты, Договоры контрагентов) выше правил выгрузки документов.
Сохраним правила и загрузим их в наши базы данных.

Этот простой шаг гарантирует, что при формировании файла обмена платформа сначала обработает выборку справочников и запишет их в XML-файл первыми.

Способ 2. Программная принудительная выгрузка связанных объектов в ПКО

Что делать, если обмен идет по плану обмена, и объекты регистрируются динамически, из-за чего порядок ПВД не всегда срабатывает идеально? Мы можем принудительно выгрузить номенклатуру непосредственно в момент выгрузки самого документа.

Для этого в ПКО (Правила конвертации объектов) для документа РасходнаяНакладная напишем обработчик события «Перед выгрузкой». Выполним выгрузку связанных элементов номенклатуры из табличной части до того, как начнется запись документа:


// Проверим наличие табличной части и выгрузим номенклатуру принудительно
Если Источник.Товары.Количество() > 0 Тогда
    Для Каждого СтрокаТЧ Из Источник.Товары Цикл
        Если ЗначениеЗаполнено(СтрокаТЧ.Номенклатура) Тогда
            // Выгружаем номенклатуру по правилу конвертации "Номенклатура"
            ВыгрузитьПоПравилу(СтрокаТЧ.Номенклатура, , , , "Номенклатура");
        КонецЕсли;
    КонецЦикла;
КонецЕсли;

Метод ВыгрузитьПоПравилу запишет данные всех номенклатурных позиций из документа в XML-поток раньше самого документа. При загрузке в базу-приемник эти объекты уже будут существовать в базе к моменту чтения табличной части накладной.

Способ 3. Проверка настроек выгрузки по ссылкам в ПКО

Иногда проблема кроется в том, что для справочника отключена выгрузка по ссылке. Проанализируем настройки ПКО для справочника Номенклатура:

В «Конвертации данных» откроем ПКО справочника Номенклатура.
Убедимся, что на вкладке «Параметры» или в свойствах конвертации свойств (ПКС) документа не стоит флаг «Не выгружать объекты свойств источника по ссылкам».
Если этот флаг установлен, то при выгрузке документа ссылка на номенклатуру уходит только в виде GUID (без реквизитов наименования, кода и т.д.). В приемнике создается пустой элемент, который мы и видим как "битый". Снимите этот флаг, чтобы объект выгружался полностью при первой же ссылке на него.

Способ 4. Использование механизмов БСП и отложенного заполнения

В современных конфигурациях 1С, использующих Библиотеку стандартных подсистем (БСП), реализованы встроенные механизмы борьбы с битыми ссылками. Выясним, почему они могут не работать в вашем случае:

Отложенное проведение документов: БСП умеет ставить документы в специальную очередь. Если при загрузке документа обнаруживается незагруженная ссылка, БСП откладывает проведение документа до завершения сеанса обмена, когда все справочники будут гарантированно загружены, а затем пытается провести его повторно. Убедитесь, что в правилах обмена в обработчике «После загрузки» не прописан принудительный отказ от отложенного проведения.
Переход на формат EnterpriseData: Если вы используете актуальные версии конфигураций (например, УНФ 3.0 и БП 3.0), настоятельно рекомендуем отказаться от старых правил КД 2.1 и перейти на обмен через универсальный формат данных (КД 3.0). В нем проблема битых ссылок решена на уровне платформы за счет регистра сведений ПубличныеИдентификаторыСинхронизируемыхОбъектов. Платформа автоматически создает временные «фиктивные» элементы и корректно связывает их при последующем получении полных данных объекта.

Применяя эти методы настройки правил и конфигурации, мы полностью избавимся от проблемы появления битых ссылок при первой синхронизации документов.