Vessünk még egy pillantást a cikkben tárgyalt problémára, amely dinamikusan hasonlította össze minden hónap első N munkanapját. Ez a probléma egy LuckyTemplates-tag kérdésén alapult a fórumunkon, ahol dinamikusan meg akarta nézni és összehasonlítani az adott hónap első 5, 10, 15 és 20 számlázható napját (a nem hétvégéket és a nem ünnepnapokat) az adott hónaphoz képest. az előző hónapban.
A power query használata helyett egy DAX kódolási nyelvi megoldást dolgozunk ki. Az oktatóanyag teljes videóját a blog alján tekintheti meg.
Az első videóban egy power query megoldást találtam ki a probléma megoldására. Ekkor azonban az egyik LuckyTemplates szakértőnk, Antriksh Sharma egy zseniálisan hatékony intézkedéssel állt elő, amelybe szintén érdemes belemerülni. Megbeszélünk néhány technikát, amelyet egy intézkedés kidolgozásakor használt, amelyek további eszközöket biztosítanak a DAX eszköztárában.
Minden bizonnyal jót tett nekem és néhány más szakértőnek is, akik megvizsgálták ezt. Az összehasonlítható munkanapok hónapok közötti összehasonlítása általában véve értékes minta, amely számos helyzetben használható.
Merüljünk el a power query-ben, és nézzük meg, mit csinált itt Antriksh. Megvan a hónap és év , az összes értékesítés és végül az összes értékesítés N munkanapra vonatkozóan , amelyeket az általunk kifejlesztett mi lenne, ha paraméter alapján választottunk ki power lekérdezéssel.
Antriksh egészen más megközelítést alkalmazott, amikor egy megdöbbentően rövid intézkedést alkalmazott az egész probléma megoldására. Az első dolog, amit ezzel kapcsolatban észrevettem, a parancs használata volt.
Ez egy DAX funkció, amelyet nem nagyon használok, de tökéletesen illeszkedik az ilyen típusú problémákhoz. Ha megnézzük az SQL BI DAX útmutatót, akkor az azt mondja, hogy a GENERATE függvény egy táblafüggvény, amely két különböző táblát használ bemenetként, majd a CROSS APPLY SQL parancs megfelelőjét használja.
Tehát vesz egy alaptáblát (Table1), és azon iterál, majd vesz egy második táblakifejezést, és kiértékeli azt az első tábla minden sorához, majd visszatér a táblához kimenetként.
Vegyük fel Antriksh mértékét, és dobjuk be a táblázatba. Láthatjuk, hogy pontosan ugyanazt az eredményt adja, mint a power query megoldás, amit legutóbb. Tehát ez jó, és elég jól érvényesíti mindkét intézkedést.
Vegyük szét ezt a mértéket. Az itt alkalmazott első szűrő a Dátumok[IsBusinessDay] = TRUE. Ez kiveszi az összes nem hétvégi és nem ünnepi dátumot a kiterjesztett dátumtábla IsBusinessDay mezője alapján.
Sokat beszélünk erről a -ban, ahol azt is végigjártuk, hogyan kössük ezt az ünnepi asztalunkra.
Ennek érdekessége valóban a két táblázatbemenetben rejlik. Az első táblázat csak egy oszlopos táblázat a Dátum táblázat Hónap és év mezőjében.
De a második táblázatban az érdekes dolgok történnek. Antriksh a-t használt, majd a dinamikus paraméterünket használta a TOPN sorainak számaként.
A Teljes értékesítés mértéke a második táblázathoz van csatolva, majd az első táblára vonatkozik.
Tartalomjegyzék
Egy összetett intézkedés megértése a DAX kódolási nyelv használatával
Az egyik legegyszerűbb módja annak, hogy kitaláljuk, mit csinál egy ilyen összetett mérték, ha belép a Táblázatszerkesztőbe . Vessünk egy pillantást erre a kifejezésre, és kitaláljuk, mit csinál ez a TOPN kifejezés először.
Másoljuk a TOPN részt, és hozzunk létre egy újat. Ne feledje, hogy a DAX-lekérdezések EVALUATE karakterekkel kezdődnek.
Amikor beillesztjük a TOPN részt, látni fogjuk, hogy ez az első 5 dátumot veszi ki az értékesítési rendelések táblázatából. A TOPN-ban van egy táblázat, amely az értékesítési táblán belüli összes rendelési dátum értékét tartalmazza.
Ez a TOPN függvény veszi a mi lenne, ha paraméter értékét (amely ebben az esetben 5), és alkalmazza azt az értékesítési rendelés dátuma mezőben. Ezután a szűrőkontextuson belül az első 5 dátumot a mező alapján növekvő sorrendben lehívja.
Tekintettel arra, hogy nincs további szűrőkörnyezet, ez csak az első 5 dátumot veszi ki a teljes táblázatból.
A @Sales oszlop csak hozzáadja a teljes értékesítést a megfelelő szűrőkontextuson belül a TOPN táblához.
Eddig megvan a Hónap & Év első táblázata, az eladási táblázatból az első N dátum TOPN-jának második táblázata, majd az ehhez kapcsolódó összes eladás.
A GENERATE tábla használata DAX kódolási nyelven
Nézzük meg, mit csinál ez a GENERATE tábla. Visszaugrunk a Táblázatszerkesztőbe, és létrehozunk egy új DAX-lekérdezést.
Kezdjük, mint mindig az EVALUATE-nél, illesszük be a kód LÉTREHOZÁS részét, és kattintsunk az 5-re.
Láthatjuk, hogy az első tábla minden soránál iterál és csatlakozik a @Sales függvénnyel összefüggésben kiértékelt TOPN tábla 5 sorához.
Április első 5 munkanapja, május első 5 munkanapja, június első 5 munkanapja telt el, és így tovább, amíg az első táblázat végére nem ér.
Pontosan erre van szükségünk, és most már viszonylag egyszerűvé válik ezen értékek összeadása. Megvan az eredmény (ami a GENERATE eredmények táblázatváltozója), majd összegeznünk kell a @Sales függvényt.
A kontextuson belül most összegezzük az első 5 munkanapot áprilisban, az első 5 munkanapot májusban, és így tovább, amíg el nem érjük a teljes 23 737 430 USD-t, ebben az esetben nincs összefüggésben a működési hónap és év. .
Ez összegzi a teljes @Sales oszlopot, és pontosan ugyanazt az összeget kapja, mint a power query megoldásunkban.
Látható, hogy ha a szeletelőt 10-re állítjuk, dinamikusan ugyanazokat az eredményeket kapjuk a DAX kódolási nyelvvel, mint a power lekérdezésnél.
Az alján található oszlopdiagram is dinamikusan igazodik, hogy tükrözze az általunk végrehajtott változtatásokat.
Az intézkedés címének dinamikus beállítása
Van még egy további trükk, amit meg akartam mutatni. Létrehozhat egy dinamikus korrekciót a mi lenne, ha paraméterén, és dinamikusan kötheti egy mértékcímhez.
Például, ha a felül lévő szeletelőt 15-re változtatjuk, akkor dinamikusan módosítja az alul lévő mérőszám nevét Minden hónap első 15 munkanapján Összes értékesítésre .
Van egy egyszerű módja ennek a DAX-ban a használatával. Alapvetően csak három húrt veszünk. Az első a Total Sales for First , majd összefűzi azt az értékkel, amelyet a mi lenne, ha paraméterből gyűjtöttünk össze, majd csak köti a cím többi részéhez.
Ezután belépünk a vizualizációba, a cím feltételes formázásához, és kattintsunk az fx gombra .
A mezőérték alapján formázzuk, és kiválasztjuk azt a dinamikus címmértéket. Ez megváltoztatja a mi lenne, ha paraméter kiválasztását.
Következtetés
Jelenleg egy teljes megoldásunk van DAX kódolási nyelvet használva. Megbeszéltük ennek egy igazán kreatív és hatékony módját a GENERATE funkció használatával. Szeretném megköszönni Antriksh-nek, hogy megosztotta velünk ragyogó DAX tudását. Sokat tanultam a DAX megoldása során, és remélem, te is így tettél.
Ebből a blogból megtudhatja, hogyan mentheti automatikusan az e-mail mellékleteket a SharePointba, majd törölheti az e-maileket a Power Automate segítségével.
A Microsoft LuckyTemplates irányítópult 18 legjobb példája 2023
Ismerje meg, hogyan hozhat létre <strong>Power Automate</strong> folyamatokat a semmiből. Sablon használata helyett mi magunk hozzuk létre a kiváltó okokat és a műveleteket.
4 módszer a Pi használatára a Pythonban példákkal
Ebben az útmutatóban bemutatom, hogyan lehet Pénzügyi információk mátrixát létrehozni a Profit és veszteség (P&L) kimutatással a LuckyTemplates alkalmazásban.
Fedezze fel, hogyan lehet dinamikusan egyesíteni oszlopokat a Power Query Table.CombineColumns függvény segítségével.
Ismerje meg, hogyan adhatjuk hozzá és szinkronizálhatjuk SharePoint-fájljainkat az asztalon és a OneDrive-on.
Tudja meg, miért fontos egy dedikált dátumtáblázat a LuckyTemplatesben, és ismerje meg ennek leggyorsabb és leghatékonyabb módját.
Ez a rövid oktatóanyag kiemeli a LuckyTemplates mobil jelentési funkcióját. Megmutatom, hogyan készíthet hatékony jelentéseket mobileszközökön.
Ebben a LuckyTemplates bemutatóban olyan jelentéseket tekintünk át, amelyek professzionális szolgáltatáselemzést mutatnak be egy olyan cégtől, amely több szerződéssel és ügyfél-elkötelezettséggel rendelkezik.
