Как заменить контрагента при обмене данными между УТ 11 и БП 3.0?

← На главную

При настройке обмена данными между конфигурациями, например, "Управление торговлей" (УТ) и "Бухгалтерия предприятия" (БП) через универсальный формат (Enterprise Data), часто возникает задача трансформации данных "на лету". Одной из распространенных ситуаций является необходимость подмены контрагента. Например, в торговой базе документы оформляются на одного контрагента (или группу разных), а в бухгалтерию они должны приходить на совершенно другое юридическое лицо или обобщенного контрагента.

Давайте подробно разберем, как реализовать такую логику, проанализируем предложенные сообществом варианты и выберем наиболее надежный способ.

Постановка задачи

Имеем стандартный обмен УТ 11 -> БП 3.0. При переносе документов (например, "Реализация товаров и услуг") необходимо, чтобы поле Контрагент в документе базы-приемника заполнялось не исходным значением из УТ, а определенным значением по нашему правилу (например, из регистра соответствия).

Рассмотрим два основных подхода к решению этой задачи: программную доработку через расширение и манипуляцию с идентификаторами (GUID).

Способ 1: Программная подмена данных (Рекомендуемый)

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

Для реализации нам понадобится создать Расширение конфигурации. Это позволит не снимать основную конфигурацию с поддержки и сохранит возможность легкого обновления.

В общем модуле МенеджерОбменаЧерезУниверсальныйФормат (или его версионных аналогах, например, МенеджерОбменаЧерезУниверсальныйФормат13) существуют специальные события-обработчики. Нам наиболее интересны события при отправке данных (в базе УТ) или при получении (в базе БП).

Вариант А: Подмена на стороне отправителя (в УТ)

Этот вариант предпочтительнее, так как мы сразу отправляем "нужные" данные, и база-приемник просто принимает их, не зная о подмене. Нам нужно переопределить процедуру, связанную с отправкой конкретного типа документа. Обычно она называется по шаблону ПКО_Документ_ИмяДокумента_ПриОтправкеДанных.

В этой процедуре мы получаем структуру ДанныеXDTO, которая уже сформирована и готова к отправке. Наша задача — найти в ней свойства контрагента и заменить их.

Алгоритм действий:

Создаем регистр сведений (в расширении или основной конфигурации), где храним пары "Исходный контрагент" -> "Контрагент для выгрузки".
В расширении заимствуем общий модуль МенеджерОбменаЧерезУниверсальныйФормат.
Перехватываем событие отправки (используем аннотацию &После).

Примерная логика кода в расширении:


&После("ПКО_Документ_РеализацияТоваровУслуг_ПриОтправкеДанных")
Процедура Расш_ПКО_Документ_РеализацияТоваровУслуг_ПриОтправкеДанных(ДанныеИБ, ДанныеXDTO, КомпонентыОбмена, СтекВыгрузки)
	
	// 1. Получаем исходного контрагента из данных документа
	ИсходныйКонтрагент = ДанныеИБ.Контрагент;
	
	// 2. Ищем соответствие в нашем регистре
	НужныйКонтрагент = ПолучитьКонтрагентаДляОбмена(ИсходныйКонтрагент);
	
	Если ЗначениеЗаполнено(НужныйКонтрагент) Тогда
		// 3. Подменяем данные в структуре XDTO
		// Обратите внимание: структура XDTO может быть сложной.
		// Обычно Контрагент находится в свойствах документа.
		
		// В Enterprise Data ссылка передается через структуру KeyProperties (КлючевыеСвойства)
		// Нам нужно найти в ДанныеXDTO свойство, отвечающее за контрагента, и подменить его UID или поля поиска.
		
		// Примерный доступ (структура зависит от версии формата):
		// ДанныеXDTO.Вставить("Контрагент", ...); 
		// Или если это сложный тип, нужно сформировать структуру для нового контрагента.
		
	КонецЕсли;

КонецПроцедуры

