DAX: 12 pułapek w miernikach z walutami (kurs dzienny vs miesięczny vs transakcyjny)

1. Wprowadzenie: dlaczego przeliczenia walut w DAX są podstępne

Przeliczanie walut w DAX wygląda na prostą operację: „kwota razy kurs”. W praktyce to jeden z najbardziej zdradliwych obszarów modelu, bo poprawność wyniku zależy nie tylko od samej formuły, ale przede wszystkim od tego na jakiej ziarnistości liczysz, w jakim kontekście filtra działa miara oraz jak poprowadzone są relacje między faktami, kalendarzem i tabelą kursów. Te trzy elementy potrafią dać wyniki pozornie wiarygodne, ale systematycznie błędne.

W raportach najczęściej spotkasz trzy logiki kursu: dzienny (np. kurs na datę), miesięczny (np. średni lub kurs z końca miesiąca) oraz transakcyjny (kurs „z dokumentu” albo z konkretnego zdarzenia). Każda z nich ma sens biznesowy, ale każda wymaga innego podejścia w modelu i w DAX. Problem zaczyna się wtedy, gdy w jednym widoku lub jednej miarze nieświadomie mieszasz te założenia.

Ziarnistość: kiedy „średni kurs” nie jest średnim kursem

Najczęstsza pułapka wynika z tego, że kwoty i kursy żyją na różnych poziomach szczegółowości. Sprzedaż bywa na poziomie wiersza transakcji, kurs może być dzienny, miesięczny albo przypisany do dokumentu. Jeśli zagregujesz kwoty i kursy niezależnie, a dopiero potem je połączysz, uzyskasz inny wynik niż przy przeliczeniu „wiersz po wierszu” i dopiero potem zsumowaniu. Różnica bywa niewielka na pojedynczym dniu, ale rośnie na poziomie miesiąca, kwartału czy całej spółki.

Ziarnistość jest podstępna, bo DAX często „pomaga” zwracając jakąś wartość nawet wtedy, gdy w kontekście jest ich wiele. To sprawia, że miara działa, ale niekoniecznie zgodnie z intencją.

Kontekst filtra: ten sam miernik, różne wyniki w zależności od wizualizacji

W DAX wynik miary zależy od kontekstu: filtrów z osi wykresu, segmentów, filtrów strony, a także od tego, czy kalkulacja wykonywana jest dla pojedynczej daty, miesiąca, waluty, spółki albo kombinacji tych wymiarów. W przeliczeniach walut szczególnie łatwo o sytuację, w której:

• miara jest poprawna na poziomie dnia, ale rozjeżdża się na poziomie miesiąca,
• działa dla jednej waluty, ale daje przypadkowy wynik przy wielu walutach jednocześnie,
• zmienia się po dodaniu kolumny do tabeli lub po przejściu na inną stronę raportu.

To nie jest „magia Power BI”, tylko konsekwencja tego, że kurs musi zostać jednoznacznie wybrany dla aktualnego kontekstu. Jeśli kontekst dopuszcza wiele kursów (np. wiele dni w miesiącu), DAX musi wiedzieć, czy ma wziąć średnią, ostatni dostępny, kurs z daty transakcji, czy coś jeszcze.

Relacje: gdy model danych decyduje za Ciebie

W przeliczeniach walut relacje są kluczowe, bo to one determinują, jak filtry przepływają między tabelami. Typowe modele mają co najmniej trzy osie, które muszą się „spotkać” w jednym miejscu:

• czas (kalendarz i daty),
• waluta (np. waluta dokumentu lub waluta raportowa),
• kursy (tabela kursów o określonej ziarnistości).

Jeśli relacje są niejednoznaczne, mają zły kierunek filtrowania, albo istnieje więcej niż jedna sensowna ścieżka łączenia (np. kilka dat w faktach: data dokumentu, data księgowania, data płatności), model może zwracać wyniki, które wyglądają „logicznie”, ale pochodzą z niewłaściwej ścieżki filtrowania. W walutach skutkuje to najczęściej kursem z innej daty, innej waluty lub innym typem kursu niż zamierzony.

Dlaczego to „podstępne”, a nie tylko „trudne”

Waluty są podstępne, bo błędy rzadko dają spektakularnie złe liczby. Częściej są to odchylenia procentowe, które mieszczą się w intuicji odbiorcy, zwłaszcza gdy w raporcie są zaokrąglenia, uśrednienia lub duże agregacje. Dodatkowo jeden miernik może przechodzić testy na próbkach danych, a psuć się w pełnym raporcie, gdzie dochodzą inne filtry, inne poziomy szczegółowości i inne kombinacje wymiarów.

Dlatego w przeliczeniach walut w DAX nie wystarczy „napisać miarę”. Trzeba zrozumieć, jaki kurs ma obowiązywać w jakiej sytuacji, oraz zapewnić, aby model i kontekst filtra prowadziły do tego samego wyboru kursu zawsze i wszędzie.

2. Fundamenty modelu danych dla walut: tabele faktów, tabela kursów, kalendarz, klucze dat, relacje i kierunki filtrowania

Poprawne przeliczenia walut w Power BI zaczynają się nie od DAX-a, tylko od modelu danych. Jeśli model nie rozróżnia jasno jakiej waluty dotyczy kwota, jakiego typu daty dotyczy kurs oraz na jakiej ziarnistości przechowywane są kursy, miary będą „czasem działać” i równie często dawać pozornie wiarygodne, ale błędne wyniki.

Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj. W praktyce w modelu walutowym zawsze trzeba świadomie zaprojektować trzy obszary: fakty (transakcje), wymiary czasu oraz wymiary kursów. Ich relacje i kierunki filtrowania determinują, czy DAX w ogóle ma szansę poprawnie dobrać kurs do kontekstu raportu.

Tabele faktów: gdzie „mieszka” kwota i waluta

Tabela faktów powinna jednoznacznie przechowywać:

• Kwotę źródłową (w walucie dokumentu/transakcji) – bez wcześniejszego przeliczania „na sztywno”, o ile nie jest to świadoma decyzja biznesowa.
• Kod waluty transakcji (np. ISO) jako klucz do wymiaru walut.
• Datę transakcji jako klucz do kalendarza (zwykle w formie klucza daty, nie tekstu).
• Opcjonalnie: dodatkowe daty (data księgowania, data rozliczenia, data dostawy). Każda z nich ma inny sens dla doboru kursu.

