Что значит нарастающий период

Нарастающий итог в SQL

Нарастающий (накопительный) итог долго считался одним из вызовов SQL. Что удивительно, даже после появления оконных функций он продолжает быть пугалом (во всяком случае, для новичков). Сегодня мы рассмотрим механику 10 самых интересных решений этой задачи – от оконных функций до весьма специфических хаков.

В электронных таблицах вроде Excel нарастающий итог вычисляется очень просто: результат в первой записи совпадает с её значением:

… а затем мы суммируем текущее значение и предыдущий итог.

Появление в таблице двух и более групп несколько усложняет задачу: теперь мы считаем несколько итогов (для каждой группы отдельно). Впрочем, и здесь решение лежит на поверхности: необходимо каждый раз проверять, к какой группе принадлежит текущая запись. Click and drag, и работа выполнена:

Как можно заметить, подсчёт нарастающего итога связан с двумя неизменными составляющими:
(а) сортировкой данных по дате и
(б) обращением к предыдущей строке.

Но что SQL? Очень долго в нём не было нужного функционала. Необходимый инструмент – оконные функции – впервые появился только стандарте SQL:2003. К этому моменту они уже были в Oracle (версия 8i). А вот реализация в других СУБД задержалась на 5-10 лет: SQL Server 2012, MySQL 8.0.2 (2018 год), MariaDB 10.2.0 (2017 год), PostgreSQL 8.4 (2009 год), DB2 9 для z/OS (2007 год), и даже SQLite 3.25 (2018 год).

1. Оконные функции

Оконные функции – вероятно, самый простой способ. В базовом случае (таблица без групп) мы рассматриваем данные, отсортированные по дате:

… но нас интересуют только строки до текущей:

В конечном итоге, нам нужна сумма с этими параметрами:

А полный запрос будет выглядеть так:

В случае нарастающего итога по группам (поле grp ) нам требуется только одна небольшая правка. Теперь мы рассматриваем данные как разделённые на «окна» по признаку группы:

Чтобы учесть это разделение необходимо использовать ключевое слово partition by :

И, соответственно, считать сумму по этим окнам:

Тогда весь запрос преобразуется таким образом:

Производительность оконных функций будет зависеть от специфики вашей СУБД (и её версии!), размеров таблицы, и наличия индексов. Но в большинстве случаев этот метод будет самым эффективным. Тем не менее, оконные функции недоступны в старых версиях СУБД (которые ещё в ходу). Кроме того, их нет в таких СУБД как Microsoft Access и SAP/Sybase ASE. Если необходимо вендоро-независимое решение, следует обратить внимание на альтернативы.

2. Подзапрос

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

Такой подзапрос должен считать сумму значений с датой до текущей (и включая текущую): .

Что в коде выглядит так:

Чуть более эффективным будет решение, в котором подзапрос считает итог до текущей даты (но не включая её), а затем суммирует его со значением в строке:

В случае нарастающего итога по нескольким группам нам необходимо использовать коррелированный подзапрос:

Условие g.grp = t2.grp проверяет строки на вхождение в группу (что, в принципе, сходно с работой partition by grp в оконных функциях).

3. Внутреннее соединение

Поскольку подзапросы и джойны взаимозаменяемы, мы легко можем заменить одно на другое. Для этого необходимо использовать Self Join, соединив два экземпляра одной и той же таблицы:

Как можно заметить, условие фильтрации в подзапросе t2.dt стало условием соединения. Кроме того, чтобы использовать агрегирующую функцию sum() нам необходима группировка по дате и значению group by s.dt, s.val .

Точно также можно сделать для случая с разными группами grp :

4. Декартово произведение

Раз уж мы заменили подзапрос на join, то почему бы не попробовать декартово произведение? Это решение потребует только минимальных правок:

Или для случая с группами:

Перечисленные решения (подзапрос, inner join, cartesian join) соответсвуют SQL-92 и SQL:1999, а потому будут доступны практически в любой СУБД. Основная проблема всех этих решений в низкой производительности. Это не велика беда, если мы материализуем таблицу с результатом (но ведь всё равно хочется большей скорости!). Дальнейшие методы куда более эффективны (с поправкой на уже указанные специфику конкретных СУБД и их версий, размер таблицы, индексы).

5. Рекурсивный запрос

Один из более специфических подходов – это рекурсивный запрос в common table expression. Для этого нам необходим «якорь» – запрос, возвращающий самую первую строку:

Затем к «якорю» с помощью union all присоединяются результаты рекурсивного запроса. Для этого можно опереться на поле даты dt , прибавляя у нему по одному дню:

