DAX dla sprzedaży: marża, rabat i KPI w jednym modelu

Kontekst biznesowy: po co łączyć marżę, rabat i KPI w jednym modelu

Oczekiwania sprzedaży, controllingu i zarządu wobec raportów

Dział sprzedaży, controlling i zarząd patrzą na te same dane z zupełnie różnych perspektyw, ale wszyscy opierają się na kilku kluczowych pojęciach: przychód, marża, rabat, realizacja planu. Jeśli każde z tych pojęć jest liczone inaczej w różnych plikach Excela, rozmowa o wynikach kończy się dyskusją o definicjach, a nie o biznesie. Spójny model danych w Power Pivot z miarami DAX sprawia, że definicje są jednolite i powtarzalne, a różnica dotyczy wyłącznie filtrów i perspektyw analizy.

Sprzedaż oczekuje szybkiej odpowiedzi na pytania: który klient kupuje najwięcej, gdzie marża spada poniżej założeń, jaki rabat można zaoferować bez „zjadania” całej marży. Controlling potrzebuje możliwości łatwego przefiltrowania tych samych danych po regionach, grupach produktowych, kanałach sprzedaży, z rozbiciem na koszty i rabaty. Zarząd z kolei chce syntetycznych KPI, trendów i informacji, gdzie „ucieka” marża w porównaniu z planem. Jeśli wszystkie te odpowiedzi wynikają z jednego zestawu miar DAX, nie ma sporu o to, która liczba jest „prawdziwa”.

Problem „stu plików Excela” i niespójnych definicji

Typowy obraz: handlowcy pracują na swoich arkuszach z klientami, controlling ma własne pliki budżetowe, a zarząd otrzymuje ręcznie przygotowywaną prezentację z „podsumowanymi” danymi. Każdy z tych plików ma własne formuły liczenia marży i rabatów, często z drobnymi różnicami: raz marża liczona jest od przychodu netto, raz nie uwzględnia określonych kosztów, a rabaty są traktowane raz jako koszt sprzedaży, raz jako obniżenie przychodu.

W takim środowisku niemożliwe staje się prowadzenie spójnej analizy: jedna osoba patrzy na marżę po rabatach, inna na marżę przed rabatami, jeszcze inna nie rozróżnia bonusów rocznych od rabatów transakcyjnych. Power Pivot i DAX pozwalają przenieść logikę biznesową z rozproszonych formuł arkuszowych do centralnego modelu. Kolumny kalkulowane przestają być rozrzucone po setkach zakładek, a krytyczne miary biznesowe są zdefiniowane w jednym miejscu i wielokrotnie wykorzystywane.

Dlaczego jeden model danych wygrywa z setkami formuł arkuszowych

Model danych w Excelu z Power Pivotem wprowadza klarowny podział: dane źródłowe w tabelach faktów i wymiarów, a logika biznesowa w miarach DAX. Jeśli zmienia się definicja marży (np. do kosztu własnego dochodzą koszty logistyczne), modyfikowana jest jedna miara, a wszystkie raporty, przestawne i dashboardy automatycznie liczą marżę według nowych zasad. W klasycznym Excelu taka zmiana oznacza przeszukiwanie i poprawianie formuł w wielu plikach, co jest powolne i podatne na błędy.

Jednolity model danych daje także skalowalność: można bez większego wysiłku dołożyć kolejne wymiary analizy (np. kanał sprzedaży online/offline), nowe typy rabatów czy plany sprzedażowe na kolejny rok, korzystając z już istniejącej infrastruktury relacji i miar. DAX potrafi pracować na setkach tysięcy czy milionach wierszy bez konieczności dzielenia danych na oddzielne pliki dla każdego regionu czy handlowca.

Zmiana sposobu rozmowy o wynikach dzięki DAX

Gdy marża, rabaty i KPI sprzedażowe są oparte o te same miary DAX, przestaje się dyskutować o „które liczby są z systemu A, a które z arkusza B”. Rozmowa przenosi się na poziom scenariuszy i decyzji: co się stanie z marżą, jeśli podniesiemy poziom rabatów w konkretnym segmencie, jak bonusy roczne wpływają na rentowność strategicznych klientów, czy planowana kampania rabatowa nie wyzeruje marży na kluczowej kategorii produktowej.

Spójny model danych z dobrze zdefiniowanymi miarami DAX wprowadza język liczb, który wszyscy w firmie rozumieją tak samo. Ułatwia to także ustalanie odpowiedzialności: dział sprzedaży widzi, jak poziom rabatów wpływa na KPI marżowe, controlling ma narzędzie do szybkiego diagnozowania anomalii, a zarząd dysponuje podstawą do stabilnych decyzji strategicznych, bez ciągłego podważania wiarygodności raportów.

Projekt modelu danych sprzedażowych pod DAX: tabele, relacje, kierunek filtrów

Kluczowe tabele w typowym modelu sprzedażowym

Podstawa analiz marży i rabatów to dobrze zaprojektowany model danych. W większości przypadków wystarczy kilka jasno zdefiniowanych tabel faktów i wymiarów. Typowa struktura to:

