Почему не выгружается Поступление на расчетный счет с видом операции Возврат займа из БП 3.0 в УТ 11.4

← На главную

При настройке синхронизации между конфигурациями «Бухгалтерия предприятия 3.0» (БП) и «Управление торговлей 11.4» (УТ) пользователи часто сталкиваются с ситуацией, когда документ Поступление на расчетный счет успешно зарегистрирован к обмену, но фактически не попадает в файл выгрузки. Особенно остро эта проблема проявляется для специфических видов операций, таких как «Возврат займа контрагентом».

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

Анализируем причину: почему регистрация есть, а выгрузки нет?

Прежде всего, разберем базовый принцип работы EnterpriseData (универсального формата обмена). Когда мы нажимаем кнопку «Синхронизировать», система выполняет несколько шагов:

Проверяет наличие записей в плане обмена СинхронизацияДанныхЧерезУниверсальныйФормат.
Для каждого зарегистрированного объекта вызывает Менеджер обмена.
Внутри менеджера происходит проверка: соответствует ли объект правилам отправки.

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

Шаг 1. Проверка регистрации документа

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

Рассмотрим порядок действий:

Откроем раздел Администрирование — Синхронизация данных.
Нажмем на иконку «Состав отправляемых данных» (выглядит как два зеленых листика).
Найдем в списке Поступление на расчетный счет.
Если документ там есть, но в файл он не попадает — значит, срабатывает программный фильтр в процедурах ПриОтправкеДанных.

Шаг 2. Поиск ограничения в программном коде

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

Проанализируем примерный фрагмент кода, который отвечает за проверку вида операции:


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

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

Как мы видим, если текущий ВидОперации документа не входит в массив ДопустимыеОперации, переменная Отказ устанавливается в значение Истина. В результате объект просто игнорируется при формировании XML-файла выгрузки, несмотря на его наличие в плане обмена.

Шаг 3. Варианты решения проблемы

Существует несколько способов обойти данное ограничение. Выберем наиболее подходящий в зависимости от ваших задач.

Вариант А. Временная смена вида операции (без программирования)

Если документов немного, можно воспользоваться «хитростью»:

В 1С:Бухгалтерии измените вид операции в документе на Прочее поступление.
Выполните синхронизацию. Документ успешно улетит в УТ 11.4.
После обмена верните в БП 3.0 исходный вид операции Возврат займа контрагентом.

Важное уточнение: В УТ 11.4 документ придет как «Прочее поступление». Вам придется вручную корректировать статью движения денежных средств и аналитику, чтобы данные в управленческом учете отразились верно.

Вариант Б. Использование расширения конфигурации (рекомендуемый)

Чтобы не снимать основную конфигурацию с поддержки, создадим расширение. Нам нужно перехватить процедуру фильтрации и разрешить выгрузку нашего вида операции.

Разберем пример кода для модуля расширения:


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

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

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

Особенности сопоставления объектов в УТ 11.4

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

При выгрузке EnterpriseData пытается сопоставить поля. Если в БП выбран вид операции Возврат займа, формат ED ожидает заполнения соответствующих узлов (LoanContract). Если эти узлы не заполнены в коде менеджера выгрузки, УТ не поймет, к какому финансовому инструменту относится этот платеж.

Итоги и рекомендации

Подведем итог нашему исследованию ситуации:

Документы не выгружаются из-за жесткого списка разрешенных ВидовОпераций в модуле МенеджерОбменаЧерезУниверсальныйФормат.
Для исправления ситуации необходимо либо временно менять вид операции на Прочее поступление, либо модифицировать массив допустимых операций через расширение.
Внимание: Просто разрешить выгрузку недостаточно. Обязательно проверьте, как документ загрузился в УТ 11. Посмотрите, заполнилась ли статья ДДС и корректно ли распределились денежные средства по регистрам управленческого учета.

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