Как исправить некорректное присвоение вида долга при проведении документа Корректировка долга в 1С 7.7 Торговля и Склад?

← На главную

При работе в типовых конфигурациях платформы 1С v7.7 (в частности, в конфигурации «Торговля и Склад 7.7») пользователи и разработчики часто сталкиваются с некорректным распределением задолженности при переносе долгов между договорами или контрагентами. Рассмотрим подробнее причину возникновения этой проблемы в коде проведения документа КорректировкаДолга и разберем проверенные способы её решения.

Выясним причину возникновения проблемы

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


ТаблДолгов.НоваяСтрока();
ТаблДолгов.КредДокумент = ТекущийДокумент();
ТаблДолгов.ВидДолга = глВД.Аванс; // Проблемная строка

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

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

Проанализируем последствия ошибки в механике 1С 7.7

Жесткое присвоение авансового вида долга нарушает базовые принципы учета взаиморасчетов. Рассмотрим основные негативные последствия этой ситуации:

Искажение разреза регистра взаиморасчетов: Регистры накопления взаиморасчетов в «1С:Торговля и Склад 7.7» ведутся в разрезе документов-оснований и конкретных видов задолженности (значений перечисления ВидыДолга: товарный долг, аванс, предоплата и т.д.). Установка авансового вида долга там, где реальной предоплаты не было, разрывает целостность аналитики.
Сбой работы алгоритмов автоматического зачета: Глобальные процедуры распределения и зачета задолженностей ориентируются на комбинацию документа-основания и типа долга. Ложное появление аванса заставляет систему считать, что контрагент переплатил средства, в результате чего блокируется автоматический зачет последующих отгрузок по FIFO.
Ошибки в налоговом учете НДС: При проведении поступающих платежей система анализирует актуальные остатки взаиморасчетов. Ложное наличие остатка с видом Аванс провоцирует ошибочную регистрацию авансового НДС, автоматическое формирование авансовых счетов-фактур и искажение показателей Книги продаж.
Каскадные ошибки при восстановлении последовательности: Стандартная процедура восстановления последовательности документов при перепроведении пересчитывает зачеты авансов за прошлые даты, что приводит к размытию остатков по всей цепочке документов контрагента.

Разберем по шагам варианты решения проблемы в коде

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

Вариант 1. Добавление реквизита «Вид долга» на форму документа

Самый наглядный и гибкий способ — предоставить пользователю возможность самостоятельно указывать тип корректируемого долга на форме документа, задав по умолчанию наиболее частые значения.

Добавим в реквизиты документа КорректировкаДолга новый реквизит ВидДолга (тип: перечисление ВидыДолга).
Выведем данный реквизит на форму документа для выбора пользователем.
В модуле проведение заменим жесткое присвоение значением из реквизита документа:


ТаблДолгов.НоваяСтрока();
ТаблДолгов.КредДокумент = ТекущийДокумент();
// Используем реквизит формы вместо жесткой константы
Если ПустоеЗначение(ВидДолгаПоУмолчанию) = 0 Тогда
    ТаблДолгов.ВидДолга = ВидДолгаПоУмолчанию;
Иначе
    ТаблДолгов.ВидДолга = глВД.ТоварныйДолг; // или глВД.Аванс в зависимости от задачи
КонецЕсли;

Вариант 2. Динамическое наследование исходного вида долга

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

Проанализируем пример логики наследования:


// Определяем исходный вид долга по анализируемой строке/документу
ИсходныйВидДолга = ТаблицаИсходныхЗаписией.ВидДолга;

ТаблДолгов.НоваяСтрока();
ТаблДолгов.КредДокумент = ПервоначальныйДокументПоставки; 
ТаблДолгов.ВидДолга = ИсходныйВидДолга;

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

Вариант 3. Разделение логики по видам операций

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

Альтернативные и обходные варианты

Если внесение изменений в конфигуратором запрещено или временно невозможно, применяются следующие обходные способы:

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

Корректировка прошлых периодов внешней обработкой: Если некорректные записи с видом Аванс уже попали в закрытые периоды, их исправление выполняют специализированными внешними обработками, корректирующими движения конкретных документов без полного перепроведения всей цепочки.