• FaktySprzedaży – pozycje dokumentów sprzedaży: daty, produkt, klient, ilość, cena transakcyjna, rabaty transakcyjne, koszty przypisane do pozycji (jeśli są na poziomie transakcji).
• Produkty – słownik produktów: kod, nazwa, grupa produktowa, marka, kategoria marżowa, jednostka miary.
• Klienci – słownik klientów: identyfikator, nazwa, segment, kanał sprzedaży, region, opiekun handlowy.
• Kalendarz – tabela dat: dzień, miesiąc, kwartał, rok, tygodnie, flagi typu dzień roboczy, koniec okresu, itp.
• Sprzedawcy – lista handlowców: identyfikator, imię i nazwisko, region, struktura sprzedaży.
• Cenniki/Rabaty – definicje cen katalogowych i polityk rabatowych: poziomy rabatów, progi wolumenowe, obowiązywanie w czasie.
• Koszty (opcjonalnie) – jeśli koszty nie są w faktach sprzedaży: koszt standardowy, koszt zakupu, koszt logistyczny przypisany do produktu lub klienta.

Każda z tych tabel pełni swoją specyficzną rolę. Tabela faktów powinna zawierać detal transakcyjny, natomiast wszystkie opisy, kategoryzacje i parametry („słowniki”) trafiają do tabel wymiarów. Taki podział umożliwia budowanie miar DAX niezależnych od dodatkowych atrybutów, które można później dowolnie dodawać do wymiarów.

Schemat gwiazdy kontra płaska tabela sprzedaży

Schemat gwiazdy (star schema) oznacza jedną główną tabelę faktów, do której relacyjnie „podłączone” są tabele wymiarów. Alternatywą jest płaska tabela sprzedaży, w której wszystkie informacje (o produkcie, kliencie, sprzedawcy, rabacie) znajdują się w jednej tabeli. Płaska tabela bywa kusząca na starcie, bo szybko pozwala coś policzyć bez projektowania relacji. Jednak przy rosnącej złożoności i wolumenie danych jej wady są bardzo wyraźne.

Schemat gwiazdy daje przede wszystkim:

• łatwiejsze utrzymanie – zmiana atrybutów produktu odbywa się w jednej tabeli zamiast w wielu miejscach,
• lepszą wydajność – mniejsze tabele wymiarów są efektywniejsze pamięciowo i szybciej się filtrują,
• prawidłowe filtrowanie – relacje jeden-do-wielu zapewniają spójne działanie filtrów w raportach.

Płaska tabela może być akceptowalna przy bardzo prostych modelach, bez dodatkowych wymiarów i z niewielką liczbą wierszy. Jeśli jednak dochodzą rabaty retrospektywne, osobne tabele z planami sprzedaży, analizy na poziomie sprzedawcy i kanału, przejście na schemat gwiazdy jest niemal koniecznością. W kontekście DAX łatwiej jest utrzymać poprawność miar w modelu gwiazdy niż w rozrastającej się płaskiej tabeli.

Relacje, kierunek filtrów i relacje nieaktywne

W Power Pivot relacje łączą tabele wymiarów z tabelą faktów. Standardowo stosuje się relację jeden-do-wielu, gdzie po stronie „jeden” jest wymiar (np. Produkty), a po stronie „wiele” fakty (FaktySprzedaży). Kierunek filtrowania zwykle ustawiony jest od wymiaru do faktów: filtr na Produkty powoduje filtrację wierszy w FaktySprzedaży. Zasadą jest, aby nie wymuszać dwukierunkowego filtrowania, jeśli nie jest absolutnie konieczne, ponieważ zwiększa to ryzyko dwuznacznych ścieżek filtrów i błędów w obliczeniach.

Relacje nieaktywne są użyteczne, gdy ten sam wymiar musi łączyć się z tabelą faktów na więcej niż jednym kluczu. Klasyczny przykład to tabela Kalendarz powiązana z FaktySprzedaży zarówno po dacie wystawienia dokumentu, jak i po dacie dostawy. Jedna z relacji jest aktywna (domyślna), druga – nieaktywna. W miarach DAX można tymczasowo włączyć relację nieaktywną funkcją USERELATIONSHIP, aby policzyć np. marżę wg daty dostawy.

Przy budowie modelu sprzedażowego z rabatami i marżą kluczowe są relacje:

• FaktySprzedaży – Produkty: po identyfikatorze produktu, relacja jeden-do-wielu, po stronie „jeden” Produkty,
• FaktySprzedaży – Klienci: po identyfikatorze klienta, relacja jeden-do-wielu,
• FaktySprzedaży – Kalendarz: po dacie dokumentu lub dacie sprzedaży,
• FaktySprzedaży – Sprzedawcy: po identyfikatorze sprzedawcy,
• Cenniki/Rabaty – Produkty / Klienci / Kanały: tu często pojawiają się relacje wiele-do-jednego lub potrzeba tabel pośredniczących (np. tabel mostów).

Przykładowy schemat modelu dla sprzedaży z rabatami i marżą

Przykładowy model danych dla analizy marży i rabatów może wyglądać następująco:

