Как настроить перенос Заказа покупателя из УТ 10.3 в Счет на оплату в БП 2.0 через Конвертацию данных 2.1?

← На главную

При настройке двустороннего обмена данными между конфигурациями «Управление торговлей 10.3» (УТ) и «Бухгалтерия предприятия 2.0» (БП) разработчики часто сталкиваются с необходимостью кастомизации типовых правил. Одна из классических задач — корректный перенос цепочки документов продажи. В частности, когда в УТ документ РеализацияТоваровУслуг оформлен на основании документа ЗаказПокупателя, в БП этот заказ должен трансформироваться в СчетНаОплатуПокупателю и автоматически привязаться к соответствующей реализации в качестве документа-основания (реквизит Сделка или аналогичные поля на вкладке «Дополнительно»).

В этой статье мы подробно разберем, как решить эту задачу в специализированной конфигурации «Конвертация данных 2.1» (КД 2.1), устраним типичные ошибки начинающих разработчиков при работе с составными типами данных и выясним, как правильно обновить ранее перенесенные («старые») документы в базах данных.

Архитектурный контекст: сопоставление объектов УТ 10.3 и БП 2.0

Для начала проанализируем структуру метаданных обеих конфигураций. Это критически важно для понимания того, какие объекты мы будем связывать в правилах конвертации:

Источник (Управление торговлей 10.3): Бизнес-процесс продажи обычно начинается с документа ЗаказПокупателя. При отгрузке товаров создается документ РеализацияТоваровУслуг. В нем присутствует реквизит Сделка, который имеет составной тип данных (включая ДокументСсылка.ЗаказПокупателя, ДокументСсылка.СчетНаОплатуПокупателю, ДокументСсылка.ДоговорКонтрагента и др.).
Приемник (Бухгалтерия предприятия 2.0): В данной конфигурации по умолчанию отсутствует документ «Заказ покупателя». Вместо него для резервирования товаров и выставления требований на оплату используется документ СчетНаОплатуПокупателю. Соответственно, при переносе реализации реквизит Сделка в БП (который также имеет составной тип) должен получить ссылку на соответствующий СчетНаОплатуПокупателю.

Следовательно, в Конвертации данных нам необходимо связать источник ЗаказПокупателя с приемником СчетНаОплатуПокупателю. Для этого в правилах обмена (ПКО) создается правило с именем, например, ЗаказПокупателяСчетНаОплатуПокупателю.

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

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

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

Пошаговое решение: настройка ПКС в Конвертации данных 2.1

Рассмотрим по шагам, как настроить правила конвертации свойств (ПКС) для реквизита Сделка в документе РеализацияТоваровУслуг.

Шаг 1. Открытие правил конвертации свойств

Откроем нашу настройку правил в конфигурации «Конвертация данных 2.1». Найдем правило конвертации объектов (ПКО) для документа реализации: РеализацияТоваровУслуг (обычно оно называется так же или аналогично в зависимости от префиксов вашей настройки). Перейдем на вкладку «Конвертация свойств» и найдем в списке реквизит «Сделка» (или иной реквизит, отвечающий за документ-основание).

Шаг 2. Анализ настроек свойства

Обратите внимание на колонку «Правило конвертации» для этого свойства. Если там просто указано ПКО по умолчанию, это может приводить к ошибкам из-за составного типа. Нам необходимо вмешаться в процесс выгрузки программно.

Шаг 3. Написание кода в обработчике «Перед выгрузкой»

Двойным кликом откроем настройки свойства Сделка. Перейдем к обработчикам событий этого свойства и найдем обработчик «Перед выгрузкой». Именно здесь мы должны написать алгоритм, который проверит тип значения в источнике и жестко укажет имя правила для выгрузки.

Проанализируем типичную ошибку начинающих специалистов. Часто в коде пытаются проверить тип значения приемника или путают имена объектов. Например, пишут так:


// ОШИБОЧНЫЙ КОД! Не используйте его!
Если ТипЗнч(Источник.Сделка) <> Тип("ДокументСсылка.СчетНаОплатуПокупателю") Тогда
    Отказ = Истина;
Иначе
    ИмяPKO = "ЗаказПокупателяСчетНаОплатуПокупателю";
КонецЕсли;

Выясним причину ошибки: На этапе выгрузки данных из базы-источника (УТ 10.3) у нас еще нет объектов БП. База УТ ничего не знает о типе данных ДокументСсылка.СчетНаОплатуПокупателю, такого типа в ней просто не существует! Проверка типа всегда должна выполняться по метаданным источника.

Посмотрим на правильный, корректный вариант кода, который необходимо вставить в обработчик «Перед выгрузкой» свойства Сделка:


