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

← На главную

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

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

Почему виртуальная таблица «ОстаткиИОбороты» не решает задачу?

Рассмотрим, как устроены регистры накопления с поддержкой остатков в платформе 1С:Предприятие. В СУБД для такого регистра создаются две основные таблицы: таблица движений (физическая таблица с записями) и таблица итогов. Таблица итогов хранит агрегированные суммы исключительно в разрезе измерений регистра (например, Контрагент, Договор, Организация). Поле Регистратор, дата и реквизиты движений в таблицу итогов не входят.

Когда мы обращаемся к виртуальной таблице РегистрНакопления.ВзаиморасчетыСКонтрагентами.ОстаткиИОбороты и накладываем условие в параметрах таблицы:


РегистрНакопления.ВзаиморасчетыСКонтрагентами.ОстаткиИОбороты(
    &НачалоПериода,
    &КонецПериода,
    Авто,
    Движения,
    НЕ Регистратор ССЫЛКА Документ.ПриходныйКассовыйОрдер
)

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

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

Решение 1. Расчет остатков через физическую таблицу движений

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

Посмотрим на пример построения запроса:


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

Важные особенности данного метода:

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

Решение 2. Разностный метод (корректировка итогов)

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

Разберем логику разностного расчета по шагам:

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

Этот метод снижает нагрузку на СУБД, так как сканирование физической таблицы происходит только по небольшому количеству кассовых документов с использованием индекса по регистратору.

Решение 3. Архитектурные и методологические альтернативы

Если задача разделения взаиморасчетов по наличным и безналичным операциям является постоянной бизнес-потребностью, правильнее заложить разделение данных на уровне структуры учета:

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