Как в запросе 1С создать отдельное поле для расчета просроченной задолженности?

Программист 1С v8.3 (Управляемые формы) 1С:Управление торговлей Управленческий учет Торговля и дистрибуция
← На главную

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

Синтаксис условной конструкции ВЫБОР КОГДА в языке запросов

Разберем типичную синтаксическую ошибку. Попытка указать псевдоним поля внутри ветки ТОГДА приводит к синтаксической ошибке при компиляции запроса:


// Ошибочный вариант:
ВЫБОР 
    КОГДА РасчетыСКлиентами.ЗаказКлиента.ДатаПлатежа < &ДатаКон 
        ТОГДА РасчетыСКлиентами.СуммаОстаток КАК Просрочено // Ошибка: псевдоним внутри конструкции
КОНЕЦ

Конструкция ВЫБОР представляет собой единое неделимое выражение. Псевдоним поля (служебное слово КАК) должен объявляться строго после завершающего ключевого слова КОНЕЦ. Кроме того, для числовых полей рекомендуется всегда явно задавать ветку ИНАЧЕ со значением 0, чтобы избежать появления значений NULL при суммировании итогов.

Посмотрим на корректный вариант написания условного выражения:


ВЫБОР
    КОГДА РасчетыСКлиентами.ЗаказКлиента.ДатаПлатежа < &ДатаКон
        ТОГДА РасчетыСКлиентами.СуммаОстаток
    ИНАЧЕ 0
КОНЕЦ КАК Просрочено

Пошаговая сборка и оптимизация запроса по взаиморасчетам

Проанализируем базовый запрос, соединяющий регистр накопления РасчетыСКлиентами.Остатки со справочником или регистром сведений АналитикаУчетаПоПартнерам. Разберем по шагам, как правильно составить запрос с точки зрения производительности СУБД:

  1. Перенос отборов в параметры виртуальной таблицы: Условие ГДЕ, наложенное после соединения, заставляет платформу рассчитывать итоги регистра по всей информационной базе, а затем отсекать ненужные строки. Оптимальнее передавать список аналитик или отбор непосредственно в параметры виртуальной таблицы остатков.
  2. Устранение неявных соединений (разыменования через точку): Обращение РасчетыСКлиентами.ЗаказКлиента.ДатаПлатежа заставляет СУБД выполнять неявный LEFT JOIN к таблице заказов. Если измерение имеет составной тип данных, соединение будет построено со всеми таблицами типов, входящих в составное поле. Надежнее использовать специализированные регистры или явные соединения.

Рассмотрим оптимизированный пример запроса с вычисляемым полем просрочки:


ВЫБРАТЬ РАЗРЕШЕННЫЕ
    РегистрАналитика.Организация КАК Организация,
    РегистрАналитика.Партнер КАК Партнер,
    РегистрАналитика.Контрагент КАК Контрагент,
    РасчетыСКлиентами.ЗаказКлиента КАК ЗаказКлиента,
    РасчетыСКлиентами.СуммаОстаток КАК ОбщийДолг,
    ВЫБОР
        КОГДА РасчетыСКлиентами.ЗаказКлиента.ДатаПлатежа < &ДатаКон
            ТОГДА РасчетыСКлиентами.СуммаОстаток
        ИНАЧЕ 0
    КОНЕЦ КАК Просрочено
ИЗ
    РегистрНакопления.РасчетыСКлиентами.Остатки(
        &ДатаКон,
        АналитикаУчетаПоПартнерам В (
            ВЫБРАТЬ
                Аналитика.КлючАналитики
            ИЗ
                РегистрСведений.АналитикаУчетаПоПартнерам КАК Аналитика
            ГДЕ
                Аналитика.Партнер = &Партнер
        )
    ) КАК РасчетыСКлиентами
    ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.АналитикаУчетаПоПартнерам КАК РегистрАналитика
        ПО РасчетыСКлиентами.АналитикаУчетаПоПартнерам = РегистрАналитика.КлючАналитики

Нюансы расчета просрочки: графики платежей и отсрочка

В реальных конфигурациях (1С:ERP, 1С:Комплексная автоматизация, 1С:Управление торговлей) расчет по единственной дате документа-заказа не всегда дает достоверный результат по следующим причинам:

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