Почему в 1С:УНФ после возврата товара от клиента по заказу остается долг?

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

Анализ причин: почему УНФ показывает долг?

Чтобы понять корень проблемы, нужно проанализировать, как 1С:УНФ учитывает оплату по заказам. Ключевая информация об оплате заказов хранится не в одном, а в нескольких регистрах, которые отвечают за разные контуры учета.

1. Общие взаиморасчеты: За общий баланс с контрагентом (кто кому и сколько должен в целом) отвечают регистры взаиморасчетов. В них корректно отражаются все операции: отгрузка (увеличивает долг клиента), оплата (уменьшает долг), возврат товара (уменьшает долг), возврат денег (увеличивает долг). Именно поэтому в отчете «Расчеты с покупателями» вы видите нулевой баланс.
2. Оперативный учет по заказам: За состояние конкретного заказа (процент отгрузки, процент оплаты) отвечают другие, специализированные регистры. В частности, данные для колонки «Оплачено» в списке заказов берутся из регистра сведений ФактОплатыЗаказов, который, в свою очередь, наполняется на основе движений регистра накопления ОплатаСчетовИЗаказов.

И вот здесь кроется главная причина проблемы. Стандартный механизм УНФ устроен так, что:

• Приходный кассовый ордер (ПКО) от клиента делает положительное движение по регистру ОплатаСчетовИЗаказов в привязке к заказу.
• Расходный кассовый ордер (РКО) на возврат денег клиенту делает отрицательное (сторнирующее) движение по этому же регистру, также в привязке к заказу.

В результате система считает, что по данному заказу итоговая сумма оплаты уменьшилась на сумму возврата. Если заказ был на 10 000 руб., оплата 10 000 руб., а затем возврат денег на 3 000 руб., то регистр ОплатаСчетовИЗаказов покажет, что по этому заказу оплачено всего 7 000 руб. Отсюда и появляется «долг» в 3 000 руб. в отчетах по заказам, хотя по факту клиент ничего не должен.

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

Подход 1: Изменение логики проведения документа возврата денег

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

Разберем по шагам:

1. Определяем точку вмешательства. Нам нужно изменить поведение документа Расход из кассы (РКО) с видом операции «Возврат покупателю».
2. Формулируем логику изменения. Необходимо сделать так, чтобы при проведении такого РКО не формировалось движение по регистру накопления ОплатаСчетовИЗаказов. В этом случае возврат денег будет корректно отражен в общих взаиморасчетах, но не будет "отнимать" сумму оплаты от первоначального заказа.
3. Реализация. Это потребует программной доработки конфигурации, как правило, через механизм расширений, чтобы не снимать систему с поддержки. В модуле проведения документа Расход из кассы нужно добавить условие, которое будет анализировать вид операции.

Концептуально, логика может выглядеть так (это псевдокод для понимания идеи):

// В процедуре проведения документа "Расход из кассы"

// ... стандартный код проведения ...

// Формирование движений по регистру оплаты заказов
Движение = Движения.ОплатаСчетовИЗаказов.Добавить();
Движение.ВидДвижения = ВидДвиженияНакопления.Расход;

// НАША ДОРАБОТКА: Проверяем, является ли операция возвратом покупателю
Если НЕ (ЭтотОбъект.ВидОперации = Перечисления.ВидыОперацийРКО.ВозвратПокупателю) Тогда
    // Если это НЕ возврат, то делаем движение по регистру оплаты заказов, как обычно
    Движение.ЗаказПокупателя = ...;
    Движение.Сумма = ...;
    // ... и другие поля ...
КонецЕсли;

// Если же это возврат покупателю, то код внутри условия НЕ выполнится,
// и движение по регистру ОплатаСчетовИЗаказов создано не будет.

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

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

Подход 2: Сохранение стандартной логики и использование правильных отчетов

Этот подход методологически более верный и не требует доработки конфигурации. Он основан на понимании, что «долг» в заказе — это не ошибка, а информация для анализа.

Принципы работы:

1. Разделяем отчеты по задачам.
   • Для контроля фактической задолженности клиента используем отчет «Расчеты с покупателями» или «Взаиморасчеты». Он всегда покажет реальное сальдо.
   • Для анализа эффективности сделки используем отчет «Анализ заказа покупателя». Да, он покажет «осталось оплатить» сумму, равную возврату. Это сигнал для менеджера или руководителя, что по этому заказу была нештатная ситуация (возврат), и итоговая сумма сделки оказалась меньше первоначальной.
2. Используем статусы заказов. После того как все операции по заказу завершены (включая отгрузку, оплату и все возвраты), переведите заказ в финальный статус, например, «Закрыт» или «Выполнен». Это будет служить сигналом для всех сотрудников, что по данному заказу никаких дальнейших действий не требуется, даже если в нем есть аналитические «хвосты». Можно настроить условное оформление списка, чтобы закрытые заказы, например, окрашивались в серый цвет, визуально отделяя их от активной работы.
3. Создаем комплексный отчет. Если стандартных отчетов недостаточно, можно создать собственный отчет, который будет выводить полную картину по заказу в одной строке: Сумма заказа, Отгружено, Оплачено, Сумма возврата, Итоговая выручка, Итоговый долг. Это наиболее гибкое и мощное решение для управленческого анализа, которое сохраняет всю историю операций.

Подход 3: Использование штатного документа «Корректировка долга»

В 1С:УНФ есть универсальный инструмент для управления задолженностью — документ Корректировка долга. Его можно использовать, чтобы вручную «отвязать» сумму возврата от конкретного заказа, не прибегая к программированию.

Схема действий:

1. После оформления возврата товара и денег у вас по заказу образуется «переплата» (если смотреть с точки зрения оплаченной суммы) или «недоплата» (если смотреть на итоговую сумму).
2. Создаем документ Корректировка долга.
3. С помощью операции, например, «Перенос задолженности» или «Взаимозачет», можно "схлопнуть" задолженность, образовавшуюся по заказу, с суммой возврата. Фактически, вы переносите сумму оплаты с аналитики «Заказ покупателя №...» на общую аналитику расчетов с клиентом или на аналитику документа возврата.

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

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