• FaktySprzedaży – klucze: IdTransakcji, DataSprzedaży, IdProduktu, IdKlienta, IdSprzedawcy; miary bazowe: Ilość, WartośćNetto, WartośćRabatówTrans, KosztWłasny.
• Produkty – klucz: IdProduktu; atrybuty: Kod, Nazwa, Grupa, Marka, KategoriaMarży.
• Klienci – klucz: IdKlienta; atrybuty: Nazwa, Segment, Kanał, Region.
• Kalendarz – klucz: Data; atrybuty: Rok, Miesiąc, Kwartał, Tydzień.
• Sprzedawcy – klucz: IdSprzedawcy; atrybuty: Nazwa, Region, Zespół.
• BonusyRoczne – klucze: IdKlienta, Rok; pola: ProgiObrotu, PoziomyBonusów, WartośćBonusów.
• Cennik – klucze: IdProduktu, DataOd, DataDo; pola: CenaKatalogowa, GrupaRabatu.

Relacje łączą FaktySprzedaży z wymiarami (Produkty, Klienci, Kalendarz, Sprzedawcy). Tabela Cennik może być połączona z Produktami, a BonusyRoczne z Klientami i Kalendarzem (po roku). Taki układ pozwala z jednej strony liczyć bieżące rabaty transakcyjne na poziomie pozycji dokumentu, a z drugiej – uwzględniać rabaty retrospektywne (bonusy) przy kalkulacji marży skorygowanej. DAX wykorzystuje te relacje w miarach opartych na CALCULATE, dzięki czemu nie trzeba ręcznie „szukać” powiązanych danych w formułach.

Dane wejściowe do analizy marży i rabatów: jak zorganizować źródła

Rozdzielenie cen katalogowych, rabatów, kosztów i sprzedaży

Jednym z kluczowych kroków jest rozdzielenie rodzajów danych na osobne strumienie. Sprzedaż to jedno, cenniki i rabaty – drugie, a koszty – trzecie. Ładowanie wszystkiego do jednej tabeli szybko prowadzi do niejasności, czy dana kolumna dotyczy ceny katalogowej, czy już ceny po rabacie, czy może ceny zakupu. Czytelny podział powinien objąć:

• Transakcje sprzedaży – tabela faktów z ilościami i wartościami po rabatach transakcyjnych (lub z informacją o rabatach na poziomie pozycji).
• Ceny katalogowe – tabela lub kolumny w wymiarze produktów z informacją o bazowej cenie sprzedaży, obowiązującej w określonym czasie.
• Koszty własne – tabela kosztów zakupu/standardowych przypisana do produktów (czasem również do klientów lub kanałów, jeśli koszty różnią się wg odbiorców).
• Rabaty i bonusy – tabele z definicjami polityk rabatowych, zarówno transakcyjnych, jak i retrospektywnych.

Taki podział ułatwia budowę przejrzystych miar: przychód liczony jest z transakcji, cena katalogowa z tabeli cenników, marża z połączenia przychodu i kosztów, natomiast udział rabatów można liczyć porównując cenę katalogową i cenę transakcyjną.

Poziomy kosztów a definicja marży

W jednej organizacji może funkcjonować kilka poziomów kosztów: koszt zakupu, koszt standardowy, koszt z uwzględnieniem logistyki, koszt pełny z narzutem ogólnym. Każdy z nich prowadzi do innej definicji marży. Przy budowie modelu DAX potrzebna jest jasność, który poziom kosztów ma być używany do jakich analiz i KPI. Przykładowo:

• Koszt zakupu – dobry do analizy negocjacji z dostawcami i marży handlowej,
• Koszt standardowy – używany często w planowaniu i budżetowaniu,
• Koszt logistyczny – przydatny przy analizie rentowności kanałów i regionów,
• Koszt pełny – kluczowy przy ocenie długoterminowej rentowności linii produktowych.

Granularność danych i spójność definicji

Przed zbudowaniem miar marży i rabatów trzeba ustalić granulat danych wejściowych. Jeśli transakcje sprzedaży są wprowadzane na poziomie pozycji dokumentu, a koszty tylko na poziomie miesięcznym i kategorii produktu, to definicja marży będzie inna niż w sytuacji, gdy koszt jest przypisany dokładnie do każdej pozycji sprzedaży. Spójność poziomu szczegółowości ma bezpośredni wpływ na wiarygodność KPI.

Najczęstsze warianty granulatu to:

• Poziom pozycji sprzedaży (IdTransakcji, IdProduktu, IdKlienta) – najbardziej szczegółowy, pozwala liczyć marżę i rabaty dla pojedynczych transakcji, ale wymaga dopasowania kosztów do tego poziomu.
• Poziom agregowany (np. Produkt + Miesiąc, Klient + Rok) – wygodny przy braku szczegółowych kosztów, ale utrudnia analizę jednostkową (rabaty „na sztukę”, promocje krótkoterminowe).
• Poziom miksowany – sprzedaż na poziomie pozycji, koszty i rabaty retrospektywne na poziomie wyższym; wymaga dodatkowych miar i często tabel pomocniczych do rozdziału kosztów i bonusów.

Jeśli planowane są analizy marży w przekroju pojedynczych transakcji, trzeba zadbać, by koszty i informacje o rabatach były możliwe do przypisania co najmniej do tego samego poziomu szczegółowości lub by istniał jasny klucz alokacji (np. udział ilościowy, udział wartościowy).

Jakość danych a miary marży i rabatu

Miary DAX mogą być poprawne syntaktycznie i logicznie, a mimo to dawać mylące wyniki, jeśli dane wejściowe są niespójne. Typowe problemy pojawiają się, gdy:

• brakuje powiązania między cennikiem a produktami (np. błędne IdProduktu),
• ceny katalogowe nie zawierają dat obowiązywania lub daty pokrywają się,
• koszty są aktualizowane z opóźnieniem względem sprzedaży,
• rabaty są księgowane w innym okresie niż sprzedaż, której dotyczą.

Jeśli część transakcji nie ma przypisanego kosztu, marża liczona jako różnica przychodu i kosztu będzie zawyżona. Dlatego przed rozpoczęciem budowy zaawansowanych miar warto przygotować prostą miarę kontrolną, np. „Sprzedaż bez kosztu”, która sumuje wartość sprzedaży tylko dla wierszy z pustym kosztem. Taki kontrolny KPI szybko pokazuje, czy model jest kompletny.

Kluczowe definicje: przychód, rabat, marża, marża procentowa

Przychód a obrót – doprecyzowanie pojęć

W praktyce biznesowej terminy „przychód”, „obrót”, „sprzedaż netto” bywają używane zamiennie, jednak w modelu DAX warto je zdefiniować precyzyjnie. Jeśli definicje nie są spójne, raporty z tego samego modelu mogą prezentować różne wartości „sprzedaży” w zależności od działu lub raportu.

Podstawowe rozróżnienie może wyglądać następująco:

• Sprzedaż brutto – wartość przed rabatami (ilość × cena katalogowa lub cena bazowa),
• Rabat transakcyjny – obniżka przypisana do konkretnej transakcji lub pozycji faktury (np. rabat liniowy, rabat od dokumentu),
• Sprzedaż netto – sprzedaż brutto pomniejszona o rabaty transakcyjne, stanowiąca podstawę do wyliczenia marży handlowej,
• Przychód skorygowany – sprzedaż netto dodatkowo pomniejszona o rabaty retrospektywne i bonusy (np. roczne rabaty od obrotu).

Jeśli sprzedaż brutto i netto nie są rozróżnione wprost w danych, trzeba je zrekonstruować na podstawie tabel cennikowych i pól rabatów zawartych w transakcjach. W przeciwnym razie trudno będzie policzyć rzeczywisty poziom rabatowania oraz marżę po uwzględnieniu wszystkich zachęt cenowych.

Definicja rabatu w modelu sprzedażowym

Rabat można rozumieć jako różnicę między ceną katalogową a ceną transakcyjną, ale w modelach złożonych w grę wchodzi kilka warstw:

• Rabat liniowy – przypisany do pozycji dokumentu (np. rabat procentowy na konkretną linię),
• Rabat od dokumentu – naliczany na poziomie całej faktury lub zamówienia (np. dodatkowe 2% od wartości dokumentu),
• Rabat programowy – wynikający z udziału w programie lojalnościowym, promocji sezonowych, kampanii, często rejestrowany osobno,
• Bonusy i rabaty retrospektywne – naliczane po czasie, w oparciu o osiągnięte progi obrotu lub marży.

W modelu DAX dobrze jest zdefiniować osobne miary dla każdej warstwy rabatu, a dopiero potem łączną miarę „Rabat całkowity”. Dzięki temu można analizować, które elementy polityki rabatowej najmocniej wpływają na obniżkę ceny. Przykładowo – w jakim stopniu marżę „zjadają” rabaty liniowe, a w jakim bonusy roczne.

Marża – które koszty bierzemy pod uwagę

Marża, w najprostszym ujęciu, to różnica pomiędzy przychodem ze sprzedaży a kosztem własnym sprzedaży. Problem pojawia się w momencie, gdy organizacja stosuje kilka poziomów kosztów i każdy dział używa innej definicji marży. W modelu DAX można jednocześnie utrzymać wiele typów marży, ale trzeba je nazwać i konsekwentnie stosować:

• Marża handlowa – sprzedaż netto minus koszt zakupu towaru,
• Marża logistyczna – marża handlowa pomniejszona o koszty logistyczne (transport, magazynowanie),
• Marża pełna – uwzględnia wszystkie koszty bezpośrednie oraz przypisane koszty ogólne (według przyjętego klucza alokacji),
• Marża po rabatach retrospektywnych – marża powyżej, pomniejszona o bonusy i inne zachęty uzależnione od obrotu.

Jeśli każdej definicji towarzyszy odrębna miara DAX oraz jasny opis biznesowy, użytkownicy raportów nie muszą zgadywać, jak liczona jest marża w konkretnym KPI.

Marża procentowa – pułapki interpretacyjne

Marża procentowa bywa prezentowana jako stosunek marży do przychodu. Problem pojawia się, gdy w różnych raportach stosuje się różne podstawy odniesienia. Najczęstsze warianty to:

• Marża % od sprzedaży netto – Marża / SprzedażNetto,
• Marża % od sprzedaży brutto – Marża / SprzedażBrutto,
• Marża % po bonusach – MarżaPoBonusach / PrzychódSkorygowany.

Jeśli w jednej organizacji funkcjonują różne „szkoły liczenia”, najlepiej zdefiniować kilka odrębnych miar marży procentowej i nadać im jednoznaczne nazwy (np. „Marża% Netto”, „Marża% PoBonusach”), zamiast jednej, której znaczenie zmienia się w zależności od raportu.

Miary bazowe sprzedaży w DAX: fundament pod dalsze KPI

Segregacja miar: ilości, wartości, ceny

Solidny model sprzedażowy w DAX opiera się na kilku kategoriach miar bazowych. Najpierw warto zbudować miary czysto agregujące dane surowe, bez logiki warunkowej, a dopiero na nich kolejne poziomy KPI. Podstawowy podział wygląda zazwyczaj tak:

• Ilości – suma sztuk, kilogramów, opakowań; miary typu SUM nad kolumną Ilość.
• Wartości sprzedaży – sprzedaż netto, brutto, wartość rabatów; najczęściej SUM nad odpowiednimi kolumnami wartościowymi.
• Ceny i stawki – cena jednostkowa, rabat procentowy, koszt jednostkowy; najczęściej liczone jako miary pochodne (wartość / ilość), a nie z kolumn źródłowych.

Jeśli ceny jednostkowe przechowywane są w tabeli faktów, warto i tak utworzyć miary ceny bazujące na sumach ilości i wartości. Chroni to przed błędami przy agregacjach, np. średnią ważoną ceną w przekrojach produkt + klient.

Miary przychodu – od prostego SUM do kontekstu filtra

Podstawowa miara przychodu może mieć postać:

Przychód =
SUM ( FaktySprzedaży[WartośćNetto] )

Taka definicja jest wystarczająca na start, ale szybko pojawia się potrzeba wprowadzenia rozróżnienia na sprzedaż brutto i wartości rabatów. W wielu modelach pomocne są miary:

Sprzedaż Brutto =
SUM ( FaktySprzedaży[WartośćBrutto] )

Rabaty Transakcyjne =
SUM ( FaktySprzedaży[WartośćRabatówTrans] )

Sprzedaż Netto =
[Sprzedaż Brutto] - [Rabaty Transakcyjne]

Użycie miar pochodnych (Sprzedaż Netto liczonej jako różnica innych miar) umożliwia późniejsze rozbudowanie logiki rabatowej bez konieczności zmiany wszystkich raportów. Jeśli w przyszłości dojdą nowe typy rabatów, wystarczy zmienić składnię miary „Rabaty Transakcyjne”, a marża i KPI automatycznie się zaktualizują.

Miary ilości i średnich cen

Miary ilości zwykle są najprostsze, natomiast przy średnich cenach pojawiają się najczęstsze błędy. Zamiast korzystać z kolumny z ceną jednostkową i liczyć jej prostą średnią, lepiej zastosować podejście oparte na ważeniu ilością:

Ilość =
SUM ( FaktySprzedaży[Ilość] )

Średnia Cena Netto =
DIVIDE ( [Sprzedaż Netto], [Ilość] )

Taki sposób liczenia średniej ceny zapewnia poprawną agregację w dowolnym kontekście filtra (produkt, klient, miesiąc). Jeśli cena zostanie wyliczona jako prosta średnia kolumny z ceną jednostkową, raporty na poziomie agregatów mogą pokazywać wartości nieodzwierciedlające realnego miksu ilościowego.

Marża w DAX: od najprostszej miary po złożone scenariusze

Prosta marża handlowa w oparciu o koszt zakupu

Najprostsza definicja marży zakłada, że koszt przypisany jest bezpośrednio do pozycji sprzedaży. W takim układzie można zbudować miary:

Koszt Zakupu =
SUM ( FaktySprzedaży[KosztZakupu] )

Marża Handlowa =
[Sprzedaż Netto] - [Koszt Zakupu]

oraz odpowiadającą jej marżę procentową:

Marża% Handlowa =
DIVIDE ( [Marża Handlowa], [Sprzedaż Netto] )

Ten wariant sprawdza się, gdy koszt jednostkowy jest zapisany przy każdej pozycji sprzedaży albo gdy koszt można bezpośrednio odczytać z wymiaru produktów (np. koszt standardowy obowiązujący w momencie sprzedaży).

Marża na bazie kosztu z wymiaru produktów

Gdy koszt nie znajduje się w tabeli faktów, ale w tabeli Produkty, miary marży muszą odwoływać się do kosztu jednostkowego z wymiaru. Przykładowo:

Koszt Jednostkowy Standard =
AVERAGE ( Produkty[KosztStandardowy] )

Koszt Standardowy =
[Koszt Jednostkowy Standard] * [Ilość]

Marża Standardowa =
[Sprzedaż Netto] - [Koszt Standardowy]

W takim podejściu istotne jest, by koszt w wymiarze produktów był jednoznaczny w danym okresie. Jeśli koszt zmienia się w czasie, lepszym rozwiązaniem jest osobna tabela kosztów z wymiarem czasu (np. Produkt + DataOd + DataDo) i odpowiednie powiązanie z modelem lub wykorzystanie technik wyszukiwania kosztu „obowiązującego” w danym dniu (np. przez tabele mostów lub obliczane kolumny Power Query).