Часть кода, добавляющая один день, не универсальна. Например, это r.dt = dateadd(day, 1, cte.dt) для SQL Server, r.dt = cte.dt + 1 для Oracle, и т.д.

Совместив «якорь» и основной запрос, мы получим окончательный результат:

Решение для случая с группами будет ненамного сложнее:

6. Рекурсивный запрос с функцией row_number()

Предыдущее решение опиралось на непрерывность поля даты dt с последовательным приростом на 1 день. Мы избежать этого, используя оконную функцию row_number() , которая нумерует строки. Конечно, это нечестно – ведь мы собрались рассматривать альтернативы оконным функциям. Тем не менее, это решение может быть своего рода proof of concept: ведь на практике может быть поле, заменяющее номера строк (id записи). Кроме того, в SQL Server функция row_number() появилась раньше, чем была введена полноценная поддержка оконных функций (включая sum() ).

Итак, для рекурсивного запроса с row_number() нам понадобится два СТЕ. В первом мы только нумеруем строки:

… и если номер строки уже есть в таблице, то можно без него обойтись. В следующем запросе обращаемся уже к cte1 :

А целиком запрос выглядит так:

… или для случая с группами:

7. Оператор CROSS APPLY / LATERAL

Один из самых экзотических способов расчёта нарастающего итога – это использование оператора CROSS APPLY (SQL Server, Oracle) или эквивалентного ему LATERAL (MySQL, PostgreSQL). Эти операторы появились довольно поздно (например, в Oracle только с версии 12c). А в некоторых СУБД (например, MariaDB) их и вовсе нет. Поэтому это решение представляет чисто эстетический интерес.

Функционально использование CROSS APPLY или LATERAL идентично подзапросу: мы присоединяем к основному запросу результат вычисления:

… что целиком выглядит так:

Похожим будет и решение для случая с группами:

Итого: мы рассмотрели основные платформо-независимые решения. Но остаются решения, специфичные для конкретных СУБД! Поскольку здесь возможно очень много вариантов, остановимся на нескольких наиболее интересных.

8. Оператор MODEL (Oracle)

Оператор MODEL в Oracle даёт одно из самых элегантных решений. В начале статьи мы рассмотрели общую формулу нарастающего итога:

MODEL позволяет реализовать эту формулу буквально один к одному! Для этого мы сначала заполняем поле total значениями текущей строки

… затем рассчитываем номер строки как row_number() over (order by dt) as rn (или используем готовое поле с номером, если оно есть). И, наконец, вводим правило для всех строк, кроме первой: total[rn >= 2] = total[cv() — 1] + val[cv()] .

Функция cv() здесь отвечает за значение текущей строки. А весь запрос будет выглядеть так:

9. Курсор (SQL Server)

Нарастающий итог – один из немногих случаев, когда курсор в SQL Server не только полезен, но и предпочтителен другим решениям (как минимум до версии 2012, где появились оконные функции).

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

Затем задаём локальные переменные, через которые будет происходить обновление:

После этого обновляем временную таблицу через курсор:

И, наконец, получем нужный результат:

10. Обновление через локальную переменную (SQL Server)

Обновление через локальную переменную в SQL Server основано на недокументированном поведении, поэтому его нельзя считать надёжным. Тем не менее, это едва ли не самое быстрое решение, и этим оно интересно.

Создадим две переменные: одну для нарастающих итогов и табличную переменную:

Сначала заполним @tv данным из основной таблицы

Затем табличную переменную @tv обновим, используя @VarTotal :

… после чего получим окончательный результат:

Резюме: мы рассмотрели топ 10 способов расчёта нарастающего итога в SQL. Как можно заметить, даже без оконных функций эта задача вполне решаема, причём механику решения нельзя назвать сложной.

Источник

Нарастающие итоги в Power Pivot и Power BI

У нас накопились ответы на вопросы о накопительных итогах (даже ответы про накопительные итоги – накапливаются =) Такое впечатление, что с задачей рассчитать нарастающие или накопительные итоги сталкивается практически каждый слушатель наших курсов. И вопрос стоит даже не в том, какую формулу использовать.

Обычно всех интересуют нюансы. Например, как «остановить» нарастающий итог, чтобы он не отображался в периодах, где данных еще нет. Или как считать такой итог не в рамках года, а за все время.

Немного о нарастающих итогах

Нарастающий итог – это сумма показателей, где к данным текущего периода добавляются суммы предыдущих периодов. Вычисления нарастающих итогов обычно просят руководители, чтобы увидеть показатели с начала месяца, квартала или года, например, продажи или прибыль. Или посмотреть, сколько денег принес проект за все время работы. Совсем специфический случай – моделирование расчетных остатков, переходящих из года в год.