Kluczowe jest rozdzielenie pojęć: data, według której agregujesz sprzedaż nie zawsze jest tą samą datą, według której chcesz dobrać kurs. Model musi to umożliwiać, zamiast wymuszać jedną „datę uniwersalną”.

Tabela kursów: pojedyncza prawda o ziarnistości i typie kursu

Tabela kursów powinna być zaprojektowana tak, by dało się z niej jednoznacznie odczytać kurs dla danego kontekstu. Minimalny zestaw informacji obejmuje:

• Datę obowiązywania kursu – na tej dacie opiera się wiązanie z kalendarzem.
• Walutę „z” i walutę „do” (lub walutę oraz walutę bazową, zależnie od konwencji).
• Typ kursu (np. dzienny, miesięczny, transakcyjny/księgowy) jeśli w modelu współistnieją różne reżimy wyceny.
• Wartość kursu wraz z jasną definicją: czy jest to liczba jednostek waluty bazowej za 1 jednostkę waluty obcej, czy odwrotnie.

Najważniejsza decyzja projektowa brzmi: jaka jest ziarnistość kursów (dzień, miesiąc, inny okres) i czy kurs jest ciągły (dla każdego dnia) czy może występować tylko w wybranych dniach. Ta decyzja wpływa na relacje, a później na logikę miar.

Kalendarz: jedno źródło czasu i kontrola kontekstu

W modelu powinien istnieć jeden, spójny wymiar dat (kalendarz), który:

• jest używany do filtrowania faktów i kursów,
• zawiera atrybuty okresów (rok, miesiąc, kwartał) potrzebne do raportowania,
• reprezentuje ten sam „czas biznesowy”, w którym interpretujesz transakcje i kursy.

Nawet jeśli kursy są miesięczne, nadal warto trzymać kalendarz dzienny i kontrolować, jak mapujesz miesiąc na datę. Dzięki temu unikasz sytuacji, w której miary przypadkiem działają dla jednego widoku (np. miesięcznego), a psują się przy zejściu na dzień.

Klucze dat: dlaczego typ i spójność mają znaczenie

Relacje w Power BI są wrażliwe na jakość kluczy. Dla walut szczególnie ważne jest, aby:

• klucze dat w faktach i kursach były w tym samym typie (data vs tekst vs liczba),
• unikać „daty z czasem” w faktach, jeśli kursy są przechowywane jako data bez czasu (albo konsekwentnie normalizować),
• mieć jasną politykę strefy czasowej i momentu „przypisania do dnia” (biznesowo: kiedy transakcja ma datę dla kursu).

Te detale często wychodzą dopiero w testach: różnica jednego dnia lub przesunięcie czasu potrafi zmienić dobrany kurs, mimo że wizualnie wszystko wygląda poprawnie.

Relacje: jak połączyć fakty, waluty, daty i kursy

Najbezpieczniejszym podejściem jest model w stylu gwiazdy, w którym:

• fakt sprzedaży/zakupu łączy się z wymiarem walut (po kodzie waluty transakcji),
• fakt łączy się z kalendarzem (po dacie transakcji lub po dacie księgowania),
• tabela kursów łączy się z kalendarzem (po dacie kursu),
• tabela kursów łączy się z wymiarem walut (po walucie „z”/„do” lub po walucie i bazie).

Ważne jest rozróżnienie relacji, które mają wspierać filtrowanie raportu, od relacji, które mają wspierać dobór kursu. Te cele bywają sprzeczne, zwłaszcza gdy w grę wchodzi więcej niż jedna data w faktach oraz więcej niż jedna definicja kursu.

Kierunki filtrowania: mniej „dwukierunkowo”, więcej kontroli

W modelach walutowych nadmiar dwukierunkowych relacji jest częstym źródłem niejednoznaczności i błędów. Zwykle:

• wymiary (kalendarz, waluty) powinny filtrować fakty w jednym kierunku,
• tabela kursów powinna być traktowana jak tabela pomocnicza do wyceny, a nie jak kolejna „faktowa”, która ma propagować filtry w obie strony,
• jeśli potrzebujesz alternatywnych ścieżek filtrowania (np. inna data dla kursu), lepiej mieć to jako świadomą konstrukcję modelu niż „ratować” sytuację relacjami dwukierunkowymi.

Dobry model walutowy minimalizuje liczbę dróg, którymi filtr może dojść do kursów. Im mniej możliwych ścieżek, tym mniejsze ryzyko, że kontekst filtra wybierze „nie ten” kurs lub wytworzy konflikt.

Waluta bazowa i waluta raportu: gdzie to umieścić w modelu

Jeśli raport ma wspierać przeliczenia do jednej lub wielu walut prezentacji, model powinien przewidywać miejsce na:

• walutę bazową (stała lub zależna od jednostki organizacyjnej),
• walutę raportu (wybieraną przez użytkownika lub wynikającą z kontekstu),
• mapowanie między walutą transakcji a walutą prezentacji przez kursy.

To nie jest jeszcze kwestia konkretnej miary, tylko fundament: czy model potrafi jednoznacznie określić parę walut oraz datę, dla której szukasz kursu.

Praktyczna zasada projektowa

Jeśli nie potrafisz odpowiedzieć na pytania: „Jaka data steruje kursem?”, „Jaka jest ziarnistość kursu?”, „Która waluta jest źródłowa i docelowa?” wyłącznie na podstawie struktury modelu i relacji, to DAX będzie zmuszony „zgadywać” na podstawie kontekstu filtra. A zgadywanie w przeliczeniach walut zwykle kończy się jedną z klasycznych pułapek.

Sekcja 3 – Pułapki 1–4: kurs dzienny vs miesięczny

Przeliczenia walut w DAX potrafią „psuć się” nie dlatego, że kurs jest zły, ale dlatego, że ziarnistość kursu (dzień vs miesiąc) nie pasuje do ziarnistości danych (transakcja/dzień/miesiąc) i do kontekstu filtra w wizualizacji. Poniżej cztery typowe pułapki, które pojawiają się, gdy próbujesz mieszać kurs dzienny i miesięczny w tych samych miernikach.

Pułapka 1: mieszanie ziarnistości (dzień vs miesiąc) w jednym mierniku

Najczęstszy scenariusz: masz sprzedaż z datą transakcji (dzień), ale na wykresie oglądasz ją w ujęciu miesięcznym. Jeśli miernik „widzi” tylko miesiąc w filtrze (np. oś to Rok-Miesiąc), łatwo niechcący zastosować logikę, która wybierze jeden kurs dla całego miesiąca zamiast kursu per dzień/per transakcję.

• Objaw: wyniki są poprawne na poziomie dnia, ale „rozjeżdżają się” po agregacji do miesiąca.
• Dlaczego: kontekst filtra nie zawiera konkretnej daty; DAX próbuje sprowadzić kurs do jednej wartości (np. przez MAX/MIN/SELECTEDVALUE), co jest semantycznie błędne.
• Konsekwencja: niepoprawne przeliczenia, zwłaszcza gdy kurs zmienia się w miesiącu.

W praktyce to nie jest „problem kursu dziennego” ani „problem kursu miesięcznego” — to problem niedopasowania ziarnistości w obliczeniu. Dzienny kurs wymaga logiki iterującej po dniach lub transakcjach; miesięczny kurs wymaga logicznego przypisania miesiąca (np. przez klucz miesiąca).

Pułapka 2: błędne agregacje kursu (SUM/AVG/MAX zamiast właściwego ważenia)

Kurs walutowy sam w sobie zwykle nie jest miarą addytywną. A mimo to w miernikach często pojawiają się agregacje typu SUM( Kurs[Rate] ) albo AVERAGE( Kurs[Rate] ), które „jakoś działają”, ale nie odpowiadają żadnej poprawnej interpretacji biznesowej w kontekście przeliczeń wartości.

• Błąd 2.1: uśrednianie kursu dziennego, a potem mnożenie przez sumę sprzedaży miesięcznej. To daje miesięczną sprzedaż * średni kurs, co rzadko jest tym samym co suma dziennych przeliczeń.
• Błąd 2.2: branie MAX/MIN kursu w miesiącu „żeby wybrać jeden”. Wynik jest deterministyczny, ale arbitralny.
• Błąd 2.3: sumowanie kursów po dniach (SUM) — to praktycznie zawsze bez sensu analitycznego.

Jeżeli w raporcie poruszasz się między poziomami agregacji (dzień → miesiąc → kwartał), to błędne agregacje kursu potrafią wyglądać „OK” na jednym poziomie i dramatycznie źle na innym. To typowa pułapka, bo DAX nie zgłosi błędu — zwróci liczbę.

Pułapka 3: SELECTEDVALUE jako „wybór kursu” (i ukryty BLANK)

SELECTEDVALUE jest wygodne do odczytu pojedynczej wartości z kontekstu, ale przy kursach bardzo łatwo użyć go w sytuacji, gdy po wyborze miesiąca istnieje wiele dni, a więc i wiele kursów.

• Objaw: miernik nagle zwraca BLANK() dla miesięcy, mimo że dane są.
• Dlaczego: SELECTEDVALUE(Kurs[Rate]) zwraca wartość tylko wtedy, gdy w kontekście jest dokładnie jeden kurs; w innym przypadku zwraca BLANK (lub wartość domyślną, jeśli ją podasz).
• Skutek uboczny: użytkownik widzi puste pola albo — jeszcze gorzej — „domyślny kurs” użyty w wielu-kontekście maskuje błąd logiczny.

Minimalny przykład wzorca, który bywa podstępny:

-- Antywzorzec: działa na poziomie dnia, psuje się na poziomie miesiąca
[Kwota w walucie raportu] =
SUM ( Fakt[Kwota] ) * SELECTEDVALUE ( Kurs[Rate] )

Problemem nie jest samo SELECTEDVALUE, tylko założenie, że kurs jest unikalny w bieżącym kontekście. W ujęciu miesięcznym zwykle nie jest.

Pułapka 4: niejednoznaczne relacje i „magiczne” propagowanie filtra (Daily vs Monthly Rate)

Gdy w modelu są jednocześnie kursy dzienne i miesięczne, łatwo doprowadzić do sytuacji, w której filtr z kalendarza lub z tabeli faktów nie wiadomo którą ścieżką dochodzi do tabel kursów. Wtedy miernik może działać inaczej w zależności od użytego pola na osi (dzień vs miesiąc) albo od tego, czy filtr pochodzi z kalendarza, czy bezpośrednio z faktu.

• Objaw: ten sam miernik zwraca różne wyniki dla pozornie tego samego zakresu dat, zależnie od wizualizacji.
• Objaw: błędy typu „nie można ustalić pojedynczej wartości” lub nieoczekiwane dublowanie (gdy relacja nie jest 1:* po właściwym kluczu).
• Źródła problemu:
  • dwie relacje z kalendarza: do kursów dziennych po dacie oraz do kursów miesięcznych po dacie (wymuszające sztuczne dopasowanie),
  • relacje o złym kierunku filtrowania (np. obustronne),
  • łączenie tabel kursów do faktu po dacie bez rozróżnienia „data transakcji” vs „miesiąc raportowania”.

Kluczowa intuicja: w obecności dwóch tabel kursów (dziennej i miesięcznej) model może stać się logicznie niejednoznaczny nawet wtedy, gdy technicznie relacje „da się utworzyć”. DAX będzie wtedy mocno zależny od kontekstu filtra i od tego, które kolumny są w użyciu w raporcie.

Pułapki 5–8: kurs transakcyjny i wielowalutowość raportowania

Gdy w grę wchodzi kurs transakcyjny (przypisany do konkretnego dokumentu/pozycji) oraz jednocześnie potrzeba raportowania w wielu walutach, miary DAX łatwo zaczynają „udawać, że wszystko jest spójne”, podczas gdy w rzeczywistości mieszają różne znaczenia waluty i kursu. Najczęściej problem wynika z pomylenia trzech pojęć: waluta dokumentu, waluta bazowa (księgowa/korporacyjna) oraz waluta raportu (wybierana przez użytkownika). Zespół trenerski Cognity zauważa, że właśnie ten aspekt sprawia uczestnikom najwięcej trudności — bo na wykresach wszystko „wygląda dobrze”, dopóki nie porówna się wyników z księgą lub nie zejdzie do poziomu transakcji.

Pułapka 5: Mylenie kursu transakcyjnego z „kursem z tabeli kursów”

Kurs transakcyjny bywa zapisany w samym fakcie (np. kurs z dokumentu, kurs z systemu ERP, kurs uzgodniony). Wtedy nie jest to „kolejny” kurs do wyszukania po dacie — tylko atrybut transakcji. Pułapka polega na tym, że miara mimo to próbuje pobierać kurs z tabeli FX na podstawie daty i waluty, przez co:

• dla tej samej transakcji możesz dostać inne wyniki zależnie od kontekstu daty (np. gdy raportujesz po miesiącu),
• pojawiają się rozjazdy między raportem a księgą (bo księga liczy według kursu dokumentu),
• mieszają się dwa reżimy: transaction rate i period-end/average rate.

Minimalna zasada: jeśli biznes mówi „kurs z dokumentu”, to konwersja powinna użyć kursu z wiersza (lub powiązanego klucza kursu), a nie kursu „wyliczonego z kalendarza”.

Pułapka 6: Podwójne przeliczenie (document → base → report) i niespójne ścieżki

W wielu modelach są równolegle przechowywane kwoty w:

• walucie dokumentu (np. AmountDoc),
• walucie bazowej (np. AmountBase),
• czasem także w walucie raportowej (np. AmountReporting w systemach konsolidacyjnych).

Pułapka pojawia się, gdy miara bez kontroli wybiera „jakąś” kwotę i przelicza „jakimś” kursem, co prowadzi do sytuacji typu:

• podwójna konwersja: najpierw korzystasz z AmountBase, a potem jeszcze raz przeliczasz jakby to była kwota dokumentu,
• różne ścieżki dają różne wyniki: dokument→raport innym kursem niż dokument→baza oraz baza→raport,
• niewidoczne błędy w agregacji: na poziomie sumy „wygląda ok”, ale na poziomie wierszy jest źle (lub odwrotnie).

W praktyce potrzebujesz z góry ustalić, które kwoty są „źródłem prawdy” dla danego scenariusza i konsekwentnie trzymać się jednej ścieżki.

Pułapka 7: Dynamiczny przełącznik waluty raportu, który psuje kontekst (SELECTEDVALUE i brak selekcji)

Typowy wzorzec to slicer „Waluta raportu” i miara, która ma reagować na wybór. Pułapka nie polega na samym przełączniku, tylko na tym, że w realnych raportach często występuje:

• brak wyboru (użytkownik nic nie zaznaczył),
• wielokrotny wybór (kilka walut),
• kontekst w macierzy/wykresie, gdzie waluta raportu jest jednocześnie na osi lub w legendzie.

Jeśli miara opiera się wprost na SELECTEDVALUE bez sensownej obsługi tych przypadków, dostaniesz losowe zachowania: BLANK(), „zatrzaśnięcie” na jednej walucie albo wyniki liczone w złym kontekście.

Minimalny przykład ryzykownego wzorca (jako sygnał ostrzegawczy):

VAR Curr = SELECTEDVALUE ( 'Currency'[Code] )
RETURN
IF ( Curr = "EUR", [Sales_EUR], [Sales_USD] )

Taki kod często działa w demo, a psuje się przy wielokrotnych selekcjach i w wizualizacjach z wieloma poziomami kontekstu.

Pułapka 8: „Magiczne” łączenie tabel kursów z faktami — kiedy potrzebujesz TREATAS/USERELATIONSHIP

W scenariuszach wielowalutowych często istnieje więcej niż jedna „data istotna” oraz więcej niż jeden klucz waluty:

• data księgowania vs data dokumentu vs data dostawy,
• waluta dokumentu vs waluta bazowa vs waluta raportu,
• kurs typu: spot/avg/eom, czasem jeszcze osobny „rate type”.

Jeżeli spróbujesz to wszystko spiąć jedną relacją, kończy się to zwykle jednym z dwóch problemów: albo relacje są niejednoznaczne (Power BI je wyłącza lub wymaga nieintuicyjnych ustawień), albo filtruje się nie ta tabela kursów, która powinna. Wtedy w DAX pojawia się potrzeba świadomego sterowania propagacją filtrów:

• USERELATIONSHIP — gdy istnieje kilka relacji (np. Fact[PostingDate] i Fact[DocumentDate] do Calendar[Date]) i w miarze chcesz wybrać właściwą,
• TREATAS — gdy filtr (np. waluta raportu) nie ma fizycznej relacji do tabeli kursów lub faktu, a chcesz „rzucić” go jako wirtualną relację.

Przykładowy, minimalistyczny szkic użycia (tylko jako ilustracja intencji):

CALCULATE (
    [Amount in Doc Currency],
    USERELATIONSHIP ( 'Calendar'[Date], Fact[PostingDate] ),
    TREATAS ( VALUES ( 'Report Currency'[Code] ), 'FX'[ToCurrency] )
)

Pułapka polega na tym, że bez takiego sterowania model może „przypadkiem” używać aktywnej relacji i przypadkowej ścieżki filtrowania, dając wyniki poprawne tylko w części wizualizacji.

Wspólny mianownik pułapek 5–8: zanim napiszesz miarę, musisz jednoznacznie zdefiniować: (1) w jakiej walucie jest kwota wejściowa, (2) jaki kurs ma być użyty (transakcyjny czy okresowy), (3) do jakiej waluty liczysz wynik oraz (4) jak filtr waluty i daty ma dotrzeć do właściwej tabeli kursów. Jeśli którykolwiek z tych elementów jest „domyślny”, DAX zwykle wybierze domyślność niezgodną z biznesem.

5. Pułapki 9–12: brakujące kursy, weekendy/święta, forward-fill vs last available, strefy czasowe i daty transakcji

Gdy w modelu pojawiają się kursy walut, szybko wychodzi na jaw, że „data” w tabeli kursów rzadko idealnie pokrywa się z „datą” w faktach. W efekcie miary potrafią zwracać puste wartości, skakać między kursami, albo przeliczać transakcje po kursie z niewłaściwego dnia. Poniżej cztery typowe pułapki, które nie wynikają z samego DAX, tylko z niedopasowania danych i niejawnych założeń o tym, co znaczy „kurs na dany dzień”.

Pułapka 9: brakujące kursy (luki w tabeli FX)

Najczęstszy przypadek: tabela kursów nie ma wpisu dla każdej kombinacji Data × Waluta. To może wynikać z jakości danych, zakresu pobrania (np. tylko wybrane waluty), ograniczeń źródła lub zmian w dostępności kursów. DAX w takim układzie często kończy na:

• BLANK() w przeliczeniach (bo nie znaleziono kursu),
• niespójnych sumach (część pozycji policzona, część pusta),
• „cichym” użyciu niewłaściwego kursu, jeśli logika wyszukiwania pozwala na przypadkowe dopasowanie.

Kluczowe jest rozróżnienie: czy brak kursu ma oznaczać brak danych (błąd), czy użyj kursu zastępczego. To decyzja biznesowa, a nie czysto techniczna.

Pułapka 10: weekendy i święta (data kalendarzowa vs data notowania)

Nawet przy „pełnych” danych kursowych, kursy mogą być publikowane tylko w dni robocze. Jeśli transakcje występują w sobotę/niedzielę lub w święto, połączenie po dacie 1:1 zwykle nie zadziała. Typowe symptomy:

• sprzedaż z weekendu przelicza się na puste,
• na wykresach dziennych pojawiają się „dziury”,
• w zależności od wizualizacji i kontekstu filtra wyniki „falują” (raz są, raz znikają).

W praktyce trzeba zdefiniować regułę: czy dla dni bez notowania bierzemy kurs z poprzedniego dnia notowania, czy z następnego, czy stosujemy osobny kurs (np. umowny). DAX sam tego nie „zgadnie”.

Pułapka 11: forward-fill vs last available (pozornie podobne, a dają inne wyniki)

Dwie popularne strategie „uzupełniania” kursu przy brakach to:

Na poziomie miar DAX obie metody mogą wyglądać niemal tak samo („znajdź ostatnią datę z kursem”), ale różnią się w kontroli i audycie: forward-fill często maskuje braki w danych, a last available w miarze może powodować trudniejsze do debugowania efekty zależne od kontekstu filtra.

Minimalny szkic wzorca (jako ilustracja intencji, bez wchodzenia w bibliotekę wzorców):

// Idea: znajdź kurs dla ostatniej daty z notowaniem nie późniejszej niż data w kontekście
VAR d = MAX('Calendar'[Date])
VAR lastD =
    CALCULATE(
        MAX('FX'[Date]),
        'FX'[Date] <= d
    )
RETURN
    CALCULATE(
        MAX('FX'[Rate]),
        'FX'[Date] = lastD
    )

Pułapka: powyższy szkic „działa” w prostym przypadku, ale bez doprecyzowania waluty, typu kursu, relacji i kontekstu może zwracać niejednoznaczne wyniki.

Pułapka 12: strefy czasowe i „data transakcji” (kiedy dzień jest dniem?)

W systemach źródłowych transakcje zwykle mają timestamp (data+czas) w określonej strefie czasowej (albo w UTC), natomiast tabela kursów jest publikowana jako data notowania według kalendarza instytucji publikującej. Jeśli w modelu sprowadzisz transakcję do samej daty bez jawnej reguły, pojawiają się błędy brzegowe:

• transakcje z okolic północy wpadają w „zły” dzień po konwersji strefy,
• kurs „z dnia” może w praktyce obowiązywać od określonej godziny (cut-off), a nie od 00:00,
• przy raportowaniu globalnym ta sama transakcja może mieć inną „datę lokalną” zależnie od regionu.

Najczęstsze konsekwencje to rozjazdy między raportem a księgowością/ERP (bo tam zastosowano inną regułę cut-off) oraz trudne do wyjaśnienia różnice w agregatach dziennych i miesięcznych.

Wskazówka praktyczna: zanim napiszesz miarę, ustal i udokumentuj, która data steruje doborem kursu: data dokumentu, data księgowania, data dostawy, czy data w strefie lokalnej vs UTC. W DAX nawet poprawna składniowo miara nie obroni się, jeśli „dzień” w faktach i „dzień” w FX oznaczają co innego.

6. Biblioteka poprawnych wzorców DAX do przeliczeń + checklista testów i walidacji

Przeliczenia walut w DAX warto budować z powtarzalnych, „bezpiecznych” klocków. Poniżej znajduje się biblioteka wzorców, które pomagają kontrolować kontekst filtra, ziarnistość oraz ścieżkę filtrowania relacji tak, aby kurs był dobierany konsekwentnie (dzienny/miesięczny/transakcyjny) i nie „pływał” w zależności od wizualizacji.

6.1. Szybka mapa: kiedy używać którego klocka

6.2. Wzorce miar: „kalkuluj na kursach, nie na intuicji”

Poniższe szkice nie narzucają konkretnego modelu, ale pokazują intencję: najpierw ustal kurs w jednoznacznym kontekście, potem przelicz wartość. W praktyce nazwij i ustandaryzuj te miary (np. FX Rate, Amount (Reporting)), aby były wielokrotnego użytku.

A) Wzorzec: pobranie kursu przez CALCULATE (kontrolowany filtr)

Dobry, gdy kurs jest w tabeli kursów i chcesz wyraźnie określić: datę/okres, walutę źródłową, walutę docelową, typ kursu.

FX Rate (controlled) :=
VAR _From = SELECTEDVALUE ( 'Currency From'[Code] )
VAR _To   = SELECTEDVALUE ( 'Currency To'[Code] )
VAR _Date = MAX ( 'Calendar'[Date] )
RETURN
CALCULATE (
    MAX ( 'FX Rates'[Rate] ),
    KEEPFILTERS ( 'FX Rates'[From] = _From ),
    KEEPFILTERS ( 'FX Rates'[To]   = _To ),
    KEEPFILTERS ( 'FX Rates'[Date] = _Date )
)

Po co KEEPFILTERS? Żeby dopinać warunki bez „resetowania” filtrów, które użytkownik ustawił w raporcie (np. typ kursu). Jeśli chcesz je nadpisać — rób to świadomie.

B) Wzorzec: kurs miesięczny jako filtr na „miesiąc” (bez mieszania ziarnistości)

Jeśli tabela kursów jest miesięczna, filtruj ją po kluczu miesiąca (np. YearMonth), zamiast po dacie dziennej. Wzorzec polega na przestawieniu filtra na właściwe ziarno.

FX Rate (month grain) :=
VAR _YM = SELECTEDVALUE ( 'Calendar'[YearMonth] )
RETURN
CALCULATE (
    MAX ( 'FX Rates Monthly'[Rate] ),
    KEEPFILTERS ( 'FX Rates Monthly'[YearMonth] = _YM )
)

W praktyce klucz miesiąca może być liczbą (np. 202503) lub datą pierwszego dnia miesiąca — ważne, by był spójny w modelu.

C) Wzorzec: ograniczanie „rozlewania się” filtrów (CROSSFILTER jako narzędzie diagnostyczne i taktyczne)

