СКД, кросс-таблица, получение итогов через ВВ и ВВГМ
Коллеги, помогите, плиз, кто сталкивался.
Вкратце: есть СКД-отчет, набором данных для которого служит запрос, собирающий данные по закупкам номенклатуры в разрезе календарных годов. Пусть для простоты нас интересует только количество.
Отчет в виде кросс-таблицы, по строкам идут группировки по категории номенклатуры, затем по номенклатуре, по колонкам - годы (2024, 2025 итд). Категория номенклатуры это некий доп. реквизит номенклатуры, типа "запчасти", "вакцина" итд, не суть, важно, что это просто некое объединение номенклатуры в группы.
задача: пользователь задает период, например 01.01.2023 - 31.12.2025
Отчет показывает закупаемое кол-во по годам в разрезе категорий ном-ры и самой номенклатуры, и важно, начиная со 2го года периода нужно видеть прирост (дельту) по количеству: ну то есть в 2024 году видеть Колво2024-Колво2023, в 2025 видеть Колво2025-Колво2024. Но приростом в данном контексте считаем только тот случай, когда кол-во в предыдущем году не равно 0. То есть если закупали 1, а теперь 4, то это прирост = +3, если закупали 5, а стали 0, то это прирост "-5", а вот если закупали 0, а стали 2, то это не прирост в данном контексте (там будет 0 в графе). Так вот пономенклатурно нужно посчитать эти приросты, а вот на верхнем уровне иерархии (по категории номенклатуры) их просто сложить.
Уточнение: за какой-либо год из периода данных в наборе данных по той или иной номенклатуре может не быть, то есть строки в явном виде "2023 Ном-ра1 Колво 0" в наборе данных нет.
Так вот, создано вычисляемое поле ОтклонениеКоличество. Выражение 0.
В Ресурсах для этого поля отдельно задаю выражение для расчета итогов по номенклатуре:
и отдельно для вышестоящей группировки "КатегорияНоменклатуры"
На уровне номенклатуре всё считается как ожидается.
На уровне итога по верхней группировке лажа. Опытным путём выяснил, что он почему-то берет и вычитает из количеств по номенклатурам итоговое количество прошлого года по этому верхнему уровню ну или что-то такое, затем ожидаемо складывает.
Имена у группировок в структуре отчета заданы. Роль у "ПериодГод" стоит.
На уровне номенклатуры мы корректно считаем отклонения. Затем на верхнем уровне их просто нужно пробежаться и сложить. Но работает криво, в чем ошибка?
Вкратце: есть СКД-отчет, набором данных для которого служит запрос, собирающий данные по закупкам номенклатуры в разрезе календарных годов. Пусть для простоты нас интересует только количество.
Отчет в виде кросс-таблицы, по строкам идут группировки по категории номенклатуры, затем по номенклатуре, по колонкам - годы (2024, 2025 итд). Категория номенклатуры это некий доп. реквизит номенклатуры, типа "запчасти", "вакцина" итд, не суть, важно, что это просто некое объединение номенклатуры в группы.
задача: пользователь задает период, например 01.01.2023 - 31.12.2025
Отчет показывает закупаемое кол-во по годам в разрезе категорий ном-ры и самой номенклатуры, и важно, начиная со 2го года периода нужно видеть прирост (дельту) по количеству: ну то есть в 2024 году видеть Колво2024-Колво2023, в 2025 видеть Колво2025-Колво2024. Но приростом в данном контексте считаем только тот случай, когда кол-во в предыдущем году не равно 0. То есть если закупали 1, а теперь 4, то это прирост = +3, если закупали 5, а стали 0, то это прирост "-5", а вот если закупали 0, а стали 2, то это не прирост в данном контексте (там будет 0 в графе). Так вот пономенклатурно нужно посчитать эти приросты, а вот на верхнем уровне иерархии (по категории номенклатуры) их просто сложить.
Уточнение: за какой-либо год из периода данных в наборе данных по той или иной номенклатуре может не быть, то есть строки в явном виде "2023 Ном-ра1 Колво 0" в наборе данных нет.
Так вот, создано вычисляемое поле ОтклонениеКоличество. Выражение 0.
В Ресурсах для этого поля отдельно задаю выражение для расчета итогов по номенклатуре:
Выбор Когда ВычислитьВыражение("ЕстьNull(Сумма(Количество), 0)", "ПериодГод", , "Предыдущая", "Предыдущая", "ПериодГод") <> 0 Тогда
ЕстьNull(Сумма(Количество), 0) - ВычислитьВыражение("ЕстьNull(Сумма(Количество), 0)", "ПериодГод", , "Предыдущая", "Предыдущая", "ПериодГод")
Иначе
0
Конеци отдельно для вышестоящей группировки "КатегорияНоменклатуры"
СУММА(ВычислитьВыражениеСГруппировкойМассив(
"Выбор Когда ВычислитьВыражение(""ЕстьNull(Сумма(Количество), 0)"", ""ПериодГод"", , ""Предыдущая"", ""Предыдущая"", ""ПериодГод"") <> 0 Тогда
ЕстьNull(Сумма(Количество), 0) - ВычислитьВыражение(""ЕстьNull(Сумма(Количество), 0)"", ""ПериодГод"", , ""Предыдущая"", ""Предыдущая"", ""ПериодГод"")
Иначе
0
Конец", "Номенклатура"))На уровне номенклатуре всё считается как ожидается.
На уровне итога по верхней группировке лажа. Опытным путём выяснил, что он почему-то берет и вычитает из количеств по номенклатурам итоговое количество прошлого года по этому верхнему уровню ну или что-то такое, затем ожидаемо складывает.
Имена у группировок в структуре отчета заданы. Роль у "ПериодГод" стоит.
На уровне номенклатуры мы корректно считаем отклонения. Затем на верхнем уровне их просто нужно пробежаться и сложить. Но работает криво, в чем ошибка?
Найденные решения
3.
nedomolkov.ivan
210
24.08.26 12:20
Сейчас в теме
+1.5 $m
Симптом вы описали точно, и он не случайный. ВычислитьВыражениеСГруппировкойМассив
перебирает записи группировки Номенклатура, но вложенное ВычислитьВыражение по
другой оси (ПериодГод, "Предыдущая") в этом переборе не сужается до текущей
номенклатуры: оно считается в контексте той группировки, для которой пишется
ресурс, то есть категории. Отсюда и одинаковые элементы, равные сумме по всей
категории. Компиляцию это не ломает, поэтому выглядит как рабочая конструкция.
Вытаскивать сдвиг на год выражениями ресурса в кросс-таблице я бы вообще не стал.
Дешевле и надёжнее принести предыдущий год в набор данных, и тогда СКД считать
уже нечего.
Схема запроса:
1. Собрать список лет периода и полный крест Номенклатура x Год. Он нужен именно
потому, что у вас строк с нулём в наборе нет, а без них случай "закупали 5,
стало 0" в отчёт не попадёт вообще.
2. К этому кресту двумя левыми соединениями подтянуть количество текущего года
и количество предыдущего (условие Год = Год2 + 1).
3. Прямо в запросе посчитать поле Отклонение:
ВЫБОР КОГДА ЕСТЬNULL(КоличествоПред, 0) <> 0
ТОГДА ЕСТЬNULL(Количество, 0) - ЕСТЬNULL(КоличествоПред, 0)
ИНАЧЕ 0 КОНЕЦ
После этого ресурс на всех уровнях один и тот же: СУММА(Отклонение). По номенклатуре
он даст ваше отклонение, по категории сложит их сами, по итогу тоже. Ни ВВ, ни ВВГМ,
ни ролей, ни "рассчитывать по" - складывать числа СКД умеет без подсказок.
Побочно решается то, что в вашей схеме ещё выстрелит: правило "прирост только если
предыдущий не ноль" делает показатель несовместимым с автоматическим итогом, пока он
живёт в выражении ресурса. Когда он посчитан построчно, итог становится обычной суммой.
перебирает записи группировки Номенклатура, но вложенное ВычислитьВыражение по
другой оси (ПериодГод, "Предыдущая") в этом переборе не сужается до текущей
номенклатуры: оно считается в контексте той группировки, для которой пишется
ресурс, то есть категории. Отсюда и одинаковые элементы, равные сумме по всей
категории. Компиляцию это не ломает, поэтому выглядит как рабочая конструкция.
Вытаскивать сдвиг на год выражениями ресурса в кросс-таблице я бы вообще не стал.
Дешевле и надёжнее принести предыдущий год в набор данных, и тогда СКД считать
уже нечего.
Схема запроса:
1. Собрать список лет периода и полный крест Номенклатура x Год. Он нужен именно
потому, что у вас строк с нулём в наборе нет, а без них случай "закупали 5,
стало 0" в отчёт не попадёт вообще.
2. К этому кресту двумя левыми соединениями подтянуть количество текущего года
и количество предыдущего (условие Год = Год2 + 1).
3. Прямо в запросе посчитать поле Отклонение:
ВЫБОР КОГДА ЕСТЬNULL(КоличествоПред, 0) <> 0
ТОГДА ЕСТЬNULL(Количество, 0) - ЕСТЬNULL(КоличествоПред, 0)
ИНАЧЕ 0 КОНЕЦ
После этого ресурс на всех уровнях один и тот же: СУММА(Отклонение). По номенклатуре
он даст ваше отклонение, по категории сложит их сами, по итогу тоже. Ни ВВ, ни ВВГМ,
ни ролей, ни "рассчитывать по" - складывать числа СКД умеет без подсказок.
Побочно решается то, что в вашей схеме ещё выстрелит: правило "прирост только если
предыдущий не ноль" делает показатель несовместимым с автоматическим итогом, пока он
живёт в выражении ресурса. Когда он посчитан построчно, итог становится обычной суммой.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Другими словами, допускает ли вообще платформа использование таких вложенных конструкций, как
в выражениях ресурсов в отчетах вида кросс-таблица, с группировкой по номенклатуре по строкам и по годам по колонкам.
Потому что данный код ошибку компиляции не вызывает, но, будучи указанным в кач-ве выражения ресурса для группировки, вышестоящей на один уровень относительно "Номенклатура", вместо ожидаемого массива со значениями количеств по каждой номенклатуре по предыдущему году (напомню, группировка по колонкам по годам) возвращает одинаковые элементы, каждый из которых это сумма количеств по ВСЕЙ номенклатуре, входящей в эту самую вышестоящую группировку, в "рассчитать по.." для которой мы и вписываем это выражение.
ВычислитьВыражениеСГруппировкойМассив("ВычислитьВыражение(""ЕстьNull(Сумма(Количество), 0)"", ""ПериодГод"", ""Группировка"", ""Предыдущая"", ""Предыдущая"", ""ПериодГод Возр"")", "Номенклатура")в выражениях ресурсов в отчетах вида кросс-таблица, с группировкой по номенклатуре по строкам и по годам по колонкам.
Потому что данный код ошибку компиляции не вызывает, но, будучи указанным в кач-ве выражения ресурса для группировки, вышестоящей на один уровень относительно "Номенклатура", вместо ожидаемого массива со значениями количеств по каждой номенклатуре по предыдущему году (напомню, группировка по колонкам по годам) возвращает одинаковые элементы, каждый из которых это сумма количеств по ВСЕЙ номенклатуре, входящей в эту самую вышестоящую группировку, в "рассчитать по.." для которой мы и вписываем это выражение.
3.
nedomolkov.ivan
210
24.08.26 12:20
Сейчас в теме
+1.5 $m
Симптом вы описали точно, и он не случайный. ВычислитьВыражениеСГруппировкойМассив
перебирает записи группировки Номенклатура, но вложенное ВычислитьВыражение по
другой оси (ПериодГод, "Предыдущая") в этом переборе не сужается до текущей
номенклатуры: оно считается в контексте той группировки, для которой пишется
ресурс, то есть категории. Отсюда и одинаковые элементы, равные сумме по всей
категории. Компиляцию это не ломает, поэтому выглядит как рабочая конструкция.
Вытаскивать сдвиг на год выражениями ресурса в кросс-таблице я бы вообще не стал.
Дешевле и надёжнее принести предыдущий год в набор данных, и тогда СКД считать
уже нечего.
Схема запроса:
1. Собрать список лет периода и полный крест Номенклатура x Год. Он нужен именно
потому, что у вас строк с нулём в наборе нет, а без них случай "закупали 5,
стало 0" в отчёт не попадёт вообще.
2. К этому кресту двумя левыми соединениями подтянуть количество текущего года
и количество предыдущего (условие Год = Год2 + 1).
3. Прямо в запросе посчитать поле Отклонение:
ВЫБОР КОГДА ЕСТЬNULL(КоличествоПред, 0) <> 0
ТОГДА ЕСТЬNULL(Количество, 0) - ЕСТЬNULL(КоличествоПред, 0)
ИНАЧЕ 0 КОНЕЦ
После этого ресурс на всех уровнях один и тот же: СУММА(Отклонение). По номенклатуре
он даст ваше отклонение, по категории сложит их сами, по итогу тоже. Ни ВВ, ни ВВГМ,
ни ролей, ни "рассчитывать по" - складывать числа СКД умеет без подсказок.
Побочно решается то, что в вашей схеме ещё выстрелит: правило "прирост только если
предыдущий не ноль" делает показатель несовместимым с автоматическим итогом, пока он
живёт в выражении ресурса. Когда он посчитан построчно, итог становится обычной суммой.
перебирает записи группировки Номенклатура, но вложенное ВычислитьВыражение по
другой оси (ПериодГод, "Предыдущая") в этом переборе не сужается до текущей
номенклатуры: оно считается в контексте той группировки, для которой пишется
ресурс, то есть категории. Отсюда и одинаковые элементы, равные сумме по всей
категории. Компиляцию это не ломает, поэтому выглядит как рабочая конструкция.
Вытаскивать сдвиг на год выражениями ресурса в кросс-таблице я бы вообще не стал.
Дешевле и надёжнее принести предыдущий год в набор данных, и тогда СКД считать
уже нечего.
Схема запроса:
1. Собрать список лет периода и полный крест Номенклатура x Год. Он нужен именно
потому, что у вас строк с нулём в наборе нет, а без них случай "закупали 5,
стало 0" в отчёт не попадёт вообще.
2. К этому кресту двумя левыми соединениями подтянуть количество текущего года
и количество предыдущего (условие Год = Год2 + 1).
3. Прямо в запросе посчитать поле Отклонение:
ВЫБОР КОГДА ЕСТЬNULL(КоличествоПред, 0) <> 0
ТОГДА ЕСТЬNULL(Количество, 0) - ЕСТЬNULL(КоличествоПред, 0)
ИНАЧЕ 0 КОНЕЦ
После этого ресурс на всех уровнях один и тот же: СУММА(Отклонение). По номенклатуре
он даст ваше отклонение, по категории сложит их сами, по итогу тоже. Ни ВВ, ни ВВГМ,
ни ролей, ни "рассчитывать по" - складывать числа СКД умеет без подсказок.
Побочно решается то, что в вашей схеме ещё выстрелит: правило "прирост только если
предыдущий не ноль" делает показатель несовместимым с автоматическим итогом, пока он
живёт в выражении ресурса. Когда он посчитан построчно, итог становится обычной суммой.
Добрый день! Спасибо за ответ!
(3)
Да, я уже к этому косвенно и сам пришёл опытным путём, анализируя на простеньких наборах данных логику подсчета и убрав самую наружную функцию СУММА, чтобы видеть собираемый ВВГМ массив.
Но ёклм - я за последние несколько дней перечитал, наверно, все, что есть в Интернете на эту тему (начиная от ИТС и документации, до тем на ИС и мисте и проч.). Нигде об этом не сказано в явном виде, что так это не работает. Равно как и то, что так работает:) Поэтому и исходил из того, что так должно работать, а я что-то не так делаю. Но эксперименты с синтаксисом, ролями полей и всем остальным ничего не дали. Пришлось временно сдаться, т.к. бизнес ждёт отчет, и полностью переписать логику, перенеся часть расчетов в запрос (всё так и сделал, имею сгруппированные данные по ном-ре и годам, но с пропусками по годам, выбрал из них всю номенклатуру, скрестил полным соед. с заранее полученной вт таблицей всех годов, получил вт всех сочетаний номенклатуры и годов, а затем вт с подтянутыми данными, если они есть, либо 0, если нет. Рассчитал все дельты в запросе, сделав 2 левых соед. с данными пред. года и первого года периода. Затем в СКД в ресурсах оставил только всякие расчеты % изменения год/году, там ВВ со сдвигами по периоду нормально работает. У меня еще задача осложняется тем, что в отчете не сравнивается фиксированно 2 года, а либо произвольное кол-во годов (нужно сравнение год к предыдущему), либо последний год периода с первым. Поэтому и группировка по Году в кросс-таблице в графах. И казалось хорошей идея использовать все эти фишки СКД.
(3)
...вложенное ВычислитьВыражение по
другой оси (ПериодГод, "Предыдущая") в этом переборе не сужается до текущей
номенклатуры: оно считается в контексте той группировки, для которой пишется
ресурс, то есть категории
другой оси (ПериодГод, "Предыдущая") в этом переборе не сужается до текущей
номенклатуры: оно считается в контексте той группировки, для которой пишется
ресурс, то есть категории
Да, я уже к этому косвенно и сам пришёл опытным путём, анализируя на простеньких наборах данных логику подсчета и убрав самую наружную функцию СУММА, чтобы видеть собираемый ВВГМ массив.
Но ёклм - я за последние несколько дней перечитал, наверно, все, что есть в Интернете на эту тему (начиная от ИТС и документации, до тем на ИС и мисте и проч.). Нигде об этом не сказано в явном виде, что так это не работает. Равно как и то, что так работает:) Поэтому и исходил из того, что так должно работать, а я что-то не так делаю. Но эксперименты с синтаксисом, ролями полей и всем остальным ничего не дали. Пришлось временно сдаться, т.к. бизнес ждёт отчет, и полностью переписать логику, перенеся часть расчетов в запрос (всё так и сделал, имею сгруппированные данные по ном-ре и годам, но с пропусками по годам, выбрал из них всю номенклатуру, скрестил полным соед. с заранее полученной вт таблицей всех годов, получил вт всех сочетаний номенклатуры и годов, а затем вт с подтянутыми данными, если они есть, либо 0, если нет. Рассчитал все дельты в запросе, сделав 2 левых соед. с данными пред. года и первого года периода. Затем в СКД в ресурсах оставил только всякие расчеты % изменения год/году, там ВВ со сдвигами по периоду нормально работает. У меня еще задача осложняется тем, что в отчете не сравнивается фиксированно 2 года, а либо произвольное кол-во годов (нужно сравнение год к предыдущему), либо последний год периода с первым. Поэтому и группировка по Году в кросс-таблице в графах. И казалось хорошей идея использовать все эти фишки СКД.
5.
nedomolkov.ivan
210
24.08.26 14:33
Сейчас в теме
(4)
(4) Про документацию вы правы, в ИТС каждая функция описана сама по себе, а про их
композицию не сказано ничего. Правило, которое из этого случая вытаскивается, звучит
так: ВычислитьВыражениеСГруппировкойМассив сужает контекст только по той группировке,
которую вы ему назвали. Вложенное ВычислитьВыражение со смещением "Предыдущая"
отсчитывает позицию по структуре той группировки, где лежит сам ресурс, а не по
текущему элементу перебора. Пока обе функции работают по одной оси, это незаметно.
В кросс-таблице оси разные, и вложенный вызов молча остаётся снаружи.
Раз уж дельты вы унесли в запрос, гляньте заодно на процент. Он у вас остался
в ресурсах на ВВ, и там та же несостыковка, только тише. Правило "прирост считаем,
только если предыдущий год не ноль" в дельте учтено, а в проценте через ВВ нет:
числитель там полная разница, включая номенклатуру, которая появилась с нуля.
На уровне номенклатуры этого не видно, на категории будет: колонка дельты покажет
одно, колонка процента посчитается от другого набора позиций, и между собой они
не сойдутся.
Проверяется за минуту - возьмите категорию, где хоть одна позиция стартовала
с нуля, и сравните процент с дельтой, делённой на прошлый год.
Лечится тем же ходом, что и дельта. Количество предыдущего года у вас в наборе
уже лежит, значит процент это обычный ресурс:
ВЫБОР КОГДА СУММА(КоличествоПред) <> 0
ТОГДА СУММА(Отклонение) / СУММА(КоличествоПред)
ИНАЧЕ 0 КОНЕЦ
и он верен сразу на всех уровнях: позиции с нулём в прошлом году в знаменатель
ничего не добавляют, поэтому знаменатель сам сходится с тем набором, по которому
считался числитель. Вид в процентах - оформлением поля, а не умножением на 100
в выражении. ВВ из отчёта после этого уходит совсем.
Со сравнением последнего года периода к первому история ровно та же: второе поле
Отклонение в запросе, и обе колонки складываются на любом уровне без ВВ.
о есть категории
(4) Про документацию вы правы, в ИТС каждая функция описана сама по себе, а про их
композицию не сказано ничего. Правило, которое из этого случая вытаскивается, звучит
так: ВычислитьВыражениеСГруппировкойМассив сужает контекст только по той группировке,
которую вы ему назвали. Вложенное ВычислитьВыражение со смещением "Предыдущая"
отсчитывает позицию по структуре той группировки, где лежит сам ресурс, а не по
текущему элементу перебора. Пока обе функции работают по одной оси, это незаметно.
В кросс-таблице оси разные, и вложенный вызов молча остаётся снаружи.
Раз уж дельты вы унесли в запрос, гляньте заодно на процент. Он у вас остался
в ресурсах на ВВ, и там та же несостыковка, только тише. Правило "прирост считаем,
только если предыдущий год не ноль" в дельте учтено, а в проценте через ВВ нет:
числитель там полная разница, включая номенклатуру, которая появилась с нуля.
На уровне номенклатуры этого не видно, на категории будет: колонка дельты покажет
одно, колонка процента посчитается от другого набора позиций, и между собой они
не сойдутся.
Проверяется за минуту - возьмите категорию, где хоть одна позиция стартовала
с нуля, и сравните процент с дельтой, делённой на прошлый год.
Лечится тем же ходом, что и дельта. Количество предыдущего года у вас в наборе
уже лежит, значит процент это обычный ресурс:
ВЫБОР КОГДА СУММА(КоличествоПред) <> 0
ТОГДА СУММА(Отклонение) / СУММА(КоличествоПред)
ИНАЧЕ 0 КОНЕЦ
и он верен сразу на всех уровнях: позиции с нулём в прошлом году в знаменатель
ничего не добавляют, поэтому знаменатель сам сходится с тем набором, по которому
считался числитель. Вид в процентах - оформлением поля, а не умножением на 100
в выражении. ВВ из отчёта после этого уходит совсем.
Со сравнением последнего года периода к первому история ровно та же: второе поле
Отклонение в запросе, и обе колонки складываются на любом уровне без ВВ.
(5)
(5)
Понял, о чем речь, но мне кажется, сейчас все верно считает и по группам. Т.к. я в выражении ресурса при расчете % отклонения по кол-ву использую в числителе выражение именно уже рассчитанное с учетом правила описанного правила "если начкол-во 0, то 0" отклонение.
Раз уж дельты вы унесли в запрос, гляньте заодно на процент. Он у вас остался
в ресурсах на ВВ, и там та же несостыковка, только тише. Правило "прирост считаем,
только если предыдущий год не ноль" в дельте учтено, а в проценте через ВВ нет:
числитель там полная разница, включая номенклатуру, которая появилась с нуля.
На уровне номенклатуры этого не видно, на категории будет: колонка дельты покажет
одно, колонка процента посчитается от другого набора позиций, и между собой они
не сойдутся.
в ресурсах на ВВ, и там та же несостыковка, только тише. Правило "прирост считаем,
только если предыдущий год не ноль" в дельте учтено, а в проценте через ВВ нет:
числитель там полная разница, включая номенклатуру, которая появилась с нуля.
На уровне номенклатуры этого не видно, на категории будет: колонка дельты покажет
одно, колонка процента посчитается от другого набора позиций, и между собой они
не сойдутся.
(5)
числитель там полная разница, включая номенклатуру, которая появилась с нуля.
Понял, о чем речь, но мне кажется, сейчас все верно считает и по группам. Т.к. я в выражении ресурса при расчете % отклонения по кол-ву использую в числителе выражение именно уже рассчитанное с учетом правила описанного правила "если начкол-во 0, то 0" отклонение.
Выбор Когда ВычислитьВыражение("ЕстьNull(Сумма(Количество), 0)", "ПериодГод", , "Предыдущая", "Предыдущая", "ПериодГод Возр") <> 0 Тогда
100 * Сумма(ОтклонениеКоличество_ИзменениеКоличества)
/
ВычислитьВыражение("ЕстьNull(Сумма(Количество), 0)", "ПериодГод", , "Предыдущая", "Предыдущая", "ПериодГод Возр")
Иначе
0
Конец
7.
nedomolkov.ivan
210
24.08.26 15:24
Сейчас в теме
(6) Согласен, снимаю. Я прочитал ваш числитель как разницу через ВВ, а туда идёт поле
из запроса, где правило "предыдущий ноль - значит ноль" уже применено. При таком
числителе всё сходится и по категории тоже: позиции, стартовавшие с нуля, в знаменатель
ничего не добавляют, поэтому знаменатель сам совпадает с тем набором, по которому
посчитан числитель. Расхождения нет, вопрос снят.
Что стоит глянуть - второй режим, последний год периода к первому. Дельту к первому
году вы посчитали в запросе вторым левым соединением, а знаменатель в проценте остался
на ВВ со смещением "Предыдущая", "Предыдущая". Если отдельного выражения на этот режим
нет, то числитель у вас от первого года периода, а знаменатель от предыдущего. Это уже
разные года, и разъедутся они тем сильнее, чем длиннее период. На сравнении год к году
оба совпадают, поэтому со стороны не видно.
Если оставаться на ВВ, для второго режима смещение другое: "Первая", "Первая" вместо
"Предыдущая", "Предыдущая". Но количество первого года у вас в наборе уже лежит полем,
ровно как и количество предыдущего, так что процент сводится к обычному ресурсу
без ВВ совсем:
ВЫБОР КОГДА СУММА(КоличествоБаза) <> 0
ТОГДА СУММА(Отклонение) / СУММА(КоличествоБаза)
ИНАЧЕ 0 КОНЕЦ
где КоличествоБаза и Отклонение - пара полей под выбранный режим. Тогда переключение
режима меняет пару полей, а не логику расчёта, и результат перестаёт зависеть от того,
какие группировки пользователь оставил в структуре и в каком порядке они идут.
из запроса, где правило "предыдущий ноль - значит ноль" уже применено. При таком
числителе всё сходится и по категории тоже: позиции, стартовавшие с нуля, в знаменатель
ничего не добавляют, поэтому знаменатель сам совпадает с тем набором, по которому
посчитан числитель. Расхождения нет, вопрос снят.
Что стоит глянуть - второй режим, последний год периода к первому. Дельту к первому
году вы посчитали в запросе вторым левым соединением, а знаменатель в проценте остался
на ВВ со смещением "Предыдущая", "Предыдущая". Если отдельного выражения на этот режим
нет, то числитель у вас от первого года периода, а знаменатель от предыдущего. Это уже
разные года, и разъедутся они тем сильнее, чем длиннее период. На сравнении год к году
оба совпадают, поэтому со стороны не видно.
Если оставаться на ВВ, для второго режима смещение другое: "Первая", "Первая" вместо
"Предыдущая", "Предыдущая". Но количество первого года у вас в наборе уже лежит полем,
ровно как и количество предыдущего, так что процент сводится к обычному ресурсу
без ВВ совсем:
ВЫБОР КОГДА СУММА(КоличествоБаза) <> 0
ТОГДА СУММА(Отклонение) / СУММА(КоличествоБаза)
ИНАЧЕ 0 КОНЕЦ
где КоличествоБаза и Отклонение - пара полей под выбранный режим. Тогда переключение
режима меняет пару полей, а не логику расчёта, и результат перестаёт зависеть от того,
какие группировки пользователь оставил в структуре и в каком порядке они идут.
(7)
Это, конечно же, все предусмотрел. У меня отдельные ресурсы на разные режимы работы (= варианты отчета). В выражении для варианта "от первого года периода" идет "Первая" - "Первая" в параметрах ф-ии ВВ, для варианта "год к году" идет "Предыдущая" - "Предыдущая"
А почему остался на ВВ и на формулах в ресурсах для % - в запросе я считаю % отклонения для номенклатуры (т.е. как бы для детальных записей, по сути для группировки номенклатура, т.к. в запросе у меня данные уже сгруппированы по номенклатуре. А % отклонения по верхним уровням группировок (все, что над номенклатурой, т.е. категория или еще что-то) его в запросе нет, поэтому его считаю через ВВ в ресурсах.
Если отдельного выражения на этот режим
нет, то числитель у вас от первого года периода, а знаменатель от предыдущего. Это уже
разные года, и разъедутся они тем сильнее, чем длиннее период. На сравнении год к году
оба совпадают, поэтому со стороны не видно.
нет, то числитель у вас от первого года периода, а знаменатель от предыдущего. Это уже
разные года, и разъедутся они тем сильнее, чем длиннее период. На сравнении год к году
оба совпадают, поэтому со стороны не видно.
Это, конечно же, все предусмотрел. У меня отдельные ресурсы на разные режимы работы (= варианты отчета). В выражении для варианта "от первого года периода" идет "Первая" - "Первая" в параметрах ф-ии ВВ, для варианта "год к году" идет "Предыдущая" - "Предыдущая"
Выбор Когда ВычислитьВыражение("ЕстьNull(Сумма(Количество), 0)", "ПериодГод", , "Первая", "Первая", "ПериодГод Возр") <> 0 Тогда
100 * Сумма(ОтклонениеКоличество_ИзменениеКоличества_ОтПервогоГодаПериодА почему остался на ВВ и на формулах в ресурсах для % - в запросе я считаю % отклонения для номенклатуры (т.е. как бы для детальных записей, по сути для группировки номенклатура, т.к. в запросе у меня данные уже сгруппированы по номенклатуре. А % отклонения по верхним уровням группировок (все, что над номенклатурой, т.е. категория или еще что-то) его в запросе нет, поэтому его считаю через ВВ в ресурсах.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот