Ну вот так:

Реализовал с помощью List.Generate в PQ

Подключается! И всякий раз при обновлении будет повторно обрабатывать каждый pdf-файл. Решение - self referencing. Подробнее тут - https://t.me/pbi_pq_from_tank/106

Тогда так:

"if ... then ... else..." используйте или "try... otherwise... " в зависимости от задачи.
А чтобы подсказать другое решение, не плохо бы файл с примером приложить

С помощью Power Query  

Наверное, это как-то можно реализовать макросом. Я сделал с помощью Power Query. Обновляете и получаете результат.  

Реализовал с помощью Power Query

Сначала объединить всё в одну таблицу с помощью Power Query или вручную перетаскиванием - как умеете. Затем сделать сводную таблицу и строить диаграммы за нужные периоды. Я объединил с помощью Power Query

В PQ это делается быстро и легко обычным мышкоклацем  

А в чём у вас проблема с сайтом ЦБРФ?  

Локальная группировка с суммированием )))))

AlienSx, благодарю вас!  

AlienSx, это работает только в разрезе ПТиУ - Товар, а в разрезе ПТиУ - уже нет, к сожалению.

Коллеги, добрый день!

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

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

Подскажите, пожалуйста, как решить эту проблему?

Сразу скажу, что вытянуть наименования платежа в столбцы - не вариант: их в реальной задаче гораздо больше, к тому же они ещё дополнительно поделены по признаку: облагаются НДС/ не облагаются НДС.

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

Ну предложите свой. Мне что пришло первое в голову, то я и сделал.  

Коллеги, здравствуйте!

Получил в работу своеобразную базу с ценами на товары с 2011-го года. Самый быстрый способ её нормализации - через транспонирование с последующим анпивотом. Но у меня есть сомнения в плане лимита по количеству столбцов в Power Query. База будет обновляться, и не получится ли в какой-то момент так, что при транспонировании портянки с ценами превысится максимальный лимит на количество столбцов?  

У вас в чём сложность? В консолидации данных в плоскую таблицу?
Данные консолидировал - дальше считайте, что вам нужно.  

Коллеги, здравствуйте!

Помогите, пожалуйста, оптимизировать существующие запросы-подключения к сайтам ЦБ РФ, РБ и КЗ.

Имеется прайс по различным товарам за различные даты. Товары закупаются в России, Беларуси и Казахстане. Цены в прайсе приведены как в российских, так и в белорусских рублях, а также в тенге. Причём цены на товары, закупаемые в Беларуси могут быть указаны как в белорусских рублях, так и в российских. Тоже самое с ценами на товары, закупаемые в Казахстане. Причём сами товары могут закупаться как в национальной валюте, так и в рублях, так и в евро, долларах и юанях. Следовательно, если цены даны в российских рублях, а закупить товары нужно в Белоруссии причём в евро, требуется пересчёт курса евро в российские рубли, но по курсу ЦБ РБ российского рубля по отношению к белорусскому рублю.

Я все необходимые кросс-курсы сделал, к прайсу подтянул. Но ожидаемо всё очень долго подгружается. Я, где смог, добавил Table.Buffer, но не уверен в том, что в плане оптимизации и ускорения сделал всё, что было возможно. Прошу уважаемых знатоков Power Query помочь с оптимизацией.

Валюты тяну с 11-го года, так как статистика ведётся с этого года и для анализа требуются данные за прошлые годы.

В общем, можете считать меня въедливым занудой, я сформулировал для себя такое правило.

Если внешний фильтр шире гранулярности первого аргумента итерационной функции, то он влияет только на этот аргумент и не влияет на меру во втором аргументе.
Если же внешний фильтр Уже гранулярности первого аргумента, то он влияет и на первый аргумент функции и на меру во втором аргументе. А по сути  мера во втором аргументе будет рассчитана только в контексте внешнего фильтра в этом случае.

В случае с мерой:

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

В случае с мерой:

по срезу дня месяца года (например, 01.01.2007) действует 2-е правило. Внешний фильтр - день Уже гранулярности 1-го аргумента - месяца, значит он фильтрует и первый аргумент: VALUES('Date'[Month]) = "January" и второй аргумент - меру [Sales Amount], но по сути мера рассчитывается только по внешнему фильтру - 01.01.2007

Критика приветствуется.

Это понятно
Хотелось бы более содержательного объяснения

Тогда удаляйте дубли по всем столбцам таблицы кроме столбца [Марка и модель]
Ваша проблема решена?

