Страницы: 1
RSS
Промежуточные значения сводной таблицы и нарастающий итог
 
Гуру экселя, приветствую!

Имеются папки с 5 файлами и файл, где содержится сводная таблица со всеми подключениями.

Файлы консолидируются через Power Query в общую базу данных, и остаются там в виде подключения. Из него уже я делаю сводную таблицу, где в строках идет иерархия: Город, статья, подразделения. Далее столбцы: план\факт и в идеале еще должны стоять столбцы с % вып. плана (оставил 1 для примера).

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

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

А так же хочу узнать, реально ли сделать вдобавок к этому еще и возможность смотреть данные по каждому месяцу, плану/факту в нарастании ? Потому что встроенное вычисление Сводной таблицы делает так только, если у меня будут 12 месяцев факта.

Файлы приложил, нужно только изменить пути к папкам, если скачаете.
 
Доброе время суток.
Версия на Power Pivot (2010). Версия с нарастающими сюда уже не лезет (сколько места не давай - всё едино примеры будут больше :) ). Тут.
Успехов.
Изменено: Андрей VG - 16.05.2018 22:30:48
 
Цитата
Yum написал:
Мне очень интересно узнать, как, имея мои данные, можно сделать так
И тишина. Толи уже и не интересно, то слишком сложно? ;)
 
Андрей VG, нет нет))

Вы невероятный мастер Экселя 8)  Большое спасибо
Мне дико интересно, просто на работе много времени провожу и не могу смотреть все. Только 1 файл посмотрел. Пришел к выводу, что надо учить Power Pivot)
Щас стоит задача адаптировать хотя бы 1й Ваш Файл для моей таблицы, ведь там гораздо больше строк)
Изменено: Yum - 18.05.2018 01:23:16
 
Приветствую всех,

С формулами разобрался, кроме той, что считает нарастание. Она запутанная)) Варюсь дальше в DAX...


В работе столкнулся с важным моментом: я забыл сказать, что статьи содержат еще и подстроки. Таким образом, когда считается итог по городу за месяц, он берет вообще все строки, хотя нужны только определённые. Можно ли как то это предотвратить, имея все, что есть на данный момент ?
Изменено: Yum - 28.05.2018 11:20:52
 
Цитата
Yum написал:
хотя нужны только определённые
Каким образом определенные?
И покажите формулу, которая считает Итог по городу за месяц.
Вот горшок пустой, он предмет простой...
 
PooHkrd,

прикинул простенький пример. Надеюсь не запутал
 
Yum, лучше приложить исходные данные в той структуре как есть со всеми статьями и подстатьями, иначе трудно лечить "по фотографиям". Давайте лучше вернемся к модели, которую сделал Андрей, только добавьте туда подстатьи как они у вас в реальной базе.
 
StepanWolkoff, хорошо, все таки так будет лучше.

Толлько не сразу залью сюда, придется немного поработать в ней
 
Цитата
Yum написал:
Толлько не сразу залью сюда, придется немного поработать в ней
Не забудьте указать и расшифровать этот момент
Цитата
Yum написал:
он берет вообще все строки, хотя нужны только определённые
 
PooHkrd, StepanWolkoff, Андрей VG,

не хватило еще 15 кб, что бы сюда прилепить
Ссылка
Выходит, там у меня сложная структура статей. Грубо говоря общие доходы считаются так: 1 = 1.1 + 1.2 + 1.3. И вот то, что под номером 1 должно попадать в итоговую сумму по каждому месяцу. А он суммирует 1 +1.1 + 1.2 + 1.3 и каждые входящие в них подстатьи

Я пробовал через средства OLAP, преобразовывал в формулы, но не знаю как обратно сделать сводную,  это уже было от безысходности
 
Цитата
Yum написал:
А он суммирует 1 +1.1 + 1.2 + 1.3
Начну чуть издалека. Тот вариант, который я предложил, на самом деле костыльный и работает только с иерархиями одинаковой глубины. На самом деле, особенно с иерархиями различной глубины, работают следующим образом.
Теперь почему так суммирует. Вы же сами пишете
Цитата
Yum написал:
1 = 1.1 + 1.2 + 1.3.
Тогда почему у вас в статье №1 находятся не принадлежащее ему данные под статьей? Именно это приводит к ошибке вычисления. Если у статьи №1 нет собственных сумм, не относящихся к его под статьям (а для под статьей тоже самое только то что принадлежит им, а не их под под статьям), то тогда её значение только 0, ну, или пусто.
Файл на yandex смогу посмотреть только вечером.
 
Цитата
Yum написал:
не хватило еще 15 кб, что бы сюда прилепить
Даже в архиве с максимальным сжатием? Внешний ресурс, к сожалению мне не доступен. Ну а вообще полностью солидарен с Андреем, у вас не корректная структура хранения данных.
Изменено: PooHkrd - 28.05.2018 16:31:07
Вот горшок пустой, он предмет простой...
 
Файл перезалил для удобства

Цитата
PooHkrd написал:
Тогда почему у вас в статье №1 находятся не принадлежащее ему данные под статьей?
Не оставлять же в статьях  просто 1.1 1.2 и 1.3.

Это не информативно)))  
 
Цитата
Yum написал:
Это не информативно)))  
Ну, коли это так важно, тогда может Максим Зеленский возьмётся за построение меры для такого случая. Я пас.
 
Андрей VG,
а он видел эту тему ? Вдруг он может показать мне как это делать, а я попытаюсь. Если это не сложно)
 
Цитата
Yum написал:
а он видел эту тему ?
Не знаю, я же не его душеприказчик. Напишите в личку, если срочно, возможно заинтересуется темой.
 
Цитата
Yum написал:
Вдруг он может показать мне как это делать, а я попытаюсь.
А что не понятного в ссылке, которую Андрей дал в посте №12? Там же все разжевано, осталось проглотить. Муторно, конечно составлять справочник подчиненности статей друг другу при таком их количестве, но это как бы вам надо, вряд ли кто-то сделает это за вас.
Вот горшок пустой, он предмет простой...
 
Yum, у вас там есть еще столбец "номер статей", что как бы намекает на наличие в исходных данных справочника данных статей, так может подключить его и вдруг станет проще?
 
StepanWolkoff,
к сожалению, нет такой возможности :(
 
StepanWolkoff,

видать, я не так понял сначала.
Вы имеете в виду разбить каждую подиерархию на разные листы, потом закинуть их в PQ, далее в Power Pivot а там уже перевязать их все по номеру статьи ?
 
Имеется ввиду, что нужно задать как минимум попарную цепочку связей родитель - наследник, после чего её можно будет преобразовать в дерево связей в Power Pivot. Либо сразу создать такое дерево и загрузить его в качестве справочника в модель данных, связать с таблицей фактов, вот тогда можно будет составлять меры, которые будут считать правильно.
Вот горшок пустой, он предмет простой...
 
Сделал для разновысотной иерархии. Собственные данные у статей, которые имеют подстатьи оставил только для "1. ДОХОДЫ"; "1.1.2."; "1.2.". Остальные собирают только с листовых подстатей по иерархии. Файл неприлично раздулся - 13 Мбайт. На ЯДиске.
 
Большущее спасибо и Вам и всем, кто отписался в этой теме !
всем бесконечных лучей добра)
Ваш пример мне предстоит еще обмозговать, улетаю в командировку на 3 дня, поэтому не сразу все будет((

Я тоже начал учить, как делать иерархию по ресурсу из поста 12, и вот что вышло. Получилось не так как у Вас) мой вариант ошибочен ?
 
Цитата
Yum написал:
мой вариант ошибочен ?
Вот смотрите, корень дерева в столбце "Name" равен "1. ДОХОДЫ", а уже в столбце "Parent" имеет значение "1. ДОХОДЫ,"
Как вы думаете, с точки зрения сопоставления этих значений, они равны?
Страницы: 1
Наверх