// Корректный код для обработчика "Перед выгрузкой" ПКС "Сделка"
Если ЗначениеЗаполнено(Источник.Сделка) Тогда
    // Проверяем, что сделка в УТ 10.3 — это именно Заказ покупателя
    Если ТипЗнч(Источник.Сделка) = Тип("ДокументСсылка.ЗаказПокупателя") Тогда
        // Принудительно назначаем ПКО, преобразующее Заказ в Счет на оплату
        ИмяПКО = "ЗаказПокупателяСчетНаОплатуПокупателю";
    Иначе
        // Если сделка заполнена другим типом (например, договором), 
        // и для него нет отдельной логики, можно отменить выгрузку конкретно этого свойства
        // или позволить КД определить ПКО автоматически
        // Отказ = Истина; // Раскомментировать при необходимости жесткой фильтрации
    КонецЕсли;
КонецЕсли;

Этот код гарантирует, что если в реализации в УТ указан заказ покупателя, КД 2.1 применит именно правило ЗаказПокупателяСчетНаОплатуПокупателю для его конвертации.

Как обновить «старые» (уже перенесенные) документы?

После сохранения правил и загрузки их в узлы обмена вы можете заметить, что у вновь создаваемых документов связь устанавливается корректно, а у документов за прошлые периоды — нет. Разберем по шагам, почему так происходит и как исправить ситуацию.

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

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

Метод 1. Использование обработки «Регистрация изменений для обмена»

Проанализируем алгоритм ручной регистрации объектов в УТ 10.3:

Откроем базу УТ 10.3 в обычном (толстом) клиенте.
Перейдем в меню: Сервис — Прочие обмены данными — Все настройки обмена данными.
Найдем наш узел обмена с Бухгалтерией предприятия. Нажмем кнопку изменения/редактирования регистрации объектов (или воспользуемся внешней обработкой РегистрацияИзмененийДляОбмена.epf через Файл — Открыть).
В дереве объектов найдем ветку «Документы» и выберем Реализация товаров и услуг.
Нажмем правую кнопку мыши и выберем пункт «Зарегистрировать изменения объектов». Мы можем настроить фильтр (например, выбрать документы только за последний месяц или квартал), чтобы не гонять базу целиком.
Внимание! Очень важный нюанс: Одних только документов реализации недостаточно. Если сами заказы покупателей (которые должны стать счетами) ранее не переносились или были удалены, реализация прилетит в БП с пустой ссылкой. Поэтому параллельно зарегистрируйте к обмену и документы Заказ покупателя за тот же самый период.

Метод 2. Групповое перепроведение (перезапись) документов

Если в вашей настройке плана обмена включена авторегистрация объектов при записи, мы можем пойти другим путем:

Откроем стандартную обработку «Групповая обработка справочников и документов» в УТ 10.3.
Выберем тип объекта: Документы, установим флаг напротив Реализация товаров и услуг.
Настроим отбор по периоду (например, текущий месяц) и нажмем кнопку «Отобрать».
В поле действий выберем команду «Изменить [ИмяРеквизита]» или просто действие «Записать документы» (именно записать, а не провести!).
При записи документов платформа автоматически зарегистрирует их на узле плана обмена для БП. При следующем сеансе синхронизации они выгрузятся по новым правилам.

Дополнительные подводные камни, о которых важно помнить

Рассмотрим еще несколько неочевидных проблем, с которыми вы можете столкнуться при доработке этого обмена:

Флаг выгрузки заказов в пользовательских настройках: В режиме предприятия в УТ 10.3 откройте настройки самого узла обмена. Убедитесь, что там взведен флаг «Выгружать заказы покупателей как счета на оплату». Если этот флаг снят, то даже корректно написанные правила в КД могут игнорироваться глобальным фильтром выгрузки на стороне конфигурации.
Синхронизация по уникальным идентификаторам (GUID): Если бухгалтеры в БП уже создавали «Счета на оплату покупателю» вручную, а теперь вы выгружаете их оригиналы из УТ 10.3, в БП могут образоваться дубли. Чтобы этого избежать, проанализируйте настройки поиска в ПКО ЗаказПокупателяСчетНаОплатуПокупателю в КД 2.1. Если сопоставление идет только по GUID, а документы создавались в двух базах независимо — дубли неизбежны. Рекомендуем настроить поля поиска по Номеру и Дате документа в случае ненадежности GUID-идентификации.
Проведение документов реализации в БП: При обмене документ реализации попытается автоматически провестись в БП 2.0. Если договор контрагента в счете-на-оплату (бывшем заказе) отличается от договора в самой реализации, проведение в Бухгалтерии завершится ошибкой из-за несовпадения аналитики. Всегда следите за идентичностью договоров в цепочке документов в УТ.

Мы подробно разобрали весь процесс модификации правил обмена, написания обработчиков и пост-обработки данных. Применяйте эти знания на практике, и ваши интеграции будут работать стабильно и предсказуемо!