← На главную

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

В данной статье мы подробно разберем, почему данные могут «пропадать» при переезде из одной базы в другую, как продиагностировать причину возникновения таких пустот и какими методами можно восстановить целостность информации. Мы пройдем путь от простых настроек плана обмена до глубокого анализа XML-структуры передаваемых сообщений.

Причина 1: Специфика выгрузки по ссылкам (Shallow Export)

Рассмотрим основной механизм работы типового обмена. В 1С объекты могут регистрироваться к обмену двумя способами: полностью (со всеми реквизитами) и по ссылке.

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

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

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

Причина 2: Глобальные фильтры и ограничения по дате

Посмотрим на ситуацию, когда обмен настроен с определенной даты, например, с 01.01.2024. Разберем по шагам, что произойдет, если в документе от января 2024 года указано основание (заказ или договор), созданное в декабре 2023 года:

• Документ реализации проходит по фильтру даты и попадает в файл обмена.
• Документ-основание (Заказ) отсекается фильтром даты и не попадает в файл.
• В базе-приемнике поле «Документ-основание» превращается в <Объект не найден>.

Аналогично работают фильтры по Организациям или Складам. Если в настройках синхронизации указано «Передавать данные только по Организации А», а в документе случайно указано подразделение, относящееся к Организации Б, данные по этому подразделению могут не выгрузиться в полном объеме, что приведет к появлению пустых ссылок.

Причина 3: Удаление объектов и работа с дублями

Разберем технический момент идентификации. Объекты в 1С при обмене сопоставляются по внутреннему идентификатору (UUID/GUID). Рассмотрим сценарий:

1. Объект «Контрагент» был перенесен из УТ в БП. В регистре сведений Соответствия объектов информационных баз создалась запись о связи двух GUID.
2. В базе УТ администратор воспользовался обработкой «Поиск и замена дублей» и объединил этого контрагента с другим. Старая карточка была удалена.
3. При следующем обмене документ, содержащий ссылку на удаленного контрагента, передает в БП старый GUID, который в УТ уже не существует, а в БП ссылается на «пустоту».

Важно помнить, что непосредственное удаление объектов (Shift+Delete) крайне опасно для систем с настроенным обменом. Всегда используйте стандартную процедуру пометки на удаление и контроля ссылок.

Причина 4: Использование формата EnterpriseData и RLS

Проанализируем более глубокие технические причины. Современный обмен между УТ 11 и БП 3.0 чаще всего использует универсальный формат EnterpriseData (XDTO).

Версии формата: Если конфигурация УТ сильно устарела по сравнению с БП (или наоборот), версии формата могут не совпадать. При загрузке база-приемник может просто «не узнать» некоторые поля в XML-файле и проигнорировать их, оставив реквизиты пустыми.

Ограничение прав доступа (RLS): Если пользователь, под которым выполняется регламентное задание обмена, имеет ограниченные права доступа к данным, система может «видеть» ссылку на объект, но не иметь прав на чтение его свойств. В этом случае в файл обмена попадет только ссылка без реквизитов (наименования, ИНН и т.д.), что снова приведет к результату <Объект не найден>.

Диагностика через анализ XML-файла

Если визуальный осмотр настроек не помогает, перейдем к «тяжелой артиллерии». Рассмотрим, как проверить содержимое сообщения обмена вручную:

1. Выполним выгрузку в файл (если настроен прямой обмен, можно временно переключить его на обмен через локальный каталог).
2. Найдем сформированный XML-файл и откроем его любым текстовым редактором (лучше всего Notepad++).
3. Найдем в тексте GUID объекта, который отображается как битая ссылка.
4. Проанализируем структуру. Если мы видим только запись вида: <Ref>550e8400-e29b-41d4-a716-446655440000</Ref> без вложенных тегов с данными (<Description>, <INN> и т.д.), значит, объект действительно выгружается только по ссылке. Нужно искать причину в правилах регистрации или фильтрах выгрузки.

Алгоритм решения проблемы

Подводя итог, выделим последовательность действий для исправления ситуации:

1. Проверка Журнала регистрации: В базе-приемнике проанализируем записи во время загрузки. Часто там фиксируются ошибки типа «Ошибка при чтении данных XDTO» или «Нарушение прав доступа».
2. Отчет по результатам синхронизации: В разделе «Синхронизация данных» воспользуемся отчетом «Результаты синхронизации». Вкладка «Незагруженные данные» может содержать список объектов, которые не удалось создать из-за противоречий в правилах.
3. Массовая регистрация: Если битых ссылок много, откроем обработку «Регистрация изменений», выберем справочник (например, Номенклатура), нажмем «Зарегистрировать» — «Все объекты выбранных типов». После этого запустим полную синхронизацию.
4. Актуализация правил: Убедимся, что обе конфигурации обновлены до совместимых версий. Если используются доработанные правила (в расширениях), проверим корректность обработчиков ПередВыгрузкой.

Соблюдение этих рекомендаций позволит вам восстановить целостность данных и избежать появления <Объектов не найденных> в будущем. Помните, что стабильный обмен — это прежде всего дисциплина в ведении справочников и регулярный контроль за очередью регистрации изменений.