Почему не меняется вид операции при выгрузке списания безналичных средств из УТ 10 в БП 3?

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

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

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

Анализ типового алгоритма в обработчике «ПослеЗагрузки»

Рассмотрим фрагмент кода из типовых правил обмена (обработчик ПослеЗагрузки соответствующего правила конвертации объектов — ПКО):


Если Не Объект.ЭтоНовый() Тогда
    Если Объект.ВидОперации = Перечисления.ВидыОперацийСписаниеДенежныхСредств.ПрочееСписание Тогда
        ВО = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Ссылка, "ВидОперации");
        Если ВО <> Объект.ВидОперации Тогда
            Объект.ВидОперации = ВО;
        КонецЕсли;
    КонецЕсли;
КонецЕсли;

Проанализируем логику этого условия. Если документ уже существует в базе-приемнике (Не Объект.ЭтоНовый()) и из файла обмена пришло значение Перечисления.ВидыОперацийСписаниеДенежныхСредств.ПрочееСписание, алгоритм обращается к базе через ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Ссылка, "ВидОперации") и считывает текущий вид операции, записанный в информационной базе БП. Если он отличается от пришедшего значения, алгоритм принудительно возвращает документу старый вид операции.

Выясним причину наличия такого ограничения в типовых правилах:

  1. Разница в детализации учета между конфигурациями. В торговой базе («Управление торговлей») набор операций по банку ограничен потребностями торгового учета. Неторговые платежи (налоги, сборы, проценты по кредитам, лизинг, выплата дивидендов или зарплаты) часто регистрируются общим видом «Прочее списание». В «Бухгалтерии предприятия» аналитика шире: там предусмотрены специализированные виды («Уплата налога», «Перечисление заработной платы», «Расчеты по кредитам и займам» и др.).
  2. Защита ручных правок бухгалтера. Бухгалтер после первичной загрузки открывает документ, выбирает точный бухгалтерский вид операции, указывает корректные счета дебета (68, 69, 66, 76) и субконто. Если бы этого условия не было, при каждом повторном изменении или перепроведении документа в УТ 10 операция в БП 3 сбрасывалась бы обратно в «Прочее списание», затирая работу бухгалтерии.

Риски простого отключения проверки

На первый взгляд кажется простым решением просто закомментировать или удалить указанный блок кода в правилах. Однако это влечет за собой технические проблемы:

При обмене данными запись выполняется в режиме ОбменДанными.Загрузка = Истина. При этом стандартные платформенные события формы не выполняются. Для вида «Оплата поставщику» документ использует табличную часть РасшифровкаПлатежа и счета взаиморасчетов (60.01, 60.02). Для вида «Прочее списание» задействуются реквизит СчетДебета (например, 91.02 или 76.09) и разрезы СубконтоДт1, СубконтоДт2, СубконтоДт3. Если просто принудительно подставить вид операции, табличная часть расчетов с контрагентом останется заполненной, а поля счета дебета останутся пустыми, из-за чего документ окажется в рассогласованном состоянии и не сможет провестись.

Способы решения проблемы

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

Вариант 1. Пересоздание документа в базе-приемнике

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

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

Вариант 2. Изменение вида операции напрямую в «Бухгалтерии предприятия»

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

Вариант 3. Корректировка алгоритма в правилах конвертации (ПКО)

Если специфика бизнес-процесса требует обязательно менять вид операции именно из УТ 10, скорректируем обработчик ПослеЗагрузки, добавив проверку исходного вида операции. Нам нужно разрешить перезапись только в том случае, если текущий вид операции в БП — «Оплата поставщику», но защитить специализированные бухгалтерские виды:


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

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

← На главную