Czasem chcesz na chwilę wyłączyć/zmienić kierunek filtrowania, aby miara kursu nie była zależna od przypadkowej relacji. Ten wzorzec pomaga też w testach: sprawdzasz, czy wynik zmienia się tylko dlatego, że filtr „przecieka” inną ścieżką.

FX Rate (isolated) :=
CALCULATE (
    [FX Rate (controlled)],
    CROSSFILTER ( 'Fact'[DateKey], 'Calendar'[DateKey], NONE )
)

Uwaga: To jest narzędzie do świadomego sterowania kontekstem, a nie substytut poprawnych relacji w modelu.

D) Wzorzec: LOOKUPVALUE do prostych, jednoznacznych kluczy

LOOKUPVALUE jest użyteczne, gdy masz gwarancję unikalności (np. dokładnie jeden kurs dla (Data, From, To)). Daje czytelny kod, ale szybko „pęka”, gdy pojawiają się duplikaty, typy kursów lub dodatkowe atrybuty.

FX Rate (lookup) :=
LOOKUPVALUE (
    'FX Rates'[Rate],
    'FX Rates'[Date], MAX ( 'Calendar'[Date] ),
    'FX Rates'[From], SELECTEDVALUE ( 'Currency From'[Code] ),
    'FX Rates'[To],   SELECTEDVALUE ( 'Currency To'[Code] )
)

E) Wzorzec: LASTNONBLANK dla „ostatniego dostępnego kursu”

Gdy kursy nie występują codziennie (weekendy/święta/braki), często wybiera się ostatni dostępny kurs przed datą kontekstu. LASTNONBLANK to klasyczny klocek do takiego doboru, pod warunkiem że kontrolujesz zakres dat.

FX Rate (last available) :=
VAR _CutoffDate = MAX ( 'Calendar'[Date] )
RETURN
CALCULATE (
    MAX ( 'FX Rates'[Rate] ),
    LASTNONBLANK (
        FILTER ( ALL ( 'Calendar'[Date] ), 'Calendar'[Date] <= _CutoffDate ),
        CALCULATE ( MAX ( 'FX Rates'[Rate] ) )
    )
)

Ten wzorzec jest szczególnie wrażliwy na to, czy oś czasu pochodzi z tabeli kalendarza oraz czy filtry na walutach/typie kursu są spójnie utrzymane.

6.3. Wzorce „miara przeliczeniowa”: najpierw kurs, potem kwota

Przeliczenie kwoty jest najbezpieczniejsze, gdy:

• kurs jest liczony jako osobna miara (łatwiejsze testy, ponowne użycie),
• kwota jest agregowana na właściwej ziarnistości, a nie po fakcie „przemnożona” z przypadkowym kursem,
• świadomie wybierasz funkcję agregacji dla kursu (MAX/MIN/AVERAGE zwykle jest tylko techniką wyciągnięcia pojedynczej wartości z kontekstu, nie „logiką biznesową”).

Amount (Reporting) :=
VAR _Rate = [FX Rate (controlled)]
RETURN
SUM ( 'Fact'[Amount] ) * _Rate

To jest celowo uproszczony szablon. Jego wartość polega na separacji odpowiedzialności: kwota vs dobór kursu.

6.4. Mini-checklista testów i walidacji miar walutowych

• Test kontekstu daty: sprawdź wynik dla pojedynczego dnia, miesiąca i zakresu (czy kurs nie zmienia się „dziwnie” przy agregacji okresu).
• Test ziarnistości: porównaj wyniki w tabeli z datą transakcji vs bez daty (czy przeliczenie nie zależy od tego, czy data jest na osi).
• Test jednowartościowości kursu: zweryfikuj, że dla danej kombinacji filtrów istnieje dokładnie jeden kurs (brak duplikatów lub mieszania typów kursu).
• Test braków danych: zasymuluj brak kursu dla daty i sprawdź zachowanie (blank vs ostatni dostępny vs błąd) zgodnie z oczekiwaniem.
• Test filtrów walut: zmień walutę docelową/źródłową w slicerze i sprawdź, czy kurs aktualizuje się bez efektów ubocznych (np. nie filtruje faktów nieintencjonalnie).
• Test relacji: porównaj wynik miary z wariantem „izolowanym” (np. z CROSSFILTER NONE). Jeśli różnice są nieoczekiwane, problemem bywa ścieżka filtrowania.
• Test sum kontrolnych: policz tę samą wartość dwiema drogami (np. przeliczenie na poziomie transakcji vs przeliczenie na poziomie dnia) i sprawdź rozjazdy.
• Test wydajności: zmierz czas odpowiedzi na wizualizacjach z dużą liczbą punktów (czy wzorzec nie skaluje się kwadratowo przez iteracje po datach/walutach).
• Test stabilności na „Total”: sprawdź, czy total nie jest inną logiką niż wiersze (częsty objaw niekontrolowanego kontekstu).
• Test zgodności z źródłem: wybierz kilka transakcji i ręcznie policz (kurs × kwota) w Power Query/Excelu lub w SQL, porównując do wyniku miary.

Jeżeli którykolwiek test nie przechodzi, zazwyczaj oznacza to problem z: (1) ziarnistością tabeli kursów, (2) niejednoznacznym doborem kursu w filtrach, lub (3) nieintencjonalnym filtrowaniem przez relacje. Biblioteka powyżej jest zaprojektowana tak, aby te trzy obszary dało się izolować i diagnozować wprost w DAX.

7. Rozwiązywanie konfliktów merge w PBIP/TMDL i dobre praktyki minimalizacji konfliktów

W zespołowej pracy nad raportami Power BI coraz częściej w grę wchodzi repozytorium Git, równoległe gałęzie oraz scalanie zmian. W trybie PBIP model i raport są rozbijane na pliki tekstowe, a w przypadku modelu dodatkowo pojawia się TMDL jako reprezentacja metadanych. To ogromny krok naprzód względem pojedynczego pliku PBIX, ale jednocześnie oznacza, że konflikty merge stają się realnym elementem codziennej pracy — szczególnie w projektach, gdzie miary (w tym walutowe) są intensywnie edytowane i refaktorowane.

