раз это таблица и нет возможности сохранить через файл/сохранить, то практически всегда можно сделать так: ПКМ по таблице/вывести список/Ctrl+S. Всегда выручает.

гуглите Power Pivot - решается элементарно. Есть в эксель с 2016 года, но не во всех. Плюс для 2010-ого года можно скачать отдельной надстройкой.
П.С. база правильная, столбец "уник" лишний.

Была подобная задача, Решил ее так:
В исходной таблице (из которой построена сводная) добавлен столбец "комментарий" - именно в нем нужно писать свои правки, а навигация работает по следующему принципу:
1. при переходе на сводную таблицу срабатывает макрос на автоматическое обновление, чтобы комментарии обновились.
2. для того, чтобы глядя на сводную, добавить новый комментарий, справа от сводной протянуты формулы с гиперссылкой, которая по индексу (естественно, индекс также нужно добавить в исходную таблицу) перенаправляет на соответствующую строку с комментарием в исходной таблице.
3. Пишу нужный комментарий
4. возвращаюсь к сводной (см. пункт 1)
П.С.
а вот в этом случае как раз использовался макрос, который в новую выгрузку  переносил комментарии из текущей таблицы, далее старая таблица удалялась, а сводная ссылалась но новые обновленные данные с перенесенными комментариями. И следующая работа по алгоритму выше. Это как раз то, о чем писал Андрей VG,:

Olga H., спасибо за информацию, гугл говорит, что последнему AutoCad минимум 8, а лучше 16 оперативки надо.

БМВ, спасибо за информацию. поизучаю вопрос - интересно стало.
согласен, работаю с милионами строк (не более 5), 8 гб хватает. Но кто знает, что будет завтра. Я немного дополню вопрос: бывало ли у кого-нибудь так, что 8 гб оперативки стало мало и пришлось расширять память, и по какой причине ее стало не хватать?

Доброго дня, уважаемые!
Выбираю себе ноут для дома и работы, определился с моделью (Xiaomi Mi Notebook Pro 15.6 GTX:Windows Home 10, проц - Core i5 8250U, карта - Nvidia GeForce GTX 1050 4 Гб, оперативка - 8 гб).
Всем он мне нравится, но вот оперативки в нем 8 гб распаяно и расширить не получится, а с 16 гб нет в наличии, или те, что есть, существенно дороже. Кроме PBI и PowerPivot другим специальных программ, жрущих много оперативки пока не использую. И вот мучаюсь, с учетом того сколько сама ОС жрет, сколько любит съедать Хром, хватит ли мне этих 8 гб или же все-таки 16 гб лучше смотреть? У меня на работе на ПК стоит 8 гб и проблем вроде не было никогда, но кто знает, может быть лучше с запасом брать? Поделитесь, пожалуйста своим опытом и советом, хочется денег потратить с умом и не жалеть об этом потом.

и Вам не хворать!
неправда, даты корректно отображаются (по крайней мере в примере). можете проверить с помощью формул =ЕЧИСЛО и =ЕТЕКСТ. Может вопрос в автоматической группировке дат по месяцам в сводной, как в фильтре таблицы?

daVinci, сюда не заглядывали?

Яна Брюханова, Вы, извиняюсь, долго "тупить" будете? Есть решение от форумчан, как Вам его должны объяснить, на пальцах? Читаем правила, все отработано десятками тысяч сообщений: прикладываете пример (не картинку), на основе примера дают решение, в котором уже можно понять как и что работает. Как по другому Вы себе еще представляете, по скайпу что-ли объяснять помогающие должны?

Вам нужно преобразовать исходные данные и 12 столбцов значений по месяцам объединить в один. В Power Query такая операция называется "отменить свертывание столбцов". Итог во вложении.

похоже на то.
bereteli, нужное значение можно получить нехитрой мерой (образец):

а дальше уже думайте, что с этим делать

в эксель вроде только подписи осей автоматически подстраиваются, а подписи данных нет - либо все, либо ничего.

добавлял специально, чтобы как раз использовать как "второй" псевдо-справочник через USERELATIONSHIP, но Максим ясно объяснил про иерархии в #31

а просто строку с ней уберите и все

проверил - работает А логика была следующая: когда я допер, что мне нужны альтернативные даты, чтобыя подумал, что второй справочник будет выходом для данной ситуации. Но заметил, что ТС в календаре уже имеет две иерархии (блин, я еще долго ругался про себя, зачем вторая дата в календаре - только мешает, т.к. по невнимательности в меру не те столбцы вставляешь - а в данном конкретном случае по случайности очень даже пригодилось). Итак я решил использовать вторую иерархию дат, но даже не проверил, что это напрямую прекрасно работает: достаточно развести иерархии дат в фильтре и гистограмме и правильно их в мерах указать.
Максим, еща раз спасибо за науку!

а не, получилось, во вложении.
П.С. Надеюсь, Максим З. предложит свое решение, потому что мое мне не нравится!

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

не, с таким видом среза не получается перенастроить алгоритм расчета.
Во-первых, задача оказалась не такой простой, как может показаться на первый взгляд.. Удалось победить только с помощью дополнительного календаря (правда я сделал "пвседо" календарь с помощью второй связи). Для того, чтобы реализовать такой же алгоритм, но с Вашим фильтром по году и месяцу, нужно переделывать календарь, где ключ связи будет по году и месяцу, а не по дате. Тогда можно меры переделать, а подругому не получится. По крайней мере мыслей у меня на этот счет больше нет.

я не знаю, как сделать в фильтре иерархию. Попробуйте в моем примере ее сделать и приложить.

mitox, смотрите так нужно?

mitox,  доброго вечера. Пишу с телефона, могу посоветовать следующее. В календаре создайте доп. столбец "порядковый номер месяца", в котором каждый месяц будет иметь уникальный номер, т.е. первый год это будут с 1 по 12, второй год с 13 по 24 и.т.д. Далее создаёте меру, которая высчитывает максимальный порядковый номер месяца с учётом налагаемых фильтров. После этого остаётся создать меру, в которой указываем диапазон от полученного результата предыдущей меры минус 12 месяцев.

Максим Зеленский, я неверно представил себе идею в голове. Попробовал сделать, и получается, что 3 составных ключа нужны на стороне таблицы данных, а это ненужная избыточность. Поэтому лучшего варианта, чем LOOKUPVALUE я придумать не смог!

можно в PQ сделать 3 составных ключа дополнительно и, соответственно, 4 связи в PP. То же самое будет, просто чуть проще на восприятие. А так да, это "топорное" решение!

................. что это?
По теме: плюс переменной в том, что она пересчитывается один раз. И если в вашей, извиняюсь, мере есть повторные вычисления, то да: целесообразно использовать переменные. Иначе ничего не изменится.

Пока пилил свое топорное решение на DAX, уже все сделали!
Сделал 4 раза ВПР (максимум возможных составных ключей в справочнике)

"Свод"

Андрей VG, все верно описал. Решение недоделанное, используйте связку MAXX(SUMMARIZE(...[какой-то результат]);[какой-то результат])

- так и делаете. Для подсчета строк используйте SUMMARIZE, а для вывода - MAXX.

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

Попробуйте такой вариант для вычисляемого столбца в календаре, должно сработать: