сумму специальным образом.
Есть плановая дата платежа от заказчика. Если сам платеж произведен), то курс брать на дату платежа (не важно, раньше или позже), если платежа не было, то курс брать на сегодня (для простоты, на последнюю дату в справочнике обменных курсов). Ключевое, привязка суммы к планируемой дате платежа должна остаться. То есть, если план был на скажем июнь, а платежа ещё нет, расчет курса должен быть на сегодня, но сумма все равно должна отображаться за июнь.
У меня загвоздка возникает в агрегировании. Для каждой строки расчет корректный. Проверил калькулятором.
В книге "Шаблоны..." Ничего подобного нет, а гугление показывает в основном USErelationship. Может, кто видел, как делать перепривязку? Хотелось бы понять, как правильно менять контекст, чтобы сохранить привязку к первой дате.
а не лучше подумать в сторону того, что на этапе загрузки данных в модель добавить столбец с пересчетом суммы платежа в нужной валюте на нужную дату в зависимости от ваших условий и затем на DAX уже просто SUM() использовать по этому полю. Зачем городить это на DAX не понимаю
Я всё же предположу, что SQL Запрос подобного рода со всеми crosstab ами или case выйдет минимум строк на 900. В даксе я пока уложился в 60
на SQL это решается легко.. вообще не вижу проблемы.
Количество строк SQL кода ни о чем не говорит. Надо смотреть какой получился итоговый план SQL запроса, а не ориентироваться на количество стро\чек
Пример подобного запроса киньте в личку, если делали. Я посмотрю алгоритмы.
я ведь только Вас хотел направить в нужную сторону, а не делать за Вас работу... если хотите, чтобы я сделал, то пишите в личку, договоримся
Чтобы меня направить в нужную сторону, мне нужно, чтобы мне показали, в каком месте у меня идёт сбой в агрегировании. потому что для каждой сделки отдельно расчёт корректный. Или подсказали, как правильно это посмотреть, потому что в Dax Studio я ничего не увидел. Кроме того, я просил не сделать за меня, а лишь предложить пример выполненного запроса. То есть копировать и вставить. Я бы почитал и посмотрел, как он идёт.
повторюсь. Не вижу смысла искать ошибку в представленной DAX мере, т.к. сам путь решения выбран не оптимальный.
А если у вас данные будут не SQLные вы что будете делать? NiFI или AirFlow искать? Отличный подход. Вместо того, чтобы пару строк исправить, найти спеца тысяч за 150, поставить базу (арендовать или купить сервер).
если нет базы под ногами, то решу на PQ
Это пример задачи, которую стоит решать на этапе загрузки данных или до. Сделайте в PQ или в вычисляемом столбце, если не получается в источнике.
Да, я понимаю, как заджойнить в PQ и через множество условий создать столбец курса, можно даже без валюты. А потом SUMX и вуаля. Но это же условие я стараюсь сделать Даксом. И я не понимаю, что там мешает это сделать.
Вот так и делайте. В DAX мешает сделать то, что Вы в мере пытаетесь реализовать логику, которую не нужно считать «на лету», с учетом фильтров и т.д. Не нужно пытаться закрутить гвоздь отверткой
Некий товарищ выше сказал, что делается это быстрее, чем вопрос написать. Всё вот хочу посмотреть, насколько эти слова смысл имеют. Я чего-то не понимаю, или просто можно не ворочая мешки людям отвечать
Он прав. Меру можно написать быстро и проще. Пришлю пример, если найду время. Но проблема в том, что меры считаются в момент рендера визуального элемента и это значит, что даже с учетом кэширования, на больших объемах все будет сильно тормозить.
Буду благодарен. С некоторым опытом, я уже знаю, что то, что я упускаю сейчас всплывёт рано или поздно. Поэтому мне очень не хочется ещё раз тупить с подобной задачей.
Вы будете тупить пока не разберетесь с работой контекстов фильтра/строки.
Так уж устроено, что на конкретном примере проще понимать, что упускаешь, чем на сферических конях в вакууме.
Обсуждают сегодня