SShakeno0220 написал: "DataFormat.Error: Не удалось выполнить синтаксический анализ входных данных, предоставленных в качестве значения даты. Сведения: 1999.2.30"
а у февраля есть 30 число? Почему просто не сделать Date.AddMonths([Дата приема], 3)? Да, 28.10.1998, 29.10.1998 и 30.10.1998 будут 28.02.1999
Если уж хотите по-вашему, то
Код
#"Добавлен пользовательский объект" = Table.AddColumn (
#"Измененный тип",
"Пользовательский",
each [ new_date = Date.AddMonths ( [Дата приема], 3 ), result = Date.AddDays ( new_date, Date.Day ( [Дата приема] ) - Date.Day ( new_date ) ) ][
result
],
type date
)
Но смотрите, что дает Ваша формула (и последний эквивалентный код в PQ): для более поздней даты истечение срока раньше
P.S. Вообще, поэтому сроки обычно задаются в днях, а не месяцах.
ponrussell, 1. А нафига Вы данные на лист грузите? Загрузите только в модель. 2. А нафига Вы данные храните в файлах excel? Выгружайте в csv. Там нет ограничения строк + чтение из csv гораздо быстрее.
mechanix 85, иногда для краткости лучше предикаты использовать И для вычисления "за текущий год" изменение контекста излишне: просто CALCULATE ( [кол-во] ) вместо CALCULATE([кол-во];FILTER(ALL( 'Таблица1'[Год]);'Таблица1'[Год]=MAX('Таблица1'[Год])))
Я бы с помощью переменных попонятнее делал. А то длинно читать это все:
Код
av:=
AVERAGEX (
VALUES ( 'Таблица1'[Год] );
VAR PY = 'Таблица1'[Год] - 1
VAR valueCY =
CALCULATE ( [кол-во] )
VAR valuePY =
CALCULATE ( [кол-во]; 'Таблица1'[Год] = PY )
VAR result =
DIVIDE ( valueCY; valuePY )
RETURN
result
)
В случае CALCULATE ( [кол-во] ) CALCULATE излишний, так как [кол-во] - мера и неявно оборачивается в CALCULATE. Но лишний раз напомнить о преобразовании контекста строки в контекст фильтра - стоит
Golubev.aa, а Вам никто не ответит. А если ответит, то это будет ложь 1. Лучше выгружать данные в модель данных (движок их там сохранит с заниманием меньшего объема памяти). Так же в этом случае Вы получаете огромный функционал Power Pivot с написанием сложных мер. 2. Ваш запрос грузится очень долго. И проблему просто так не понять. Это может быть и долгое получение большого объема данных с какого-то ресурса, и (более вероятно) Ваш неоптимальный код, и другие причины. Скорее всего, Вы делаете какие-то расчеты в PQ не оптимально и/или их вообще не нужно там делать, а реализовать в PP.
P.S. Не нужно нас заставлять гадать по картинкам. Сделайте пример данных + файл с Вашим запросом из этого примера.
В Power Query при отмене свертывания столбцов исчезли строки с нулевыми значениями, В Power Query при отмене свертывания столбцов исчезли строки с нулевыми значениями
AlienSx написал: придать им действительно нулевое значение.
Ну это же не по-нашему Ведь замена null (которое ТС называет "нулевым") на 0 будет совсем не эквивалентна для дальнейшей аналитики Можно просто погуглить:
Код
/**
* Unpivots columns (or optional other columns) while keeping empty fields (with
* null). Any entry to the 3rd parameter will set to 'Unpivot Other Columns'
* instead.
*
* @categories table, pivot
* @author https://github.com/ImkeF
* @source https://github.com/ImkeF/M
* @license MIT (c) 2017 Imke Feldmann
* @version 2021-02-09-1
*/
let
func = (Table_ as table, Columns as list, optional Others as any) =>
let
NonSelectedColumns = List.Difference(Table.ColumnNames(Table_), Columns),
Unpivot = if Others <> null then NonSelectedColumns else Columns,
AddColumn = Table.AddColumn(
Table_,
"Custom",
each Record.ToTable(Record.SelectFields(_, Unpivot))
),
Cleanup = Table.RemoveColumns(AddColumn, Unpivot),
Expand = Table.ExpandTableColumn(Cleanup, "Custom", {"Name", "Value"}, {"Name", "Value"})
in
Expand,
documentation = [
Documentation.Name = " Table.UnpivotKeepNulls#(cr,lf)",
Documentation.Description
= " Unpivots columns (or optional other columns) while keeping empty fields (with null). #(cr,lf)",
Documentation.LongDescription
= " Unpivots columns (or optional other columns) while keeping empty fields (with null). Any entry to the 3rd parameter will set to ""Unpivot Other Columns"" instead. #(cr,lf)",
Documentation.Category = " Table Transformation#(cr,lf)",
Documentation.Source = " local#(cr,lf)",
Documentation.Author = " Imke Feldmann: www.TheBIccountant.com .#(cr,lf)",
Documentation.Examples = {[Description = " #(cr,lf)", Code = " #(cr,lf) ", Result = " #(cr,lf)"]}
]
in
Value.ReplaceType(func, Value.ReplaceMetadata(Value.Type(func), documentation))
excelboy1 написал: Необходимо чтобы функция автоматически выбрала необходимое значение для цены продажи товара (ЗЕЛЕНОЕ ВЫДЕЛЕНИЕ), условием истиности является % от закупки - 15% (голубые ячейки). Или процент от продажи 15% (желтые ячейки)
Так от чего именно нужен расчет? Вы руками будете вводить либо % от закупки, а % от продажи будет вычисляться по формуле (учитывая рассчитанную цену товара), либо наоборот.
* Если еще актуально - могу сделать любой из вариантов. В ЛС отправил стоимость.
Цитата
tolikt написал: при данной постановке задачи она не решаема из-за циклических ссылок.
Не совсем так. Во-первых, можно в VBA/PQ просто перебрать цены и вернуть максимально соответствующую условию. Ну или чуть громоздкой, но формулой
dim678 написал: в таблице перестало считать другие параметры
Вам бы эту книжку почитать... Хотя, желательно перед этим DAX изучить, но все же. В таблице Вы выводите измерения из одной из таблиц фактов, а нужно из справочника. Направление стрелочки на связях показывает направление фильтра. То есть таблица фактов никак не фильтрует справочники, которые, в свою очередь, фильтруют остальные таблицы фактов, поэтому Вы видите ожидаемое значение только у мер, которые используют данные этой таблицы фактов, а у остальных мер тупо вся сумма. В визуалы выносите измерения ТОЛЬКО из справочников. Для удобства и избегания ошибок даже сделайте соответствующие столбцы в таблицах фактов скрытыми.
dim678, Во-первых, исправьте свой ник (уберите оттуда цифры). Во-вторых, а если нормальную модель создать? * Для Тип операции тоже создайте отдельный справочник.
НЕ используйте связь N:N до того момента, как Вы начнете понимать ее работу.
Сергей написал: Цель -- сделать по таблице в PQ сводную
PQ не для создания сводной... А как раз для получения плоской таблицы, из которой уже строить сводную.
Цитата
Сергей написал: А исходно конечно талбичка составляется в экселе и пустые ячейки (например перерыв в финансировании или погашении и при оокнчании ) не отражаются в PQ при отмене свертывания и посему нарастающий итог в сводной и при составлении графика по ней уходит в бесконечность
Этот поток сознания я вообще не понял... Нафига Вам в плоском виде строки с null? Каким образом нарастающий итог в сводной уходит в бесконечность?
* AlienSx, не хочу весь бред читать 1. ТС подойдет замена "n квартал yyyy" на дату "01.n*3.yyyy". Ну и календарь добавить со столбцами кварталов/годов-кварталов и тд в нужном формате. 2. ТС мало что понимает не только в M/DAX, а просто в том, как должны выглядеть данные (модель данных) для аналитики в BI. Можно сделать платно под ключ. Или ТС сам хоть как-то изучит тему. Иначе это бесконечные вопросы не по задаче, а по видению ТС решения задачи (скорее всего, неправильному видению)
Otabek228 написал: ЛИФО же наооборот то есть Last in firs out.
Тут чуть-чуть логики нужно. Продаете Вы товар по FIFO (первым пришел, первым ушел). И его стоимость нужно вычислять по FIFO. Но Вы же вычисляете стоимость остатков. Можно "по-тупому": вычислить общую стоимость, стоимость проданного и найти разницу. А можно схитрить. Подмените понятия: "остатки" - реально проданное, "проданное" - реальные остатки. Теперь у Вас "проданное" "продается" по LIFO. Так что бочку на AlienSx не катите!
Да у Вас есть коды Уфы. Но они УФА UFA УВУУ. Нет кода UWUU (это транслит последнего кода; почти транслитерация, так как В в W преобразуем). Можно тоже это сделать в запросе (чтобы UWUU автоматом добавился как транслитерация УВУУ, если есть правила транслитерации. Ну и аналогично для всех кодов кириллицей).
*Что-то мне кажется, что это тестовое задание Если совсем нет своих идей, то, может, и не стоит устраиваться?
Оплата поставщикам в определённое число каждый месяц! (месяца текущие), Предварительная подсветка за два дня, за день и в день оплаты на одну дату но разные месяцы.
ser-jo написал: Наверное версия excel не позволяет такое сделать
Наверное, Вы не прочитали правила форума, раз не приложили пример данных и результата. И из Вашего первого сообщения я при беглом прочтении ничего не понял. Если не понял - пройду мимо Скорее всего, так поступит большинство пользователей.
Например,
Цитата
ser-jo написал: статический только день ... и дни разные
не находите в этом предложении противоречие?
Даже третий раз прочитав, я не понимаю, что Вам нужно. Заполнены даты, при дальнейших открытиях файла даты, в зависимости от текущей даты, должны сами поменяться на новый месяц? Или Вам нужно из одной начальной даты составить список платежных дней на весь период договора? Короче, нужен пример.
Странный вопрос. Еще раз: у Вас в данных может быть много столбцов с данными о продажах: сумма, количество, себестоимость, вес, объем и тд. В моделе данных PP эти данные продаж должны быть в разных столбцах. НЕ НУЖНО из 5 столбцов делать 2 (показатель/значение). Это негативно скажется как на занимаемом объеме, так и на производительности вычислений. Более того, придется писать более сложные меры.
Для Вашего примера никаких преобразований в PQ не требуется. Это данные в нужном виде. Я только загрузил через PQ, указав там тип данных для столбцов.
0033s написал: По заданию "Вес" и "Сумма", а в реале - "стредне-списочный состав" и куча KPI , должны находиться в одном столбце.
В данных подобные значения должны быть в разных столбцах. Если Вы о конечном виде в сводной таблице - то это уж как пожелаете (у меня на скрине вес и сумма в "одном столбце", хотя в данных они в разных столбцах).
Прошу прощения у всех, кто смотрел решение в предыдущем моем ответе Изначально я слишком все усложнил. Изменил на оптимальный вариант.
Vladimir Ch, думаю, Вам зайдет краткость решения по новым вводным от Юлии. И такая наценка мне кажется уже нормальным показателем, в отличие от начального
Alex, совершил такую же ошибку сам, так как в голове было предыдущее решение (вычисляли какую-то дичь сложным способом). Не нужны вообще условия, на каком уровне происходит вычисление (наименования/бренда/итогов). Все довольно тривиально:
P.S. Как обычно, моя жопа чуйка подсказала, что в изначальном условии ТС есть некорректные вычисления, противоречащие здравому смыслу. Всегда стоит изначально разработать нормальную математическую модель, а потом уже пытаться ее перенести в отчет.
Sviman144, не умею в PQ преобразовывать графические файлы Где пример данных? Где попытки реализовать? Почему нужно делать в PQ, а не преобразовать в PQ, а вычислять в PP?
Юлия, как бы существенное изменение. И теперь я считаю такой расчет корректным, а не хренью, как было Ваша задача вообще на платную тянет...
По сути тут уже не нужно будет всего гемороя (первые 3 меры, скорее, для уменьшения кода; и чтобы их отдельно выводить). Ну и мера наценки довольно простая + она уже будет работать с брендами, у которых только один товар, корректно.
0033s, можно так сделать. Если убрать измерение товара из сводной, то не будет "+" для разворачивания, как на примере результата. Но!!! Можно это реализовать (будет доп таблица с наименованиями мер), но нафига? При сворачивании категории что должно выводиться (сумма продаж или средний вес)?
Можно сделать и анпивотом, как Вы что-то пытались. Тогда не будет нужна доп таблица с названием мер. Но такое решение неверное с точки зрения оптимальности, плюс такая структура данных ведет к усложнению кода мер, что плохо скажется на поддержке. Короче, данные по весу и сумме должны быть в разных столбцах
Возможно, кто-то Вам поможет. Если захотите моей помощи, то в данном случае считаю задачу платной - можете попросить модераторов перенести в платный раздел. По стоимости будет 1800 (стоимость 1 часа), заказы менее 1800 не беру.
0033s, не понял. Данные подготавливаются в PQ. Ок. Именно подготавливаются, не рассчитываются.
Цитата
0033s написал: Проблема, на мой взгляд, состоит в том, что если период выбирается слайсером, то не понятно, как ему дать понять, на какое число надо разделить общий "Вес", чтобы получить средне-месячное значение.
А зачем среднемесячное значение вычислять в PQ? Он для подготовки данных. Сделайте это в Power Pivot. И отчет в PP уже отлично будет реагировать на срезы. И создается элементарно.
Хватит микроскопом гвозди заколачивать А потом еще и жаловаться, что не очень удобно.
Vladimir Ch, по факту Вы итератором SUMX создаете эквивалент вычисляемого столбца. Только он несколько раз создается, оптимальнее создать вычисляемый столбец. Только мерой (при наличии столбца с номером строки) тоже можно. Даже почти Вашим выражением Хоть и медленнее, чем вычисляемым столбцом.