При настройке правил обмена данными между конфигурациями 1С часто возникают ситуации, когда бизнес-логика источника и приемника не совпадает. Типичный пример: в исходной базе (например, нетиповой «Управление производственным предприятием 1.3») цепочка документов включает промежуточный виртуальный склад, а в целевой типовой базе этот склад отсутствует, и товар должен списываться со склада, указанного в исходном заказе покупателя. Чтобы решить эту задачу, необходимо реализовать алгоритм динамической подмены склада непосредственно в процессе переноса данных.
В этой статье мы подробно разберем, как решить эту задачу с помощью конфигурации «1С:Конвертация данных 2.1» (КД 2.1), проанализируем критические ошибки, которые часто допускают разработчики на форумах, и рассмотрим два наиболее эффективных и безопасных архитектурных решения.
Прежде чем перейти к правильным алгоритмам, давайте проанализируем технические решения, часто предлагаемые на форумах (включая сообщение 11 из обсуждения), и выясним, почему они опасны для вашей базы данных.
1. Использование поиска по наименованию в цикле обработки документов
Попытка написать в обработчиках событий код вида:
Объект.Склад = Справочники.Склады.НайтиПоНаименованию("Основной склад");
Это классический антипаттерн разработки в 1С. Метод НайтиПоНаименованию выполняет прямой запрос к базе данных. Если вы переносите тысячи документов реализации, система для каждого документа (и для каждой строки, если код выполняется в цикле) будет отправлять отдельные запросы к СУБД для поиска элемента справочника. Это приведет к катастрофическому падению производительности обмена и затянет процесс выгрузки на часы.
2. Путаница в контекстах выполнения и переменных («Источник» vs «Объект»)
В «Конвертации данных 2.1» критически важно понимать, где именно выполняется код — на стороне источника (при выгрузке) или на стороне приемника (при загрузке):
Источник. Переменной Объект здесь не существует. Любая попытка обратиться к Объект.Склад в обработчиках выгрузки вызовет критическую ошибку выполнения.Объект, которая представляет собой создаваемый или обновляемый документ в целевой базе.3. Жесткое кодирование («хардкод») конкретных складов
Прописывание конкретных названий складов вроде "Склад10" или "Склад01" прямо в программном коде лишает систему гибкости. Если завтра в компании появится новый склад или переименуют старый, правила обмена полностью перестанут работать, и вам придется вручную переписывать XML-правила.
---
Это наиболее рекомендуемый и изящный способ. Мы переопределяем выгружаемое значение непосредственно в ПКС (Правиле конвертации свойства) для реквизита Склад документа РеализацияТоваровУслуг. При этом сам документ в базе-источнике не меняется, но в XML-файл выгрузки записывается правильный склад из связанного заказа.
Рассмотрим пошаговый алгоритм настройки:
РеализацияТоваровУслуг.Склад.
// Проверяем, заполнена ли сделка (заказ покупателя) в документе-источнике
Если ЗначениеЗаполнено(Источник.Сделка) Тогда
// Получаем склад непосредственно из связанного заказа
Значение = Источник.Сделка.Склад;
Иначе
// Если заказ не указан, оставляем склад из реализации по умолчанию
Значение = Источник.Склад;
КонецЕсли;
Как работает этот код:
Переменная Значение в обработчике «Перед выгрузкой» ПКС указывает платформе, какой именно объект (в данном случае элемент справочника Склады) должен быть преобразован и отправлен в файл обмена. Мы динамически подменяем ссылку на склад. Поскольку мы передаем ссылку, КД 2.1 автоматически применит к ней ПКО Склады, выгрузит УИД (уникальный идентификатор) или код элемента, и сопоставление в базе-приемнике пройдет штатно и быстро.
---
Если по какой-то причине в источнике сложно или невозможно получить данные (например, структура метаданных сильно изменена, или реквизиты заполняются динамически), задачу можно решить на стороне приемника. Для этого необходимо, чтобы в приемник также переносился документ-заказ (записываемый в реквизит Сделка или ЗаказПокупателя документа реализации).
Разберем по шагам, как настроить этот вариант:
РеализацияТоваровУслуг.
// Проверяем наличие заполненного заказа в уже загруженном объекте приемника
Если ЗначениеЗаполнено(Объект.Сделка) И ЗначениеЗаполнено(Объект.Сделка.Склад) Тогда
// Устанавливаем в документе реализации склад из этого заказа
Объект.Склад = Объект.Сделка.Склад;
КонецЕсли;
Преимущества данного подхода:
Мы работаем уже с готовыми ссылками базы-приемника. Нам не нужно делать запросы через НайтиПоНаименованию или НайтиПоКоду, так как платформа 1С при чтении XML-файла самостоятельно сопоставила и заполнила реквизит Объект.Сделка.Склад. Запись документа произойдет стандартным образом с уже измененным складом.
---
Если в источнике и приемнике склады имеют разные наименования или коды (и сопоставление по УИД невозможно), никогда не пишите жесткие условия подмены в коде документов. Решать эту проблему нужно на уровне ПКО справочника «Склады»:
Склады. Настройте сопоставление, например, по реквизиту Код или связке реквизитов.СоответствиеНоменклатурыИСкладовПриОбмене. В обработчиках КД делайте быстрый запрос к этому регистру. Это позволит конечным пользователям настраивать маппинг складов прямо в режиме «1С:Предприятие» без изменения самих правил обмена.Используя предложенные шаблоны проектирования правил обмена, вы обеспечите высокую скорость работы конвертации данных, исключите появление ошибок "битых ссылок" и сохраните гибкость вашей интеграционной системы.