Отсюда, вычисления можно разделить на два вида:
а) внутри периода (с начала месяца, квартала, года);
б) без привязки к периодам.

В Power Pivot и Power BI для расчета нарастающих итогов есть специальные формулы.

DAX-формулы для расчета нарастающих итогов

1. Нарастающие итоги с начала года считаются с помощью формул TOTALYTD или DATESYTD .

YTD = TOTALYTD ( [факт] , ‘ Календарь ‘ [Date] ) или YTD = CALCULATE ( [факт] , DATESYTD ( ‘ Календарь ‘ [Date] ) )

2. Нарастающий итог с начала квартала – формулы TOTALQTD или DATESQTD .

QTD = TOTALQTD ( [факт] , ‘ Календарь ‘ [Date] ) или QTD = CALCULATE ( [факт] , DATESQTD ( ‘ Календарь ‘ [Date] ) )

3. C начала месяца – формулы TOTALMTD или DATESMTD .

MTD = TOTALMTD ( [факт] , ‘ Календарь ‘ [Date] ) или MTD = CALCULATE ( [факт] , DATESMTD ( ‘ Календарь ‘ [Date] ) )

4. Нарастающий итог без привязки к периодам.

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

Источник

Как верно заполнить декларацию по налогу на прибыль нарастающим итогом?

Что такое нарастающий итог при расчете налога на прибыль?

Налоговой базой по налогу на прибыль является денежное выражение прибыли организации (п. 1 ст. 274 НК РФ).

При определении налоговой базы облагаемая прибыль определяется нарастающим итогом с начала налогового периода (п. 7 ст. 274 НК РФ). Исходя из базы за год исчисляется налог.

Авансы по итогам отчетных периодов исчисляются исходя из прибыли, рассчитанной нарастающим итогом с начала налогового периода до окончания отчетного периода (п. 2 ст. 286 НК РФ). Нарастающий итог означает, что прибыль отчетного квартала определяется исходя из доходов и расходов, полученных/понесенных с начала года до отчетной даты. То есть она фактически включает в себя и прибыль/убыток прошлого отчетного периода, и прибыль/убыток текущего.

Как правильно считать авансовые платежи по налогу на прибыль, узнайте в КонсультантПлюс. Если у вас нет доступа к системе, получите пробный онлайн-доступ бесплатно.

Про нарастающий итог в другом отчете читайте в материале «6-НДФЛ заполняется нарастающим итогом с начала года».

Пример расчета налоговой базы

Поясним сказанное на примере.

Допустим, отчетными периодами для организации являются квартал, полугодие и 9 месяцев.

За I квартал ее доходы составили 900 тыс. рублей, а расходы — 750 тыс. рублей.

За II квартал: доходы — 600 тыс., расходы 800 тыс. рублей соответственно.

За III квартал: 1 млн и 700 тыс. рублей.

За IV квартал — 700 тыс. и 800 тыс.

Представим расчет налоговой базы в таблице:

I квартал

Полугодие

9 месяцев

Год

Доходы, тыс.

(900 + 600 + 1 000)

(900 + 600 + 1000 + 700)

Расходы, тыс.

(750 + 800 + 700 + 800)

Финрезультат, тыс.

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

Что в декларации?

Декларация по налогу на прибыль также составляется нарастающим итогом с начала года (п. 2.1 Порядка заполнения, утв. приказом ФНС России от 23.09.2019 № ММВ-7-3/475@).

Если вам нужен образец заполнения декларации по налогу на прибыль за 3 квартал/9 месяцев 2021 года, переходите к образцу от экспертов КонсультантПлюс. Это можно сделать бесплатно, получив пробный тестовый доступ к К+.

В ней вы отражаете доходы и расходы, накопленные с 1 января по дату отчета, и исчисленную из них сумму налога или авансового платежа.

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

Если у вас есть доступ к КонсультантПлюс, проверьте правильно ли вы заполнили декларацию по налогу на прибыль. Если доступа нет, получите пробный онлайн-доступ к правовой системе бесплатно.

Рекомендации по составлению и пример заполнения декларации по налогу на прибыль ищите здесь.

Итоги

Исчисление налога нарастающим итогом означает, что расчет нужно вести исходя из доходов и расходов, полученных (осуществленных) с 1 января по отчетную дату. По этому же принципу заполняется налоговая декларация. Нарастает и сумма налога к уплате, т. к. при ее определении учитываются платежи предыдущих отчетных периодов.

Источник