Najczęstsza przyczyna konfliktów nie wynika z „błędów w DAX”, tylko z tego, że kilka osób dotyka tej samej powierzchni modelu: tych samych obiektów (miar, tabel, relacji) lub tych samych właściwości (format, opis, folder wyświetlania). Przy miernikach walutowych dochodzi jeszcze ryzyko częstych, drobnych zmian w nazwach, formatowaniu i strukturze miar, co zwiększa liczbę punktów potencjalnego konfliktu.

PBIP vs PBIX: co się zmienia z perspektywy merge

• PBIX jest monolitem — praktycznie nie nadaje się do sensownego porównywania i scalania na poziomie treści. Konflikt oznacza zwykle ręczne odtwarzanie zmian.
• PBIP rozdziela artefakty, dzięki czemu Git potrafi wskazać, co konkretnie się zmieniło. To ułatwia code review i daje szansę na bezpieczne merge — o ile projekt jest uporządkowany.
• TMDL jest tekstową definicją modelu. Pozwala śledzić zmiany w metadanych (np. miary, formaty, opisy, foldery, relacje), ale jest też wrażliwy na sytuacje, w których narzędzia automatycznie przebudowują fragmenty definicji w sposób trudny do scalania.

Typowe źródła konfliktów w TMDL, które nie wyglądają groźnie

• Równoczesne zmiany w tej samej mierze: jedna osoba poprawia logikę przeliczeń, druga zmienia nazwę, format lub folder wyświetlania — konflikt powstaje, choć merytorycznie zmiany się nie wykluczają.
• Masowe refaktoryzacje: zmiana prefiksów, przeniesienia do folderów, ujednolicanie formatów liczb/walut lub opisów. Git widzi ogromny diff, a realna intencja jest prosta.
• Zmiany w relacjach i roli kalendarza: edycja kierunku filtrowania lub aktywnej relacji wpływa na wiele elementów metadanych i często „przesuwa” konflikt w inne miejsca niż oczekiwane.
• Różnice w ustawieniach lokalnych i formatowaniu: formaty walut, separatory, ustawienia regionalne lub automatyczne zmiany właściwości potrafią generować szum w diffach.
• Jednoczesne porządki w modelu: ktoś usuwa nieużywane kolumny/miary, a ktoś inny odwołuje się do nich w nowej mierze — konflikt nie zawsze jest czysto tekstowy, czasem ujawnia się dopiero po odświeżeniu modelu.

Zasady pracy zespołowej, które realnie zmniejszają liczbę konfliktów

• Ustal „właścicieli” obszarów: np. jedna osoba utrzymuje tabelę kursów i relacje, inna buduje miary raportowe. Mniej nakładania się zmian to mniej konfliktów.
• Ogranicz rozmiar PR-ów: małe, tematyczne pull requesty scalają się łatwiej i są prostsze do przeglądu. Unikaj łączenia refaktoryzacji nazw z merytoryczną zmianą logiki.
• Konwencje nazewnictwa i folderów: stały schemat na miary walutowe (np. rozróżnienie kursu dziennego/miesięcznego/transakcyjnego w nazwie) zmniejsza liczbę późniejszych „porządków”, a więc i konfliktów.
• Stabilizuj formatowanie: jeśli zespół ma uzgodnione zasady opisów, formatów i kategorii danych, unikniesz „wojen” o kosmetykę w metadanych.
• Nie mieszaj zmian w modelu z układem raportu: najlepiej rozdzielać PR-y dotyczące logiki (model/miary) od zmian czysto wizualnych. To ogranicza sytuacje, w których konflikt jest rozproszony po wielu plikach.
• Refaktoryzacje rób w oknach serwisowych: masowe zmiany w nazwach, przenoszenie miar czy przebudowa folderów powinny być komunikowane i wykonywane w krótkim czasie, gdy nikt inny nie modyfikuje tych samych elementów.
• Wymuszaj przegląd zmian w metadanych: w review zwracaj uwagę na „szum” — jeśli PR zawiera dużo zmian, które nie są związane z celem (np. hurtowe zmiany formatów), warto to odseparować.

Jak podejść do konfliktu merge, żeby nie zepsuć logiki przeliczeń

Konflikt w TMDL warto traktować jak konflikt w specyfikacji, a nie jak konflikt w kodzie aplikacji. Priorytetem jest zachowanie spójności semantycznej modelu. W praktyce oznacza to:

• Ustal intencję obu stron: czy jedna zmiana była refaktoryzacją (np. nazwy i porządek), a druga zmianą logiki biznesowej? Jeśli tak, scalenie powinno zachować obie.
• Sprawdź zależności: miary walutowe często są bazą dla innych miar. Konflikt rozwiązany „na oko” może spowodować kaskadowe błędy w wielu miejscach.
• Odróżnij konflikty treści od konfliktów właściwości: czasem spór dotyczy tylko opisu, folderu lub formatu. Wtedy ryzyko biznesowe jest małe, ale ryzyko bałaganu w modelu — duże.
• Po scaleniu weryfikuj zachowanie raportu: jeśli konflikt dotyczył relacji, tabel kursów lub kluczowych miar, błędy mogą być niewidoczne na poziomie kompilacji, a ujawniają się dopiero w wynikach.

Dobre praktyki repozytorium: porządek, który wspiera DAX

• Jasne reguły branching: krótkie gałęzie, szybkie scalanie, unikanie długotrwałych odchyleń od main ogranicza liczbę konfliktów w modelu.
• Spójne zasady wersjonowania zmian: opisuj PR-y w języku biznesowym (co zmienia się w kalkulacjach i dlaczego), a nie tylko technicznie. To ułatwia rozstrzyganie konfliktów.
• Separacja zmian ryzykownych: zmiany w relacjach, kluczach dat, tabelach kursów i miarach bazowych powinny być wdrażane ostrożnie i możliwie pojedynczo, aby łatwo je cofnąć.
• Unikanie „automatycznych porządków”: jeśli narzędzie lub nawyk generuje masowe zmiany w metadanych bez wartości merytorycznej, lepiej to ograniczyć — w przeciwnym razie każdy merge będzie drogi i ryzykowny.

Najważniejsza zasada: w projektach z przeliczeniami walut konflikt merge to potencjalna zmiana wyniku finansowego. Dlatego scalanie powinno być traktowane jak element kontroli jakości modelu, a nie jedynie formalność w Git.

8. Automatyczne testy i CI: analizatory, jednostkowe testy miar, minimalny zestaw narzędzi

