Как исправить битые ссылки в поступлении при синхронизации УТ 11 и БП 3.0?

← На главную

При настройке регулярного обмена данными между конфигурациями «1С:Управление торговлей» (ред. 11) и «1С:Бухгалтерия предприятия» (ред. 3.0) технические специалисты часто сталкиваются со следующей проблемой: после успешной, казалось бы, синхронизации в табличной части загруженных документов (например, «Поступление товаров и услуг») вместо реальных наименований товаров отображаются битые ссылки вида <Объект не найден> (83:9881005056с0015511e7...).

В этой статье мы подробно разберем, почему возникает эта ошибка, рассмотрим внутренние механизмы платформы 1С на базе КД 3 (EnterpriseData) и изучим несколько эффективных способов решения проблемы — от простых ручных манипуляций до полной автоматизации процесса восстановления соответствий.

Давайте разберем эту ситуацию по шагам.

Выясняем причину: почему возникают битые ссылки?

В старых версиях обмена (на базе технологии «Конвертация данных 2.0») поиск объектов при загрузке происходил непосредственно по полям поиска — например, по артикулу, коду или наименованию. Если объект не находился в базе-приемнике, система создавала его с нуля на основании переданных реквизитов.

В современных конфигурациях, использующих технологию «Конвертация данных 3.0» (формат EnterpriseData), логика кардинально изменилась. Связь между объектами в базах-участниках синхронизации теперь фиксируется в специальных служебных таблицах. За это отвечают:

РегистрСведений.СоответствияОбъектовИнформационныхБаз — хранит явную карту сопоставления между ссылкой в текущей базе и уникальным идентификатором (UUID) в другой базе.
РегистрСведений.ПубличныеИдентификаторыСинхронизируемыхОбъектов — фиксирует соответствия для обмена через формат EnterpriseData.

Алгоритм оптимизации обмена работает следующим образом:

Когда документ регистрируется к обмену в базе-источнике (УТ 11), система проверяет всю связанную с ним номенклатуру по регистрам соответствий.
Если система «видит», что определенная позиция номенклатуры уже выгружалась ранее (запись в регистре соответствий существует), она считает, что в базе-приемнике (БП 3.0) эта карточка товара гарантированно есть.
В целях жесткой экономии объема XML-файла обмена, система помещает в пакет данных только ссылку (GUID) номенклатуры, исключая все её реквизиты (наименование, артикул, ставку НДС, единицу измерения).
Если в базе-приемнике этот товар был по какой-то причине удален (например, при ручной чистке дублей, сворачивании базы, или если базу БП 3.0 «откатили» из бэкапа на дату, когда товара еще не существовало), программа загрузки получает только «голый» GUID. Создать полноценную карточку товара база-приемник не может, так как у нее нет данных. Как результат — в документе проводится битая ссылка.

Рассмотрим подробнее способы решения этой проблемы.

Способ 1. Принудительная повторная регистрация номенклатуры в источнике

Самый быстрый локальный способ вернуть «потерянные» данные — заставить базу-источник (УТ 11) выгрузить полную информацию по проблемным позициям номенклатуры.

Для этого нам необходимо зарегистрировать данные объекты на узле плана обмена вручную. Проанализируем, как это сделать:

В базе УТ 11 перейдите в раздел Администрирование — Синхронизация данных.
Откройте состав зарегистрированных изменений для вашего плана обмена с Бухгалтерией.
Найдите в дереве объектов справочник Номенклатура.
Добавьте в список регистрации те позиции, которые отображаются в БП 3.0 как битые ссылки.
Запустите синхронизацию. Принудительно зарегистрированные объекты выгрузятся со всеми своими свойствами (наименование, код и т.д.), и в базе БП 3.0 битые ссылки автоматически «склеятся» с вновь созданными карточками товаров.

Способ 2. Программная очистка «битых» соответствий в базе-приемнике

Если база-приемник часто восстанавливается из резервных копий или в ней регулярно удаляют дубли, регистры сопоставления объектов забиваются неактуальными записями. В таком случае правильным решением будет полная очистка записей, ссылающихся на несуществующие элементы.

Напишем небольшую обработку для базы-приемника (БП 3.0), которая выявит «мертвые» связи в регистре сведений СоответствияОбъектовИнформационныхБаз.

Посмотрим на пример кода для поиска и удаления записей с битыми ссылками:


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	Соответствия.УзелИнформационнойБазы КАК Узел,
    |	Соответствия.СобственнаяСсылка КАК СобственнаяСсылка,
    |	Соответствия.УникальныйИдентификаторИсточника КАК ИдентификаторИсточника
    |ИЗ
    |	РегистрСведений.СоответствияОбъектовИнформационныхБаз КАК Соответствия
    |ГДЕ
    |	Соответствия.СобственнаяСсылка.Ссылка ЕСТЬ NULL
    |	И НЕ Соответствия.СобственнаяСсылка = ЗНАЧЕНИЕ(Справочник.Номенклатура.ПустаяСсылка)";

Выборка = Запрос.Выполнить().Выбрать();

Пока Выборка.Следующий() Цикл
    // Удаляем некорректную запись сопоставления
    НаборЗаписей = РегистрыСведений.СоответствияОбъектовИнформационныхБаз.СоздатьНаборЗаписей();
    НаборЗаписей.Отбор.УзелИнформационнойБазы.Установить(Выборка.Узел);
    НаборЗаписей.Отбор.СобственнаяСсылка.Установить(Выборка.СобственнаяСсылка);
    
    НаборЗаписей.Прочитать();
    Если НаборЗаписей.Количество() > 0 Тогда
        НаборЗаписей.Очистить();
        НаборЗаписей.Записать();
        ПолучитьСообщениеПользователю("Удалено битое соответствие для объекта: " + Выборка.СобственнаяСсылка);
    КонецЕсли;
КонецЦикла;

После удаления битых записей из регистра соответствий при очередном обмене УТ 11 поймет, что этих данных в бухгалтерии нет, и автоматически передаст их полные свойства.

Способ 3. Массовая перезапись номенклатуры в источнике

Что делать, если позиций номенклатуры с битыми ссылками очень много (сотни или тысячи) и регистрировать их вручную через форму плана обмена нереально? В этом случае мы можем прибегнуть к групповой обработке объектов в базе УТ 11.

Выполним следующие шаги:

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

Способ 4. Полуавтоматический поиск битых GUID и отправка запроса в УТ 11

Если у вас нет прямого доступа к боевой базе УТ 11 (как часто бывает у приходящих программистов 1С или системных администраторов), но есть доступ к БП 3.0, можно реализовать схему «запроса» недостающих данных.

Рассмотрим подробнее этот алгоритм:

Напишите внешнюю обработку для БП 3.0, которая сканирует табличные части документов за выбранный период и собирает строковое представление всех битых ссылок (их GUID-идентификаторы).
Выгрузите полученный список GUID в простой файл формата TXT или JSON.
Передайте данный файл администратору базы УТ 11.
В базе УТ 11 администратор запускает встречную обработку, которая считывает полученные GUID, находит по ним реальные элементы номенклатуры через метод Справочники.Номенклатура.ПолучитьСсылку(Новый УникальныйИдентификатор(ТекущийGUID)) и принудительно регистрирует их на узле обмена.

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