Воспользуйтесь формулой

Только предварительно надо в столбце [Keyword] заменить ошибки на "пусто". Сделать это надо потому, что у вас в этом столбце присутствуют: #ИМЯ? - Power Query такое очень не любит.  

Ох! )))) Ну уж это я помню, как и то, что вообще любой фильтр в функциях CALCULATE(-TABLE) по какому-либо столбцу автоматически заворачивает условие фильтрации в функцию FILTER:А в случае с фильтрацией по 'Date'[Date] ещё и добавляет по умолчанию условие ALL('Date')
Только в примерах моих мер функция CALCULATE напрямую вообще не задействована и присутствует лишь как обязательное дополнение к мере [Sales Amount]Да вот взять хотя бы пример из видео Руссо. Там мера:рассчитывается в контексте внешнего фильтра - Product[Brand].
Таблицы Product и Customer напрямую не связаны, то есть первый аргумент - таблица Customer внешний контекст фильтра не примет, то есть вернёт всю таблицу Customer целиком.
А вот мера [Sales Amount] примет и внешний контекст фильтра - Product[Brand], и внутренний контекст фильтра - каждая строка таблицы Customer.
Понятно, что при итерациях по таблице Customer будут пустые строки:
 1) либо потому, что данный клиент совсем не совершал покупок;
 2) либо потому, что по данному клиенту покупки есть, но с дополнительным внешним фильтром по бренду - их нет.
Но функция AVERAGEX игнорит пустые значения, поэтому можно быть уверенным, что расчёт будет верным.

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

Возьмём первую меру в разрезе Года / месяца - например, января 2007-го. Повторю то, что писал выше
1-й аргумент VALUES('Date'[Date]) принимает внешний контекст фильтра - январь 2007-го
2-й аргумент мера [Sales Amount] принимает:
 1) внешний контекст фильтра - январь 2007-го;
 2) внутренний контекст фильтра - каждый день января 2007-го: с 1-го января по 31-е января
И вот тут попробуем наложить внешний контекст фильтра на внутренний
Мера  [Sales Amount] должна одновременно посчитаться по 1-му января и по всему месяцу январь - вот в точности, как в том примере у Руссо. Но это абсурд, поэтому рассчитывается она только по датам (датам января 2007-го, так как  VALUES('Date'[Date]) приняла на себя внешний фильтр по месяцу года). Вот именно это я и имею в виду под "внутренний фильтр перебивает внешний"

Но почему же тогда не абсурд, что во второй мере:в разрезе даты месяца года - 01.01.2007 мера [Sales Amount] принимает:
и внешний фильтр - дата 01.01.2007
и внутренний фильтр - месяц январь (так как внешний фильтр по дате 01.01.2007 отфильтровал первый аргумент VALUES('Date'[Month]) по месяцу "January")

Я вот этого до конца понять не могу. Почему в первой мере нельзя друг на друга наложить внешний и внутренний фильтр, а во второй - можно?
Почему, грубо говоря, в первой мере мы не можем посчитать  [Sales Amount]  одновременно по месяцу и дню, а во второй мере - можем?

Понимаете, что я не понимаю?

Огромное вам спасибо!

Я никак до конца не могу уяснить, в каких случаях на меру во втором аргументе итерационной функции действует только внутренний контекст фильтра таблицы в первом аргументе, а в каких ещё и внешний контекст фильтра.

Корни этого непонимания растут вот откуда.

Есть мера, рассчитывающая максимальные продажи в гранулярности дат:И есть мера, рассчитывающая максимальные продажи в гранулярности месяцев:Посмотрим, как работает мера "Max Sales Date" в разрезе Года / месяца - например, января 2007-го
1-й аргумент VALUES('Date'[Date]) принимает внешний контекст фильтра - январь 2007-го
2-й аргумент мера [Sales Amount] принимает:
  1) внешний контекст фильтра - январь 2007-го;
  2) внутренний контекст фильтра - каждый день января 2007-го: с 1-го января по 31-е января
Внутренний контекст фильтра перебивает внешний, так как нельзя же одновременно вычислить продажи по месяцу и по дню

Теперь как работает мера "Max Sales Month", но уже в разрезе Года / месяца / дня - например, 1-го января 2007-го года
1-ый аргумент VALUES('Date'[Month]) принимает внешний контекст фильтра - 01.01.2007.
Таким образом для 01.01.2007 - VALUES('Date'[Month]) = "January"
2-ой аргумент мера [Sales Amount] принимает:
 1) внешний контекст фильтра - 01.01.2007;
 2) внутренний контекст фильтра - месяц "January"