Marża po rabatach retrospektywnych (bonusach)

Gdy w grę wchodzą bonusy roczne lub kwartalne, sama różnica między sprzedażą netto a kosztem zakupu nie oddaje pełnej marży. Rabaty retrospektywne zmniejszają przychód, ale są księgowane z opóźnieniem i często w oddzielnych tabelach. Jednym z praktycznych podejść jest rozliczenie bonusów na poziom okresu i klienta, a następnie rozdzielenie ich proporcjonalnie na sprzedaż w tym okresie. Przykładowo:

• tabela BonusyRoczne zawiera bonus przypisany do klienta i roku,
• miara przypisuje bonus do miesięcy proporcjonalnie do sprzedaży klienta w danym roku.

Konceptualnie miary mogą wyglądać tak (uproszczony schemat):

Bonus Roczny =
SUM ( BonusyRoczne[WartośćBonusów] )

Udział Sprzedaży Klienta w Roku =
DIVIDE ( [Sprzedaż Netto],
         CALCULATE ( [Sprzedaż Netto],
                     ALLEXCEPT ( Klienci, Klienci[IdKlienta],
                                 Kalendarz[Rok] ) )
)

Bonus Alokowany =
[Bonus Roczny] * [Udział Sprzedaży Klienta w Roku]

Marża po Bonusach =
[Marża Handlowa] - [Bonus Alokowany]

Dokładna składnia zależy od struktury tabel, jednak idea pozostaje taka sama: bonus roczny jest rozdzielany w dół, a marża po bonusach pokazuje faktyczną rentowność współpracy z klientem po uwzględnieniu wszystkich rabatów.

Marża po kosztach logistycznych i innych obciążeniach

W organizacjach z rozbudowaną logistyką sam koszt zakupu towaru to za mało. Często trzeba uwzględnić:

Marża przy wielu poziomach kosztów operacyjnych

Rozszerzenie marży o koszty logistyczne, marketingowe czy serwisowe wymaga oddzielenia ich od kosztu zakupu towaru. Praktyczny schemat to rozbicie kosztów na tabele tematyczne, które można elastycznie łączyć z faktem sprzedaży:

• FaktySprzedaży – przychody, ilości, podstawowy koszt zakupu,
• KosztyLogistyki – koszty transportu, magazynowania, opłat dystrybucyjnych,
• KosztyMarketingu – budżety trade marketingu, ekspozycji, akcji promocyjnych,
• KosztySerwisu – gwarancje, reklamacje, obsługa posprzedażowa.

Jeśli każdy typ kosztu jest trzymany w osobnej tabeli, relacje zwykle prowadzą przez te same wymiary (produkt, klient, czas, kanał). Daje to możliwość budowania wariantów marży przez stopniowe odejmowanie kolejnych grup kosztów, np.:

Koszty Logistyki =
SUM ( KosztyLogistyki[Kwota] )

Koszty Marketingu =
SUM ( KosztyMarketingu[Kwota] )

Marża po Logistyce =
[Marża Handlowa] - [Koszty Logistyki]

Marża po Kosztach Operacyjnych =
[Marża po Logistyce] - [Koszty Marketingu]

Kiedy struktura kosztów jest stabilna, da się zdefiniować kaskadę marż (handlowa → po logistyce → po marketingu → pełna) i tym samym ujednolicić analizy w całej organizacji. Jeden dział patrzy na marżę handlową, inny na marżę po kosztach operacyjnych, ale miary w modelu są wspólne.

Marża po kosztach alokowanych (koszty ogólne)

Koszty ogólne, takie jak administracja, IT czy ogólny marketing, rzadko są zapisane per produkt lub klient. Aby wprowadzić je do modelu, trzeba przyjąć regułę alokacji. Popularne są klucze oparte o:

• udział w przychodzie,
• udział w marży handlowej,
• udział ilościowy (sztuki, palety),
• udział w wartości logistycznej (np. waga, objętość).

Jedna z prostszych implementacji to tabela z kosztem ogólnym per okres (np. miesiąc) oraz miara przeliczająca ten koszt na jednostkę obrotu w danym okresie:

Koszty Ogólne Okresu =
SUM ( KosztyOgólne[Kwota] )

Sprzedaż Netto Okresu =
CALCULATE ( [Sprzedaż Netto],
            ALL ( Produkty ),
            ALL ( Klienci ) )

Stawka Kosztów Ogólnych na 1 PLN =
DIVIDE ( [Koszty Ogólne Okresu], [Sprzedaż Netto Okresu] )

Koszty Ogólne Alokowane =
[Sprzedaż Netto] * [Stawka Kosztów Ogólnych na 1 PLN]

Marża Pełna =
[Marża po Kosztach Operacyjnych] - [Koszty Ogólne Alokowane]

Przy takim podejściu każdy produkt czy klient „niesie” ze sobą część kosztów ogólnych proporcjonalną do swojego udziału w sprzedaży. Ten klucz jest uproszczony, ale zazwyczaj wystarczający do oceny rentowności portfela z perspektywy zarządczej.

Konsekwentna hierarchia marż w modelu

Zdefiniowanie spójnej hierarchii marż pozwala uniknąć chaosu w rozmowach biznesowych. Jednym z praktycznych wzorców jest ustalenie poziomów:

1. Marża Handlowa (sprzedaż – koszt zakupu),
2. Marża po Logistyce (1 – koszty logistyczne),
3. Marża po Kosztach Operacyjnych (2 – marketing, serwis),
4. Marża po Bonusach (3 – bonusy, rabaty retrospektywne),
5. Marża Pełna (4 – koszty ogólne).

Każdy poziom ma swoją miarę i ewentualnie wersję procentową. W raportach można je ułożyć w formie „drabinki marżowej” (waterfall), co ułatwia wychwycenie, który poziom kosztów najbardziej obniża rentowność.

Rabaty w modelu DAX: od rabatu transakcyjnego po złożone polityki rabatowe

Podstawowe rodzaje rabatów a struktura tabel

Warunkiem dobrej analizy rabatów jest rozdzielenie ich typów już na etapie modelu danych. W praktyce występują m.in.:

• Rabat liniowy – przypisany do pozycji faktury (kolumna w FaktySprzedaży),
• Rabat nagłówkowy – przypisany do całego dokumentu (faktura, zamówienie),
• Rabat kontraktowy – ustalony w umowie z klientem, rozliczany okresowo,
• Bonus obrotowy – zależny od poziomu obrotu w okresie, często retrospektywny,
• Rabat marketingowy – powiązany z akcjami promocyjnymi lub funduszami trade marketingu.

Przypisanie ich do tabel może wyglądać następująco:

• rabaty liniowe – kolumny w tabeli FaktySprzedaży,
• rabaty nagłówkowe – osobna tabela FaktRabatNagłówek powiązana przez numer dokumentu,
• kontrakty rabatowe i bonusy – tabele FaktBonusy, FaktKontrakty z wymiarami klienta, produktu, czasu.

Takie rozdzielenie ułatwia później budowanie miar typu „rabat transakcyjny”, „rabat kontraktowy” czy „bonus obrotowy”, zamiast jednej niejasnej miary „Rabaty”.

Miary rabatów transakcyjnych i nagłówkowych

Rabaty transakcyjne (na poziomie pozycji faktury) są zazwyczaj najprostsze do zsumowania:

Rabaty Liniowe =
SUM ( FaktySprzedaży[RabatLiniowy] )

Bardziej problematyczne są rabaty nagłówkowe, które trzeba rozdzielić na linie dokumentu. Jeśli rabat nagłówkowy zapisany jest w osobnej tabeli, można obliczyć jego wartość per dokument, a następnie rozdzielić proporcjonalnie do sprzedaży linii:

Rabat Nagłówkowy Dokument =
SUM ( RabatyNagłówkowe[KwotaRabatu] )

Sprzedaż Brutto Dokumentu =
CALCULATE ( [Sprzedaż Brutto],
            ALLEXCEPT ( FaktySprzedaży, FaktySprzedaży[NrDokumentu] ) )

Udział Linii w Dokumencie =
DIVIDE ( [Sprzedaż Brutto], [Sprzedaż Brutto Dokumentu] )

Rabat Nagłówkowy Alokowany =
CALCULATE ( [Rabat Nagłówkowy Dokument],
            VALUES ( FaktySprzedaży[NrDokumentu] ) )
    * [Udział Linii w Dokumencie]

Po takim zdefiniowaniu „Rabat Nagłówkowy Alokowany” zachowuje się jak rabat transakcyjny – można go odejmować od sprzedaży brutto na poziomie linii, klienta, produktu czy kanału sprzedaży.

Rabat kontraktowy i rabat docelowy

Dla kontraktów, w których klient ma zapisany docelowy rabat (np. „średnio 10% w roku”), model powinien umożliwiać porównanie:

• rabatów faktycznie udzielonych (transakcyjnych + nagłówkowych + bonusów),
• rabatów wynikających z umowy (docelowych).

Podstawą jest tabela Kontrakty, np. z kolumnami: Klient, Produkt/GrupaProduktowa, Okres, RabatDocelowy%. Miary mogą wyglądać następująco:

Rabat Docelowy% =
AVERAGE ( Kontrakty[RabatDocelowyProc] )

Rabat Docelowy Wartość =
DIVIDE ( [Sprzedaż Brutto] * [Rabat Docelowy%], 1 )

Rabat Faktyczny =
[Rabaty Liniowe] + [Rabat Nagłówkowy Alokowany] + [Bonus Alokowany]

Odchylenie Rabatu =
[Rabat Faktyczny] - [Rabat Docelowy Wartość]

Pozwala to sprawdzić, czy polityka rabatowa jest przestrzegana. Dla niektórych klientów zestawienie „Rabat Faktyczny%” vs „Rabat Docelowy%” jest jednym z kluczowych KPI handlowych, szczególnie jeśli handlowcy mają ograniczenia na maksymalny rabat.

Rabaty progowe i widełkowe (progi obrotu)