Przeliczenia walut w DAX psują się najczęściej „po cichu”: miara zwraca liczbę, ale jest ona błędna dla wybranych przekrojów czasu, walut lub poziomów agregacji. Dlatego poza ręczną walidacją warto mieć automatyczne testy, które wykryją regresje po zmianie modelu, relacji, kalendarza albo logiki kursów. W tym kontekście CI (continuous integration) nie jest luksusem — to sposób na szybkie wychwycenie problemów z ziarnistością, kontekstem filtra i niejednoznacznymi zależnościami.

W Cognity łączymy teorię z praktyką – dlatego ten temat rozwijamy także w formie ćwiczeń na szkoleniach.

Co testować w miarach walutowych (bez wchodzenia w implementację)

• Poprawność na różnych ziarnistościach: ten sam wynik biznesowy powinien zachowywać się sensownie dla dnia, miesiąca, kwartału i roku (a nie „wyglądać dobrze” tylko miesięcznie).
• Stabilność względem kontekstu: wyniki dla waluty raportu, waluty dokumentu i waluty bazowej powinny być spójne w filtrach po jednostkach, produktach, krajach czy kanałach.
• Kontrole brzegowe: brak kursu, weekend/święto, transakcje na granicy miesiąca, filtry wielokrotnego wyboru waluty, mieszane źródła kursów.
• Detekcja podwójnych przeliczeń: miara nie powinna czasem przeliczać „już przeliczonej” kwoty (typowe przy zmianach relacji lub ponownym użyciu miar pośrednich).
• Spójność sum: suma po wierszach (np. transakcjach) kontra przeliczenie na poziomie agregatu (np. miesiąca) — to najczęstsze źródło ukrytych rozjazdów.

Analizatory i statyczne „checki” jako pierwsza linia obrony

Zanim uruchomisz testy porównujące liczby, warto łapać błędy strukturalne i antywzorce wcześnie:

• Analiza modelu: ostrzeżenia o niejednoznacznych ścieżkach filtrowania, nieaktywnych relacjach, relacjach wiele-do-wielu użytych „przypadkiem”, kolumnach dat bez spójnego kalendarza.
• Analiza miar: wykrywanie miar zależnych od wartości domyślnych, ryzykownego polegania na pojedynczej wartości w filtrze, niezamierzonego ignorowania filtrów lub nadpisywania kontekstu.
• Standardy nazewnictwa i warstw: spójne konwencje (np. oddzielanie miar bazowych od raportowych) ułatwiają testowanie i redukują pomyłki przy ponownym użyciu miar.

Jednostkowe testy miar: jak myśleć o nich praktycznie

Testy jednostkowe w BI nie muszą przypominać klasycznego programowania, ale powinny mieć podobną cechę: mały, powtarzalny scenariusz i jednoznaczne oczekiwanie. Dla walut oznacza to w szczególności:

• Małe, kontrolowane próbki danych z ręcznie wyliczonym oczekiwanym wynikiem (np. kilka transakcji i kilka kursów), aby od razu wykryć błędną agregację kursu.
• Testy regresyjne: po każdej zmianie modelu lub miar porównujesz wyniki zestawu kluczowych wizualizacji/miar dla tych samych filtrów.
• Testy kontrastowe: te same dane liczone z użyciem kursu dziennego i miesięcznego powinny różnić się w przewidywalny sposób; jeśli różnica „znika” albo rośnie nielogicznie, to sygnał błędu.
• Assercje na właściwości, nie tylko na liczby: np. brak wyniku tam, gdzie kursu brak (jeśli taka jest polityka), albo deterministyczny wybór kursu w przypadku wielu rekordów.

CI dla modeli Power BI: co automatyzować minimalnie

Minimalne CI dla projektu z przeliczeniami walut powinno wykonywać się przy każdej zmianie w repozytorium i kończyć się statusem „zielony/czerwony”. Kluczowe elementy:

• Walidacja struktury artefaktów: wykrywanie niepożądanych zmian w metadanych modelu (relacje, kierunki filtrowania, typy danych, formaty).
• Pakiet testów liczbowych dla kilku krytycznych miar i przekrojów (dzień/miesiąc, kilka walut, przypadki brzegowe).
• Raport z różnic: gdy test nie przechodzi, potrzebujesz czytelnej informacji „co i gdzie” zmieniło wynik (miara, filtr, zakres dat, waluta).
• Gating: brak możliwości wdrożenia/połączenia zmian, jeśli kluczowe testy walutowe nie przechodzą.

Minimalny zestaw narzędzi (praktyczny, bez narzucania jednego ekosystemu)

• Repozytorium Git z ustandaryzowaną strukturą projektu (żeby zmiany modelu i miar dało się śledzić i recenzować).
• Narzędzie do analizy modeli i miar (typ „lint” dla DAX i metadanych), uruchamiane lokalnie i w CI.
• Framework do testów datasetu, który potrafi wykonywać zapytania do modelu i porównywać wyniki z oczekiwaniami.
• Pipeline CI w dowolnym popularnym systemie (ważne, by wspierał uruchamianie skryptów, przechowywanie artefaktów i blokowanie merge przy błędach).
• Mechanizm środowisk (dev/test) lub przynajmniej osobny dataset testowy, aby testy nie zależały od zmiennych danych produkcyjnych.

Dobre praktyki, które obniżają koszt testowania

• Deterministyczne źródła kursów w testach: testy powinny działać na niezmiennym zestawie kursów, inaczej będą „płonąć” bez realnej regresji.
• Izolacja miar bazowych: prostsze miary wejściowe są łatwiejsze do przetestowania niż jedna „mega-miara” od wszystkiego.
• Jawne scenariusze walutowe: osobne testy dla kursu dziennego, miesięcznego i transakcyjnego, zamiast jednego testu „czy działa FX”.
• Recenzje zmian w relacjach: większość regresji walutowych wynika z modelu, nie z samej formuły; CI powinno szczególnie pilnować zmian w relacjach i kluczach dat.

Automatyczne testy i CI nie eliminują złożoności przeliczeń walut, ale zamieniają ją w kontrolowane ryzyko: błędy wychodzą szybko, w małym zakresie zmian, a nie dopiero po publikacji raportu i w trudnym do odtworzenia kontekście filtrów.

Power BI: anti-pattern „jedna mega-tabela” — 8 symptomów i plan refaktoru bez przestoju 28 czerwca 2026

Power BI: wersjonowanie miar DAX w Git bez rozjazdów definicji (workflow dla zespołu) 26 czerwca 2026