Важный нюанс: Просто заменить ссылку нельзя, так как формат XDTO оперирует не ссылками 1С, а структурами данных. Вам придется либо сформировать структуру описания нового контрагента, либо подменить УникальныйИдентификатор (UID) в выгружаемом пакете на UID нужного контрагента из БП (если вы его знаете).

Вариант Б: Подмена на стороне получателя (в БП)

Как упоминалось в обсуждении, можно использовать событие ПКО_Документ_..._ПриКонвертацииДанныхXDTO или ПриПолученииДанных. В этом случае данные приходят в БП как есть (со ссылкой на исходного контрагента), но перед записью документа в базу мы программно меняем реквизит.

Этот способ удобен тем, что мы можем оперировать реальными ссылками справочника Контрагенты в текущей базе БП.


// В расширении базы БП
&После("ПКО_Документ_РеализацияТоваровУслуг_ПриПолученииДанных")
Процедура Расш_ПКО_Документ_РеализацияТоваровУслуг_ПриПолученииДанных(ДанныеXDTO, ПолученныеДанные, КомпонентыОбмена)
	
	// ПолученныеДанные - это уже объект документа (или структура данных объекта), который будет записан
	
	Если ТипЗнч(ПолученныеДанные) = Тип("ДокументОбъект.РеализацияТоваровУслуг") Тогда
		
		// Проверяем условие и меняем
		Если НужнаЗамена(ПолученныеДанные.Контрагент) Тогда
			ПолученныеДанные.Контрагент = Справочники.Контрагенты.НайтиПоНаименованию("ООО Ромашка");
		КонецЕсли;
		
	КонецЕсли;
	
КонецПроцедуры

Способ 2: Подмена через GUID (Манипуляция данными)

В обсуждении был предложен альтернативный вариант, который не требует программирования логики обмена, но требует аккуратной работы с базой данных. Суть метода заключается в "обмане" механизма синхронизации.

Механизм обмена Enterprise Data ищет соответствие объектов по уникальному идентификатору (УникальныйИдентификатор / GUID). Если GUID объекта в базе-источнике совпадает с GUID объекта в базе-приемнике, они считаются одним и тем же объектом.

Суть метода:

У нас есть Контрагент А в УТ (Вася) и Контрагент Б в БП (Петя).
Мы хотим, чтобы документы от Васи из УТ падали на Петю в БП.
Мы берем GUID Васи из УТ.
В базе БП с помощью обработки (например, "Групповое изменение реквизитов" в режиме разработчика или простой внешней обработки) назначаем Пете GUID от Васи.

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

Риски этого метода:

Нарушение целостности НСИ: Если вы перепутаете идентификаторы, исправить это будет сложно.
Проблемы обновлений: Если поля поиска (ИНН/КПП) у Васи и Пети разные, механизм обмена может в какой-то момент решить, что это разные объекты, и создать дубль, или перезаписать реквизиты Пети данными Васи (наименование, ИНН), испортив карточку контрагента в бухгалтерии.
Односторонность: Это работает жестко. Вы не сможете сделать так, чтобы часть документов Васи шла на Петю, а часть — на Колю. Все документы Васи будут идти на тот объект, которому присвоен его GUID.

Способ 3: Штатное сопоставление объектов

Не стоит забывать про стандартный механизм платформы ПубличныеИдентификаторыСинхронизируемыхОбъектов.

В окне настройки синхронизации данных есть пункт "Настроить правила сопоставления объектов" (или "Предупреждения при синхронизации" -> "Несопоставленные объекты").

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

Однако, если автоматическое создание разрешено, система часто пытается сопоставить по полям поиска (ИНН+КПП). Если они разные, система может проигнорировать ручное сопоставление и создать нового контрагента. Поэтому данный способ подходит не всегда.

Резюме

Если вам нужно надежное, гибкое решение, работающее по определенной логике (например, для определенных организаций или видов договоров), используйте Способ 1 (Расширение). Это профессиональный подход.

Если задача разовая и простая (всегда подменять одного на другого), и вы понимаете риски, можно воспользоваться подменой GUID (Способ 2), но делайте это с осторожностью и обязательно на копии базы перед внедрением в продуктив.

← На главную