Rabaty oparte o progi obrotu (np. „powyżej określonego obrotu klient dostaje dodatkowy procent rabatu”) można zaimplementować na kilka sposobów, zależnie od poziomu szczegółowości. Jednym z częstszych scenariuszy jest naliczenie rabatu rocznego na koniec okresu, a potem rozdzielenie go w dół, jak w przypadku bonusów. Innym – wyliczanie stawki rabatowej w locie, w zależności od aktualnego obrotu w okresie.

Przykładowa logika dla rabatu rocznego, gdzie progi są zapisane w tabeli ProgRabatu (ObrótMin, ObrótMax, Rabat%):

Obrót Klienta Rok =
CALCULATE ( [Sprzedaż Netto],
            ALLEXCEPT ( Klienci, Klienci[IdKlienta], Kalendarz[Rok] ) )

Rabat Progowy% =
VAR Obrót = [Obrót Klienta Rok]
RETURN
    CALCULATE (
        MAX ( ProgiRabatu[RabatProc] ),
        FILTER (
            ProgiRabatu,
            Obrót >= ProgiRabatu[ObrótMin]
                && Obrót <= ProgiRabatu[ObrótMax]
        )
    )

Rabat Progowy Wartość =
[Obrót Klienta Rok] * [Rabat Progowy%]

Dalej rabat progowy można alokować proporcjonalnie do sprzedaży w roku, podobnie jak bonus roczny. Ważne, by miary posługiwały się jasno opisanym okresem (rok, kwartał) oraz zdefiniowanymi progami w osobnej tabeli, a nie „zaszytymi” w kodzie DAX stałymi wartościami.

Analiza efektywności rabatów

Sam poziom rabatu nie mówi wiele, dopóki nie zestawi się go z marżą. Przydają się miary typu:

• Marża przed rabatami – różnica między sprzedażą brutto a kosztem,
• Marża po rabatach transakcyjnych – marża przed rabatami – rabaty transakcyjne,
• Marża po wszystkich rabatach – wliczając bonusy i rabaty kontraktowe.

Marża przed Rabatami =
[Sprzedaż Brutto] - [Koszt Zakupu]

Marża po Rabatach Transakcyjnych =
[Marża przed Rabatami] - [Rabaty Liniowe] - [Rabat Nagłówkowy Alokowany]

Marża po Wszystkich Rabatach =
[Marża po Rabatach Transakcyjnych] - [Bonus Alokowany]

Dopiero zestawienie „Marża po Wszystkich Rabatach%” z „Rabat Faktyczny%” pokazuje, na ile polityka rabatowa jest opłacalna. W praktyce często okazuje się, że grupa klientów z najwyższymi rabatami ma jednocześnie najniższą rentowność po kosztach pełnych – bez takiego modelu trudno to wykazać.

KPI sprzedażowe w jednym modelu: od prostych celów po zaawansowane wskaźniki

Struktura miar KPI: baza, cel, odchylenie

Większość KPI sprzedażowych można zorganizować w trzech warstwach:

1. miara bazowa – np. sprzedaż netto, marża pełna, rabat faktyczny,
2. cel – wartość planowana, target budżetowy, benchmark,
3. odchylenie – różnica lub procent realizacji celu.

Jeżeli cele trzymane są w osobnych tabelach (np. BudżetSprzedaży, BudżetMarży), warto zadbać o ich kompatybilność z wymiarami głównego modelu (czas, produkt, klient, kanał). Przykładowo:

Sprzedaż Netto =
[Sprzedaż Brutto] - [Rabaty Transakcyjne]

Budżet Sprzedaży =
SUM ( BudżetSprzedaży[Kwota] )

Realizacja Sprzedaży% =
DIVIDE ( [Sprzedaż Netto], [Budżet Sprzedaży] )

Odchylenie Sprzedaży =
[Sprzedaż Netto] - [Budżet Sprzedaży]

Ten sam schemat można zastosować do marży, rabatów, wolumenu czy liczby nowych klientów. Z czasem model może zawierać dziesiątki KPI, ale ich struktura pozostanie spójna.

KPI marżowe: poziom, miks, efektywność rabatowa

KPI marżowe nie muszą ograniczać się do samej wartości marży procentowej. Przydatne wskaźniki to m.in.:

• Marża% vs Cel% – porównanie marży procentowej do docelowej,
• Efekt miksu produktowego – wpływ zmiany struktury asortymentu na marżę,
• Efektywność rabatów – marża utracona na rabatach vs dodatkowy obrót z rabatów.

Efekt miksu można oszacować np. przez porównanie marży, gdy sprzedaż jest ważona strukturą ilościową z poprzedniego okresu. Wymaga to użycia funkcji CALCULATE z innym kontekstem filtrowania oraz miarą ilości.

Efektywność rabatów da się wyrazić przez wskaźnik:

Marża Utracona na Rabatach =
[Marża przed Rabatami] - [Marża po Wszystkich Rabatach]

Efektywność Rabatów =
DIVIDE ( [Marża Utracona na Rabatach], [Sprzedaż Netto] )

W połączeniu z analizą wolumenu przed i po wprowadzeniu promocji handlowych wskaźnik ten wskazuje, gdzie rabaty napędzają obrót, a gdzie tylko „zjadają” marżę.

KPI aktywności klienta i kanału sprzedaży