Как автоматически заполнить реквизит Заказ покупателя в УТ 10.3 при обмене данными с БП 2.0

Программист 1С v8.3 (Обычные формы) Управленческий учет Торговля и дистрибуция
← На главную

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

В рамках данной статьи мы разберем, как автоматизировать этот процесс, используя механизмы конфигурации «Конвертация данных 2.0». Мы проанализируем несколько подходов: от стандартной синхронизации по идентификаторам до программного поиска по номеру и дате.

Метод 1: Синхронизация по уникальным идентификаторам (UID)

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

Нам необходимо убедиться, что для реквизита Сделка в документе-приемнике настроено правильное ПКО. Разберем последовательность действий:

  1. В конфигурации «Конвертация данных» найдем правило конвертации свойств (ПКС) для табличной части РасшифровкаПлатежа документа ПлатежноеПоручениеВходящее.
  2. Для реквизита Сделка (в УТ) установим в качестве источника реквизит СчетНаОплату (из БП).
  3. Укажем правило конвертации объектов (ПКО), например, СчетНаОплату_ЗаказПокупателя.

Система при загрузке попытается найти объект в УТ по внутреннему идентификатору (GUID), который был сохранен в БП при первичной выгрузке заказа. Это самый надежный способ, не требующий написания сложного кода.

Метод 2: Программный поиск по номеру и дате в «Полях поиска»

Если по каким-то причинам поиск по идентификаторам не срабатывает (например, счета в БП создавались вручную или базы были перенесены без сохранения ссылок), мы можем реализовать поиск по номеру и дате. Проанализируем, как это сделать в обработчике ПКО.

В ПКО для документа ЗаказПокупателя перейдем в обработчик «Поля поиска». Нам нужно сопоставить номер счета из БП и номер заказа в УТ. Учтем, что в разных базах могут быть разные префиксы. Рассмотрим пример кода:


// Очищаем стандартный поиск, если нужно реализовать свой алгоритм
Если НомерОбъектаПоиска <> Неопределено Тогда
    // Удаляем префиксы для сопоставления «чистых» номеров
    НомерДляПоиска = ОбщегоНазначения.УдалитьПрефиксИнформационнойБазы(Номер);
    
    Запрос = Новый Запрос;
    Запрос.Текст = 
    "ВЫБРАТЬ ССЫЛКА 
    |ИЗ Документ.ЗаказПокупателя 
    |ГДЕ Номер ПОДОБНО &Номер";
    
    Запрос.УстановитьПараметр("Номер", "%" + НомерДляПоиска);
    Результат = Запрос.Выполнить();
    
    Если Не Результат.Пустой() Тогда
        Выборка = Результат.Выбрать();
        Выборка.Следующий();
        СсылкаНаОбъект = Выборка.Ссылка;
        ПрекратитьПоиск = Истина;
    КонецЕсли;
КонецЕсли;

Метод 3: Использование «Исходящих данных» при выгрузке

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

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

Пример формирования структуры в ПКС:


// В обработчике Перед выгрузкой ПКС табличной части
СтруктураСтроки = Новый Структура;
СтруктураСтроки.Вставить("Сделка", Источник.СчетНаОплату);
СтруктураСтроки.Вставить("СуммаПлатежа", Источник.СуммаДокумента);
// Добавляем строку в коллекцию
КоллекцияОбъектов.Добавить(СтруктураСтроки);

Метод 4: Установка значения в обработчике «После загрузки»

Если мы хотим максимально контролировать процесс на стороне приемника (УТ 10.3), мы можем прописать алгоритм в обработчике «После загрузки» ПКО самого платежного документа. Проанализируем ситуацию: документ уже загружен, но поле Сделка пустое. Мы можем найти нужный заказ программно и подставить его в объект.

Разберем пример кода для обработчика «После загрузки»:


Для Каждого СтрокаТЧ Из Объект.РасшифровкаПлатежа Цикл
    Если ЗначениеЗаполнено(СтрокаТЧ.Сделка) Тогда
        Продолжить;
    КонецЕсли;

    // Пытаемся найти заказ по косвенным признакам
    // Предположим, мы передали номер счета в ДополнительныхСвойствах
    НомерСчета = Объект.ДополнительныеСвойства.НомерСчета;
    ДатаСчета = Объект.ДополнительныеСвойства.ДатаСчета;
    
    ЗаказСсылка = Документы.ЗаказПокупателя.НайтиПоНомеру(НомерСчета, ДатаСчета);
    
    Если Не ЗаказСсылка.Пустая() Тогда
        СтрокаТЧ.Сделка = ЗаказСсылка;
        // Важно: в УТ 10.3 при заполнении сделки часто нужно пересчитать счета учета
        // Но для простой загрузки достаточно установки ссылки
    КонецЕсли;
КонецЦикла;

// Если документ должен быть проведен, вызываем Объект.Записать(РежимЗаписиДокумента.Проведение);

Важные технические нюансы

При реализации любого из вышеперечисленных методов следует учитывать специфику конфигурации «Управление торговлей 10.3»:

Подводя итог, отметим, что наиболее корректным с точки зрения архитектуры 1С является Метод 1 (синхронизация по UID). Мы рекомендуем сначала проверить настройки ПКО и убедиться, что идентификаторы объектов передаются корректно. К программному поиску по номеру следует переходить только в случае невозможности установления прямой ссылочной связи.

← На главную