Как правильно рассчитать просроченную задолженность с учетом индивидуальной отсрочки контрагента?

← На главную

При разработке отчетов по дебиторской задолженности в 1С часто возникает задача: вывести остатки по контрагентам, учитывая индивидуальный срок отсрочки оплаты, заданный в карточке контрагента. На первый взгляд кажется, что достаточно просто вычесть 30 дней из текущей даты и передать это значение в виртуальную таблицу регистра накопления. Однако, как мы сейчас выясним, такой подход является технически невозможным и методологически неверным.

Почему нельзя просто изменить параметр даты в запросе к виртуальной таблице?

Рассмотрим ситуацию: мы имеем справочник Контрагенты с реквизитом ОтстрочкаОплаты. Мы хотим получить конечный остаток на дату ТекущаяДата - ОтстрочкаОплаты. Главная техническая проблема заключается в том, что виртуальные таблицы регистра накопления (например, ОстаткиИОбороты) формируются до момента соединения данных с вашими справочниками.

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

Методологическая ошибка логики расчета

Даже если бы мы смогли «обмануть» систему, логика расчета задолженности «на дату» привела бы к ошибкам. Рассмотрим пример: клиент должен оплатить товар в течение 30 дней. Если у него есть старый долг и новый долг, простая дата отсечки может отсечь не те суммы. Правильный подход к учету задолженности требует анализа момента возникновения каждого конкретного долга.

Как правильно реализовать отчет в 1С

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

Использование детальных записей (разрез по документам): Вместо того чтобы полагаться на виртуальные таблицы остатков, необходимо получить данные из физической таблицы регистра накопления. Выбирайте все неоплаченные движения в разрезе документов расчетов.
Применение СКД (Системы компоновки данных): Это наиболее мощный инструмент для данной задачи. В СКД вы можете реализовать объединение наборов данных. Первый набор данных — это остатки по регистру в разрезе документов, а второй набор — справочная информация по контрагентам. Связь наборов данных внутри СКД позволит отфильтровать документы, срок жизни которых (ТекущаяДата - ДатаДокумента) превышает значение ОтстрочкаОплаты.
Метод ФИФО (First In, First Out): Профессиональный подход подразумевает, что задолженность гасится в порядке возникновения. В отчете необходимо вычислять не просто остаток, а «возраст» каждой суммы, зафиксированной в регистрах расчетов.

Алгоритм реализации через СКД (пошагово)

Рассмотрим подробнее, как организовать работу в СКД:

Шаг 1: Создадим первый набор данных «Запрос», который выберет все движения регистра накопления с остатками по документам без отбора по дате.

Шаг 2: Создадим второй набор данных «Запрос», который выберет контрагентов и их реквизит ОтстрочкаОплаты.

Шаг 3: На вкладке «Связи наборов данных» свяжем эти два набора по полю Контрагент.

Шаг 4: Используем вычисляемое поле, где пропишем условие просрочки:


// В выражении поля СКД:
ВЫБОР 
    КОГДА РАЗНОСТЬДАТ(ДатаДокумента, ТекущаяДата(), ДЕНЬ) > ОтстрочкаОплаты 
    ТОГДА СуммаОстаток 
    ИНАЧЕ 0 
КОНЕЦ

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

Использование механизмов типовых конфигураций

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

Заключение: Не пытайтесь вычислить задолженность через «магическую дату» в виртуальной таблице. Правильный путь — получение детальных данных, их сопоставление с параметрами контрагента в СКД и последующая фильтрация на основе разности дат возникновения обязательств.