Тут как раз ситуация аналогична с моим первым примером про категории и подкатегории, то есть оба фильтра - и внешний и внутренний - накладываются на меру - январь и 01.01.2007, то есть мера рассчитывается по 01.01.2007

И вот тут я не до конца понимаю, почему в первом случае внутренний фильтр по датам перебивает внешний по месяцам, а во втором внутренний фильтр по месяцам НЕ перебивает внешний по датам.

Хотя логично всё звучит, но нету точного понимания, когда подобные временные фильтры перебивают один другой, а когда - дополняют друг друга. Если сможете мне это доходчиво объяснить - буду вам признателен!

Ссылка на файл с примером - https://disk.yandex.ru/d/Fydau1SkcikQwA

Коллеги, ни у кого нет версий?

Здравствуйте!

Прошу помощи в решении очередного вопроса по DAX.

Есть таблица Product, где содержится информации о товарах: названия, бренды, цвета, категории и подкатегории.

Создал простую меру:В разрезе категорий и подкатегорий мера отрабатывает верно: по категориям показывает кол-во входящих подкатегорий, по подкатегориям - единицы

Создал меру посложнее:Логика такая:
1) в разрезе категорий - аналогично предыдущей мере;
2) в разрезе подкатегорий - рассуждаю так:

На первый аргумент VALUES('Product'[Category]) влияет фильтр по подкатегории. Подкатегория фильтрует категорию, в которую она входит. Для "Bluetooth Headphones"  - это категория "Audio".

На второй аргумент  CALCULATE(DISTINCTCOUNT('Product'[Subcategory])) влияет внешний фильтр - подкатегория "Bluetooth Headphones" и внутренний фильтр - категория "Audio". Внутренний фильтр важнее внешнего, значит CALCULATE(DISTINCTCOUNT('Product'[Subcategory])) должен рассчитываться по категории  "Audio"

Таким образом по каждой подкатегории: "Bluetooth Headphones", "MP4&MP3" и т.д. значение меры должна быть 3, но выдаёт почему-то 1

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

Да, спасибо!

До меня дошло, наконец, что CALCULATE(SUM('Товары'[Прибыль]) примет ещё и внешний К.Ф., преобразованный из К.С., и помимо фильтра по столбцу "Товар" будет фильтроваться остальными столбцами: "Категория", "Прибыль" и т.д. Таким образом нужно ограничить внешний фильтр столбцом "Товар" и снять с остальных столбцов. Формула:отработала корректно

Здравствуйте, коллеги!

Для последующего ABC-анализа нужно посчитать накопительный итог по товарам.
Обычно создавал вычисляемый столбец с помощью функции FILTER:
Всё корректно считает.

Затем я попробовал ради эксперимента использовать вместо FILTER функцию CALCULATETABLE.
Опишу логику формулы.

CALCULATETABLE в отличие от FILTER инициирует преобразование К.С. в К.Ф., следовательно на выражение VALUES('Товары'[Товар]) действуют следующие внешние фильтры:
1. Значение в текущей строке по столбцу "Категория".
2. Значение в текущей строке по столбцу "Прибыль".

Второй и третий аргументы функции CALCULATETABLE задают внутренние фильтры:
1. Фильтровать только по столбцу "Прибыль", игнорить фильтры по остальным столбцам.
2. Весь столбец "Прибыль" (по умолчанию действует доп. условие - ALL( 'Товары'[Прибыль]) ) отфильтровать так, чтобы остались только те значения, что равны или превышают значение в текущей строке столбца "Прибыль".

Внутренний фильтр перебивает внешний, и в итоге остаются только те строки столбца 'Товары'[Товар], что удовлетворяют условиям 2-го и 3-го аргументов функции CALCULATETABLE

Далее в функции SUMX происходит преобразование К.С. в К.Ф. посредством функции CALCULATE, и значение SUM('Товары'[Прибыль]) рассчитывается по каждой строке отфильтрованного столбца VALUES('Товары'[Товар]), а затем все вычисленные значения прибыли суммируются.

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

Для того, чтобы убедиться в справедливости своей логики, я также создал вычисляемый столбец с накопительным итогом по товарам:
Как и ожидалось, в каждой строке идёт накопление товаров по изложенной выше логике.

Вопрос: почему же не считается накопительный итог?  

Как будет возможность, пришлите, пожалуйста, ваш файл.