При настройке обмена данными между конфигурациями «1С» разработчики часто сталкиваются с ситуацией, когда перенесенный документ создается в базе-приемнике, но отказывается корректно проводиться или не формирует нужные проводки по бухгалтерскому учету. Типичный пример — перенос документа «Отчет о розничных продажах» из «1С:Розница» в «Приходный кассовый ордер» (ПКО) в «1С:Бухгалтерию предприятия 3.0».
Пытаясь решить проблему «в лоб», начинающие специалисты замечают, что при ручном перевыборе реквизитов на форме документа (например, при изменении склада или вида операции) ПКО чудесным образом «оживает», заполняет счета учета и проводится правильно. Возникает соблазн программно вызвать процедуры формы, такие как ВидОперацииПриИзмененииСервер или КонтрагентПриИзмененииСервер, прямо во время загрузки XML. В этой статье мы разберем, почему этот путь тупиковый, и рассмотрим правильные архитектурные решения этой задачи.
Для начала давайте разберем фундаментальный принцип работы платформы. Процесс загрузки данных (будь то Конвертация Данных 2.1, 3.0, чтение XML или JSON) происходит исключительно в серверном контексте без отображения интерфейса. В этот момент у создаваемого документа ПКО просто физически не существует формы.
Попытка обратиться к свойству Форма.Элементы или вызвать экспортируемые методы модуля формы из обработки загрузки приведет к неизбежной ошибке выполнения. Модуль формы и его элементы предназначены исключительно для интерактивной работы пользователя. Они управляют визуализацией: скрывают ненужные колонки, делают доступными определенные поля ввода в зависимости от выбранного вида операции, выводят подсказки.
Для проведения документа системе не нужны красивые визуальные элементы. Проводки формируются исключительно на основе данных самого объекта — его реквизитов шапки и строк табличных частей. Следовательно, всю бизнес-логику заполнения реквизитов и счетов учета нам необходимо реализовать на уровне объекта базы данных, полностью минуя интерфейсный слой.
Основная причина, по которой программно загруженный ПКО не делает проводок или проводится некорректно — это незаполненная табличная часть РасшифровкаПлатежа. В старых версиях конфигураций на обычных формах (например, в БП 1.6 или УПП 1.2) многие расчетные механизмы опирались на реквизиты шапки документа. В современных конфигурациях на управляемых формах (БП 3.0, ERP, КА) учет расчетов с контрагентами практически всегда ведется в разрезе строк табличной части.
Если при переносе данных вы заполнили только реквизиты Контрагент, ДоговорКонтрагента и СуммаДокумента в шапке, но оставили ТЧ РасшифровкаПлатежа пустой, документ не сможет определить аналитику расчетов и счета учета. Нам нужно заполнить именно табличную часть. Ниже мы детально разберем три отличных способа решения этой задачи в правилах конвертации.
В конфигурации «1С:Бухгалтерия предприятия 3.0» за определение счетов расчетов с контрагентами отвечает специализированный общий модуль СчетаУчетаВДокументах. Чтобы не прописывать счета вручную и не «хардкодить» их в правилах конвертации (ведь счета могут зависеть от учетной политики организации, договоров и настроек регистров), мы можем задействовать типовой механизм.
Для этого в правилах конвертации объектов (ПКО) для документа «Приходный кассовый ордер» в обработчике «После загрузки» мы напишем следующий код:
// 1. Указываем системе, что необходимо выполнить заполнение счетов перед записью
Объект.ДополнительныеСвойства.Вставить("ЗаполнитьСчетаУчетаПередЗаписью", Истина);
// 2. Вызываем стандартный метод заполнения счетов из общего модуля БП
СчетаУчетаВДокументах.ЗаполнитьПередЗаписью(Объект, РежимЗаписиДокумента.Запись);
Этот простой и элегантный способ заставит систему самостоятельно определить нужные счета учета (например, 50.01 для кассы, 62.01 для расчетов с покупателями, 62.02 для авансов) на основании переданной организации, контрагента и его договора.
Если ваш «Приходный кассовый ордер» создается строго на основании документа «Отчет о розничных продажах» (или любого другого документа-основания) и эта связь передается при конвертации, мы можем использовать стандартный платформенный метод Заполнить().
Давайте реализуем это в обработчике «После загрузки»:
Если ЗначениеЗаполнено(Объект.ДокументОснование) Тогда
// Инициализируем стандартный алгоритм заполнения ПКО на основании ОРП
Объект.Заполнить(Объект.ДокументОснование);
КонецЕсли;
Преимущество этого метода колоссально. Платформа самостоятельно выполнит всю цепочку действий, которую обычно делает бухгалтер, нажимая кнопку «Создать на основании»:
РасшифровкаПлатежа.Бывают ситуации, когда стандартный метод Заполнить() не подходит из-за специфики бизнес-логики или когда документ-основание не переносится в базу-приемник. В этом случае нам придется заполнить табличную часть РасшифровкаПлатежа вручную.
Для этого мы можем написать код в обработчике «После загрузки», который обратится к регистрам сведений БП 3.0 для получения счетов учета расчетов:
// Очищаем существующие строки ТЧ во избежание дублирования при повторной загрузке
Объект.РасшифровкаПлатежа.Очистить();
// Добавляем новую строку и заполняем ее базовыми реквизитами платежа
НоваяСтрока = Объект.РасшифровкаПлатежа.Добавить();
НоваяСтрока.ДоговорКонтрагента = Объект.ДоговорКонтрагента;
НоваяСтрока.СуммаПлатежа = Объект.СуммаДокумента;
НоваяСтрока.КурсВзаиморасчетов = 1;
НоваяСтрока.КратностьВзаиморасчетов = 1;
// Получаем счета расчетов программно через типовой механизм Бухгалтерии
СчетаРасчетов = БухгалтерскийУчетПереопределяемый.ПолучитьСчетаУчетаРасчетов(
Объект.Организация,
Объект.Контрагент,
Объект.ДоговорКонтрагента
);
// Подставляем полученные счета расчетов в строку табличной части
НоваяСтрока.СчетУчетаРасчетовСКонтрагентом = СчетаРасчетов.СчетРасчетовПокупателя;
НоваяСтрока.СчетУчетаРасчетовПоАвансам = СчетаРасчетов.СчетАвансовПокупателя;
// При необходимости здесь же можно рассчитать и заполнить ставку и сумму НДС
Если ЗначениеЗаполнено(Объект.ДоговорКонтрагента) Тогда
НоваяСтрока.СтавкаНДС = Объект.ДоговорКонтрагента.СтавкаНДС;
// Здесь может быть ваш алгоритм расчета НДС от суммы платежа
КонецЕсли;
Этот способ дает разработчику максимальный контроль над процессом формирования данных внутри ПКО. Мы вручную управляем каждой строкой, что позволяет гибко распределять суммы, если, например, один ПКО закрывает сразу несколько договоров или сделок.
Мы выяснили причину проблемы и разобрали, что попытка управлять экранными формами во время интеграции данных — это грубая архитектурная ошибка. Для того чтобы документы ПКО успешно проводились и формировали корректные проводки в «1С:Бухгалтерии предприятия 3.0» после переноса, необходимо сфокусироваться на заполнении табличной части РасшифровкаПлатежа и счетов учета.
Используйте наиболее подходящий для вашей задачи вариант из рассмотренных нами: