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