Синхронизация данных между конфигурациями «1С:Управление торговлей 11» (УТ) и «1С:Бухгалтерия предприятия 3.0» (БП) — один из наиболее часто настраиваемых процессов в экосистеме 1С. Тем не менее в ходе обмена специалисты нередко сталкиваются с коварной ошибкой: процесс синхронизации завершается успешно и без видимых критических предупреждений, однако часть документов (например, Поступление товаров и услуг и Реализация товаров и услуг) не переносится вовсе. При этом связанные с ними счета-фактуры выгружаются, но в поле документа-основания или контрагента красуется пустая битая ссылка «<Объект не найден>».
В этой статье мы подробно разберем, почему возникает данная проблема, как работает механизм записи объектов при обмене через универсальный формат EnterpriseData, и пошагово устраним первопричину этой ошибки, которая чаще всего кроется в скрытом задвоении контактной информации.
При детальном анализе журнала регистрации в базе-приемнике (БП 3.0) можно заметить странную картину: система фиксирует создание нового контрагента или организации, но следом за этим отображается запись о его удалении. На самом деле физического удаления объекта не происходит. Рассмотрим, как устроен этот механизм изнутри:
ПередЗаписью, ПриЗаписи) и правила проверки заполнения реквизитов в менеджере обмена.Поскольку сам контрагент не записался в базу данных БП, все связанные с ним документы (реализации, поступления), ссылающиеся на этот GUID, теряют связь. Документы либо не могут быть проведены и записаны, либо загружаются в усеченном виде, отображая битые ссылки <Объект не найден> [Идентификатор GUID].
В современных конфигурациях 1С, разработанных на базе Библиотеки стандартных подсистем (БСП), классический регистр сведений для хранения адресов и телефонов больше не используется. Вся контактная информация хранится непосредственно в табличных частях КонтактнаяИнформация справочников Контрагенты, Организации, ФизическиеЛица и Партнеры.
Обмен данными между УТ 11 и БП 3.0 происходит по правилам универсального формата EnterpriseData (XDTO). Спецификация этого формата накладывает жесткое ограничение: для каждого уникального Вида контактной информации (например, «Фактический адрес», «Юридический адрес», «Телефон») в табличной части объекта должна существовать строго одна строка.
Если в исходной базе УТ 11 у контрагента по какой-то причине образовалось несколько строк с абсолютно одинаковым значением в поле Вид, то при попытке разбора XDTO-пакета в базе БП 3.0 менеджер обмена выбросит системное исключение вида:
Вид контактной информации [Наименование вида] полученного объекта указан несколько раз. Загрузка невозможна.
Именно это исключение инициирует откат транзакции, из-за чего контрагент не создается, а документы-основания приходят «битыми».
Проанализируем основные причины появления дублирующихся строк контактной информации в УТ 11:
КонтактнаяИнформация.Разберем детальный алгоритм, как выявить проблемных контрагентов и восстановить корректный обмен данными.
Для начала нам необходимо точно локализовать ошибку и понять, какой именно объект вызывает сбой. Выполним следующие действия в базе «1С:Бухгалтерия предприятия»:
Важность (укажем значение «Ошибка») и выберем период последней синхронизации._ОбменДанными). В детальном описании ошибки мы увидим точное указание на проблемный объект и дублирующийся вид контактной информации. Например: Ошибка записи объекта: Справочник.Контрагенты, Наименование: ООО "Вектор". Вид контактной информации "Юридический адрес" указан несколько раз.Когда характер проблемы ясен, нам нужно найти всех контрагентов и организации в базе «1С:Управление торговлей», у которых зафиксировано задвоение строк. Для этого откроем консоль запросов или напишем обработку, выполняющую следующий запрос:
ВЫБРАТЬ
КИ.Ссылка КАК СсылкаНаОбъект,
КИ.Вид КАК ВидКонтактнойИнформации,
КОЛИЧЕСТВО(КИ.НомерСтроки) КАК КоличествоСтрок
ПОМЕСТИТЬ ВТ_ДублиКИ
ИЗ
Справочник.Контрагенты.КонтактнаяИнформация КАК КИ
ГРУППИРОВАТЬ ПО
КИ.Ссылка,
КИ.Вид
ИМЕЮЩИЕ
КОЛИЧЕСТВО(КИ.НомерСтроки) > 1
;
////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
ВТ_ДублиКИ.СсылкаНаОбъект КАК ПроблемныйКонтрагент,
ВТ_ДублиКИ.ВидКонтактнойИнформации КАК ВидКИ,
ВТ_ДублиКИ.КоличествоСтрок КАК ВсегоСтрок,
ПроблемныйКонтрагент.Код КАК КодКонтрагента,
ПроблемныйКонтрагент.ИНН КАК ИННКонтрагента
ИЗ
ВТ_ДублиКИ КАК ВТ_ДублиКИ
Этот запрос выведет список всех контрагентов, у которых нарушено правило уникальности видов контактной информации. Аналогичный запрос мы можем выполнить и для справочника Организации, заменив имя таблицы источника.
После выявления проблемных элементов их необходимо исправить. Сделать это можно несколькими способами:
// Пример программной очистки дубликатов КИ у конкретного контрагента
ПроблемныйОбъект = СсылкаНаКонтрагента.ПолучитьОбъект();
ТаблицаКИ = ПроблемныйОбъект.КонтактнаяИнформация;
СписокВидовКИ = Новый Соответствие;
ИндексыДляУдаления = Новый Массив;
Для Индекс = 0 По ТаблицаКИ.Количество() - 1 Цикл
СтрокаКИ = ТаблицаКИ[Индекс];
Если СписокВидовКИ[СтрокаКИ.Вид] <> Неопределено Тогда
// Этот вид КИ уже встречался в табличной части, помечаем индекс на удаление
ИндексыДляУдаления.Добавить(Индекс);
Иначе
СписокВидовКИ.Вставить(СтрокаКИ.Вид, Истина);
КонецЕсли;
КонецЦикла;
// Удаляем дубли с конца коллекции, чтобы не сбились индексы
Для Каждого ИндексИзСписка Из ИндексыДляУдаления Цикл
ТаблицаКИ.Удалить(ТаблицаКИ.Количество() - 1 - ИндексИзСписка);
КонецЦикла;
Если ИндексыДляУдаления.Количество() > 0 Тогда
ПроблемныйОбъект.Записать();
КонецЕсли;
Если программная очистка не помогает или дубли появляются снова, обязательно проверим справочник Виды контактной информации. Для этого:
Виды контактной информации.После того как данные в УТ 11 очищены от дубликатов, их необходимо принудительно доставить в БП 3.0. Поскольку объекты уже могли быть отмечены системой как «успешно отправленные» (несмотря на то, что транзакция в БП откатилась), выполним их ручную перерегистрацию:
Контрагенты, кликнем правой кнопкой мыши и выберем пункт Зарегистрировать изменения членов класса (все объекты) или выберем конкретных измененных контрагентов.Реализация товаров и услуг и Поступление товаров и услуг, которые ранее пришли в бухгалтерию в урезанном виде.После выполнения этих шагов все данные успешно пройдут валидацию формата EnterpriseData, транзакция записи в БП 3.0 завершится корректно, а ссылки на контрагентов в документах и счетах-фактурах автоматически восстановятся и перестанут отображаться как <Объект не найден>.