Почему нет сумм в проводках 10.01 - 60.01 при программном создании договора и приобретения в 1С:КА и ERP?

← На главную

При автоматизации учета и интеграции внешних систем с конфигурациями 1С:Комплексная автоматизация 2 (КА 2) и 1С:ERP Управление предприятием 2 разработчики часто сталкиваются с неприятной проблемой. Программно созданный и проведенный документ ПриобретениеТоваровУслуг формирует количественные движения, но при отражении в регламентированном учете проводка по дебету счета 10 (или 41) и кредиту счета 60 формируется без суммы. При этом, если тот же самый документ провести без указания договора, суммы в проводках появляются штатным образом.

В этой статье мы подробно разберем, почему возникает такое поведение системы, проанализируем скрытые механизмы работы оперативного контура ERP/КА и предоставим готовое программное решение для исправления этой ошибки.

Выясняем причину: особенности оперативного учета в ERP-решениях

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

В современных конфигурациях регламентированный учет (проводки) строится строго на основании данных оперативного учета (регистров накопления). Если оперативный учет заполнен некорректно или противоречиво, то механизм формирования проводок не сможет рассчитать себестоимость ТМЦ и распределить взаиморасчеты. В результате проводка по учету номенклатуры (Дебет 10, Кредит 60) записывается пустой по сумме, так как программа «не понимает», по какой именно стоимости приходовать номенклатуру.

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

Ключевые реквизиты договора, влияющие на проводки

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

ВариантОформленияЗакупок (Перечисление «Варианты оформления закупок»)
Это основной виновник описываемой проблемы. Этот реквизит управляет тем, как именно программа должна интерпретировать поступление. Если поле остается пустым, система может переключить логику проведения в режим «неотфактурованной поставки» или «товаров в пути». В этих режимах возникновение обязательств перед поставщиком и переход права собственности на товар разделены во времени. Соответственно, документ прихода делает движения только по количеству, ожидая распределения стоимости отдельным финансовым документом. Для обычных поставок здесь должно быть строго установлено значение НеРазделять.
ВариантПриемкиТоваров (Перечисление «Варианты приемки товаров»)
Определяет схему складского документооборота. Ошибки в этом поле приводят к рассинхронизации финансового и складского контуров. Чаще всего должно принимать значение РазделенаТолькоПоНакладным или НеРазделена.
ПорядокРасчетов (Перечисление «Порядок расчетов»)
Определяет детализацию ведения взаиморасчетов с партнером. Возможные варианты: ПоДоговорам, ПоЗаказам, ПоНакладным. Если в договоре указан один порядок расчетов, а программно созданный документ не содержит соответствующих аналитических разрезов (например, не заполнен реквизит ОбъектРасчетов), то система не сможет сопоставить партию товара с задолженностью, из-за чего себестоимость зависнет без суммы.
ГруппаФинансовогоУчета (Справочник «Группы финансового учета расчетов»)
В новых конфигурациях счета учета расчетов (60.01, 60.02) не выбираются непосредственно в документах, а подтягиваются из настроек ГФУ расчетов, привязанной к договору. Если это поле пустое, счета учета могут определиться неверно или не определиться вовсе.

Решаем проблему: как правильно создать договор программно

Чтобы избежать ошибок при формировании проводок, рассмотрим правильную методику создания договора контрагента программным путем. Мы применим два подхода: заполнение обязательных реквизитов вручную и вызов типовых процедур инициализации БСП.

Рассмотрим пример кода на языке 1С:


// Создаем новый элемент справочника ДоговорыКонтрагентов
НовыйДоговор = Справочники.ДоговорыКонтрагентов.СоздатьЭлемент();

// Заполняем основные реквизиты
НовыйДоговор.Владелец = ПартнерСсылка; // В ERP договоры подчинены Партнерам или Контрагентам
НовыйДоговор.Контрагент = КонтрагентСсылка;
НовыйДоговор.Организация = ОрганизацияСсылка;
НовыйДоговор.Наименование = "Договор программный № " + НомерДоговора;
НовыйДоговор.Статус = Перечисления.СтатусыДоговоровКонтрагентов.Действует;
НовыйДоговор.НачалоДействия = ТекущаяДата();

// Заполнение реквизитов направления деятельности и назначения договора
НовыйДоговор.ТипДоговора = ПредопределенноеЗначение("Перечисление.ТипыДоговоров.СПоставщиком");

// КРИТИЧЕСКИ ВАЖНО: Заполнение скрытых реквизитов для корректных проводок
НовыйДоговор.ВариантОформленияЗакупок = Перечисления.ВариантыОформленияЗакупок.НеРазделять;
НовыйДоговор.ВариантПриемкиТоваров = Перечисления.ВариантыПриемкиТоваров.РазделенаТолькоПоНакладным;
НовыйДоговор.ПорядокРасчетов = Перечисления.ПорядокРасчетов.ПоНакладным;

// Указываем группу финансового учета расчетов для корректного подбора счетов 60.01 / 60.02
НовыйДоговор.ГруппаФинансовогоУчета = Справочники.ГруппыФинансовогоУчетаРасчетов.НайтиПоНаименованию("Поставщики");

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

// Записываем договор
Попытка
    НовыйДоговор.Записать();
Исключение
    ЗаписьЖурналаРегистрации("ПрограммноеСозданиеДоговора", УровеньЖурналаРегистрации.Ошибка, , , ОписаниеОшибки());
    ВызватьИсключение "Не удалось записать договор: " + ОписаниеОшибки();
КонецПопытки;

Как быстро найти расхождения между "ручным" и "программным" договорами?

Если после выполнения указанных рекомендаций суммы в проводках всё равно не появляются, проведем диагностику методом сравнения. Нам потребуется сравнить рабочий («ручной») договор и проблемный («программный») договор.

Для этого выполним следующие шаги:

Откроем обработку «Консоль запросов» в нашей базе.
Напишем простой запрос к таблице договоров, выбрав все реквизиты:


ВЫБРАТЬ
    *
ИЗ
    Справочник.ДоговорыContрагентов КАК Договоры
ГДЕ
    Договоры.Ссылка В (&СсылкаНаРучнойДоговор, &СсылкаНаПрограммныйДоговор)

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

Использование этого подхода гарантирует, что система при проведении документа ПриобретениеТоваровУслуг правильно распознает финансовую схему сделки, успешно сопоставит складские движения с финансовым долгом и сформирует полноценные проводки по дебету 10 (или 41) счета с корректно рассчитанной себестоимостью.