Raport Studio — kompletny przewodnik

Raport Studio to wbudowane środowisko tworzenia raportów w Veloryn. Pozwala budować raporty SQL na danych systemu i na zewnętrznych bazach danych (np. ERP WAPRO), definiować filtry i parametry dla użytkowników, wzbogacać wynik o dane z innych źródeł, prezentować dane w tabelach, tabelach przestawnych i na wykresach oraz przypinać raporty do kart klientów i produktów.

1Co potrafi Raport Studio

• Raporty SQL na danych Veloryn — piszesz zapytanie SELECT na tabelach systemu (CRM, sprzedaż, magazyn, dokumenty…). Dostęp do tabel kontroluje lista dozwolonych tabel (whitelista), a dane są automatycznie ograniczone do Twojej organizacji.
• Raporty na zewnętrznych bazach — raport może czytać bezpośrednio z zewnętrznego systemu podłączonego w Centrum integracji, np. z bazy MSSQL programu WAPRO albo z zewnętrznego PostgreSQL. Ta sama składnia, te same filtry.
• Wzbogacanie wyniku — mechanizm, którego większość systemów raportowych nie ma: do wyniku głównego zapytania możesz „dosypać" kolumny z innych zapytań, nawet wykonanych na innej bazie. Przykład: sprzedaż liczona w Veloryn + kolumna planu z zewnętrznego arkusza budżetowego + saldo rozrachunków prosto z ERP — wszystko w jednej tabeli. Szczegóły w rozdziale 7.
• Filtry i parametry — definiujesz parametry (daty, listy wyboru, zakresy), a użytkownik dostaje wygodny pasek filtrów z „chipami". Listy wyboru mogą być statyczne albo ładowane własnym SQL-em, z wyszukiwaniem i kaskadowaniem (np. kategoria → podkategoria). Szczegóły w rozdziale 8.
• Tokeny kontekstowe — raport „wie", w jakim kontekście działa: kto go uruchomił, na karcie którego klienta jest otwarty, jaki jest odpowiednik tego klienta w zewnętrznym ERP. Dzięki temu jeden raport przypięty do kart kontrahentów pokazuje każdemu klientowi jego własne dane.
• Prezentacja — tabela z sortowaniem, sumami i formatowaniem, tabela przestawna (pivot) z podsumowaniami, wykresy, formatowanie warunkowe (reguły kolorów, heatmapy).
• Drill-through — kliknięcie w wiersz raportu może otwierać drugi, szczegółowy raport zasilony wartościami klikniętego wiersza.
• Eksporty — CSV, XLSX, PDF i JSON. Bardzo duże eksporty (powyżej 100 000 wierszy) generują się w tle, a link do pliku przychodzi e-mailem.
• Dystrybucja — grupowanie raportów, udostępnianie wybranym grupom użytkowników, przypinanie do kart produktów i kontrahentów.

2Organizacja modułu i uprawnienia

Widoki modułu Raporty

Uprawnienia

3Edytor raportu — przegląd

Edytor otwierasz z Biblioteki (Nowy raport / Edytuj). Ekran składa się z bocznego menu zakładek, obszaru roboczego i panelu wyników na dole.

Zakładki edytora

Pasek górny

• Status raportu — Opublikowany / Wersja robocza. Steruje nim przełącznik Aktywny w zakładce Metadane: raport nieaktywny nie pojawia się użytkownikom na listach.
• Formatuj SQL — porządkuje formatowanie zapytania; tokeny w klamrach {...} pozostają nietknięte.
• Zapisz — wymaga wypełnionego kodu i nazwy raportu (Metadane).
• Usuń — dostępne dla zapisanych raportów niesystemowych; zawsze z potwierdzeniem.
• Skróty klawiszowe: Alt+1 Zapytanie SQL, Alt+2 Kolumny, Ctrl/⌘+Enter Uruchom.

4Zakładka „Zapytanie SQL"

Zasady bezpieczeństwa — co wolno w SQL

• Wyłącznie zapytania SELECT (dozwolone też WITH). Wszelkie modyfikacje danych (INSERT/UPDATE/DELETE/DROP…) są blokowane.
• Tabele podawaj zawsze z nazwą schematu: sales.sales_invoices, nie samo sales_invoices.
• Wolno używać tylko tabel z listy dozwolonych (zakładka „Schemat bazy danych" pokazuje dokładnie to, co jest dostępne). Administrator z uprawnieniem reports.manage_whitelist może tę listę rozszerzać; dla wybranych tabel można też ograniczyć dostęp do konkretnych kolumn — wtedy SELECT * na takiej tabeli jest odrzucany.
• Zakaz średników (jedno zapytanie), komentarze są ignorowane.
• Limit wierszy: jeśli nie podasz LIMIT, system doda domyślny limit 5000 wierszy. Własny limit może wynosić maksymalnie 50 000.
• Limit czasu: zapytanie ma 30 sekund na wykonanie — po przekroczeniu zobaczysz błąd przekroczenia czasu.
• Dane są automatycznie ograniczane do Twojej organizacji (zabezpieczenia na poziomie wierszy bazy danych) — nie musisz, ale warto dla czytelności filtrować po tenant_id = {TENANT_ID}.

Źródło danych (pole „Dataset")

Trzy elementy składni w zapytaniu

1) Parametry raportu — @kod

Każdy parametr zdefiniowany w zakładce „Filtry i parametry" wstawiasz do SQL jako @kod_parametru. Wartość podana przez użytkownika jest podstawiana bezpiecznie (bind, nie sklejanie tekstu) — nie da się przez filtr „wstrzyknąć" złośliwego SQL-a.

SELECT numer, data_wystawienia, wartosc_netto
FROM sales.sales_invoices
WHERE EXTRACT(YEAR FROM data_wystawienia) = @rok
  AND EXTRACT(MONTH FROM data_wystawienia) = @miesiac

2) Tokeny kontekstowe — {TOKEN}

Tokeny w klamrach są wypełniane automatycznie przez system na podstawie kontekstu uruchomienia. Paleta „Tokeny kontekstowe" nad edytorem wstawia je jednym kliknięciem.

3) Klauzule opcjonalne — [[ ... ]]

Fragment SQL ujęty w podwójne nawiasy kwadratowe jest usuwany z zapytania w całości, jeśli którykolwiek użyty w nim parametr lub token nie ma wartości. Jeśli wszystkie mają wartości — nawiasy znikają, a treść zostaje. To podstawowy wzorzec filtrów niewymaganych:

SELECT p.nazwa, SUM(f.wartosc_netto) AS sprzedaz
FROM sales.invoice_items f
JOIN products.products p ON p.id = f.product_id
WHERE f.data BETWEEN @zakres
  [[ AND p.category_id = @kategoria ]]
  [[ AND f.magazyn = @magazyn ]]
GROUP BY p.nazwa

Użytkownik, który nie ustawi filtra „Kategoria", dostanie wszystkie kategorie — warunek po prostu zniknie z zapytania. Bez [[ ]] pusty parametr niewymagany zostawiłby w SQL nieprawidłowy warunek.

Uruchamianie i konsola

• Uruchom (Ctrl/⌘+Enter) wykonuje zapytanie i pokazuje wynik w panelu na dole. Przycisk jest nieaktywny, dopóki nie uzupełnisz wymaganych parametrów/tokenów testowych.
• Konsola (zakładka panelu wyników) zapisuje historię uruchomień z czasami wykonania i błędami (ostatnie 50 wpisów).
• Po udanym podglądzie system potrafi zaproponować kolumny (zakładka Kolumny) i sugestie filtrów (zakładka Filtry i parametry) na podstawie typów danych wyniku.
• Zapisz jako szablon — odkłada bieżący SQL do biblioteki szablonów, z której można korzystać przy tworzeniu kolejnych raportów.

5Zakładka „Kolumny"

Konfigurator mapuje kolumny zwracane przez SQL na kolumny widoczne dla użytkownika. Najszybsza ścieżka: uruchom podgląd zapytania, a system sam wstawi wykryte kolumny — potem tylko je dostrajasz.

6Zakładka „Konfiguracja" (JSON)

Zaawansowana konfiguracja domyślnego widoku raportu w formacie JSON — dla administratorów. Edytor waliduje składnię na bieżąco; „Przywróć" cofa niezapisane zmiany.

Formatowanie warunkowe

Kolorowanie komórek definiuje się w definicji kolumny raportu — każda kolumna może mieć pole conditional_formats: listę reguł sprawdzanych po kolei (wygrywa pierwsza pasująca). Formatowanie nie ma jeszcze osobnego formularza w tabeli „Kolumny" — konfiguruje je administrator w JSON definicji kolumn.

Tryb reguł

W warunku #value to wartość bieżącej komórki, @pole — wartość innej kolumny tego samego wiersza; warunki łączysz AND/OR. Dostępne właściwości stylu: text_color (kolor tekstu), background_color (tło; kolor tekstu dobierze się automatycznie dla kontrastu), font_weight (np. "bold").

{
  "field": "marza_procent",
  "label": "Marża %",
  "conditional_formats": [
    { "condition": "#value < 0",                   "text_color": "#dc2626", "font_weight": "bold" },
    { "condition": "#value >= 0 AND #value < 10", "background_color": "#fef9c3" },
    { "condition": "#value >= 10",                 "text_color": "#16a34a" }
  ]
}

Skala kolorów (heatmapa)

{
  "field": "sprzedaz",
  "conditional_formats": [
    { "scale": { "from": "#dcfce7", "to": "#166534" } }
  ]
}

Komórki są cieniowane proporcjonalnie od wartości najmniejszej (from) do największej (to) w kolumnie — szybki przegląd „gdzie jest najwięcej/najmniej". Pominięte kolory mają domyślne wartości zielony → czerwony; opcja "invert": true odwraca kierunek gradientu (przydatne, gdy „mniej = lepiej").

7Zakładka „Wzbogacanie" — łączenie danych z wielu źródeł

Do czego to służy

Wzbogacanie pozwala dołożyć do wyniku głównego zapytania dodatkowe kolumny z innych zapytań — także wykonanych na zupełnie innej bazie danych. Główne zapytanie i źródło wzbogacania są wykonywane osobno, a system łączy je po wskazanych kluczach (jak VLOOKUP/WYSZUKAJ.PIONOWO w Excelu, tylko automatycznie i na żywo).

Typowe zastosowania:

• Plan vs wykonanie — sprzedaż liczona w Veloryn + kolumna planu z tabeli budżetowej;
• dane z ERP obok danych Veloryn — np. saldo rozrachunków lub limit kredytowy prosto z WAPRO przy każdym kontrahencie;
• wynik dwóch systemów w jednej tabeli — porównanie stanów magazynowych Veloryn i systemu zewnętrznego;
• drogie agregaty liczone osobno — zamiast komplikować główne zapytanie kolejnymi JOIN-ami, liczysz agregat w osobnym źródle.

Jak to działa — krok po kroku

1. System wykonuje główne zapytanie raportu (z filtrami użytkownika).
2. Dla każdego źródła wzbogacania wykonuje zapytanie źródła — na bazie Veloryn albo przez połączenie integracyjne. Tokeny ({TENANT_ID}, {EXTID}…) działają też tutaj.
3. Buduje z wyniku źródła mapę wyszukiwania po kluczach łączenia.
4. Do każdego wiersza głównego wyniku dokleja kolumny wskazane w „Kolumny do dosypania". Nazwa doklejonej kolumny to identyfikator_źródła + „_" + nazwa_kolumny (np. źródło plan i kolumna plan_value → kolumna wyniku plan_plan_value).

Pola konfiguracji źródła

Identyfikator źródła

Krótka techniczna nazwa źródła (małe litery, cyfry, podkreślenia; zaczyna się literą; maks. 32 znaki), np. plan, erp_saldo. Staje się prefiksem doklejanych kolumn — pod polem edytor pokazuje podgląd: „Prefix kolumn: plan_<column>". Identyfikatory muszą być unikalne w obrębie raportu.

Typ źródła

Natywna baza PG — zapytanie źródła wykonuje się na bazie Veloryn, z pełną walidacją bezpieczeństwa i whitelistą tabel (jak główne zapytanie).
Połączenie integracyjne — zapytanie wykonuje się na zewnętrznej bazie z Centrum integracji (WAPRO/MSSQL — dialekt T-SQL, lub zewnętrzny PostgreSQL). Wybierasz konkretne połączenie z listy. Obowiązuje tryb tylko-do-odczytu i limit czasu 30 s.

Zapytanie

SQL zwracający kolumny kluczy łączenia oraz kolumny do dosypania. W zapytaniu źródła działają wyłącznie tokeny kontekstowe w klamrach ({TENANT_ID}, {EXTID}, {TODAY}…). Parametry raportu @kod NIE działają we wzbogacaniu — filtry użytkownika ograniczają tylko główne zapytanie; zawężenie źródła zapisz na sztywno w jego SQL-u.

Klucze łączenia (Pole główne / Pole źródła)

Pary kolumn, po których wiersze są dopasowywane: Pole główne = alias kolumny w wyniku głównego zapytania, Pole źródła = alias kolumny w wyniku źródła. Kilka par działa jak warunek ŁĄCZNY (wszystkie muszą się zgadzać) — np. id_kategorii + rok + miesiac.

Zasady dopasowania:

• porównanie nie rozróżnia wielkości liter;
• wiersz z pustą wartością (NULL) w którymkolwiek kluczu nie zostanie dopasowany;
• gdy źródło ma kilka wierszy z tym samym kluczem, użyty zostanie pierwszy — zadbaj, by klucz był w źródle unikalny (najlepiej przez GROUP BY).

Kolumny do dosypania

Lista kolumn źródła (jedna na linię), które mają zostać doklejone do wyniku. Każda pojawi się w raporcie z prefiksem identyfikatora źródła. Jeśli tak powstała nazwa kolidowałaby z kolumną głównego wyniku, system użyje podwójnego podkreślenia (identyfikator__kolumna) i zgłosi ostrzeżenie. Doklejone kolumny konfigurujesz potem normalnie w zakładce „Kolumny" (etykieta, format, agregacja).

Tryb łączenia

LEFT (zachowaj wszystkie wiersze) — domyślny: wiersze głównego wyniku bez dopasowania w źródle zostają, a doklejone kolumny mają wartość pustą. Wybieraj do danych uzupełniających (plan, saldo, atrybut).
INNER (odrzuć niesparowane) — wiersze bez dopasowania są usuwane z wyniku. Wybieraj, gdy raport ma pokazywać wyłącznie wiersze mające odpowiednik w źródle (np. „tylko produkty objęte planem"). Jeśli tryb INNER odrzuci ponad połowę wierszy, edytor pokaże ostrzeżenie — zwykle oznacza to błąd w kluczach.

8Zakładka „Filtry i parametry"

Parametry to pomost między użytkownikiem a zapytaniem SQL: definicja parametru staje się kontrolką filtra w przeglądarce raportu, a jego wartość trafia do SQL w miejsce @kod. Panel ma układ dwóch kolumn: po lewej lista parametrów z kolejnością, po prawej szczegóły zaznaczonego.

Pola parametru

Kod parametru

Techniczny identyfikator, np. rok, data_od. Dokładnie tego kodu używasz w SQL jako @rok, @data_od. Małe litery, bez spacji i polskich znaków.

Nazwa

Etykieta widoczna dla użytkownika na chipie filtra i w formularzu parametrów (np. „Miesiąc", „Data od").

Typ

Decyduje o kontrolce, jaką zobaczy użytkownik, o sposobie sprawdzenia wartości i o tym, jak pisać warunek w SQL:

Wartość domyślna

Wartość, z jaką raport uruchamia się przed zmianą filtrów przez użytkownika. Dla typów Miesiąc / Drzewo miesięcy możesz wpisać token {CURRENT_MONTH} — filtr zawsze wystartuje z bieżącym miesiącem (token działa właśnie w tym polu; w treści SQL go nie używaj). Dla list — wpisz wartość (nie etykietę) opcji.

Wymagany

Użytkownik musi podać wartość przed uruchomieniem raportu — bez niej raport się nie wykona. Używaj dla parametrów, bez których wynik nie ma sensu (np. rok w raporcie rocznym) albo byłby zbyt duży. Parametry niewymagane obejmuj w SQL klauzulą [[ ... ]] (patrz rozdział 4), inaczej pusty filtr zepsuje zapytanie.

Widoczny jako chip w FilterBar

Steruje miejscem filtra na pasku w przeglądarce raportu: włączony = chip widoczny od razu obok wymaganych; wyłączony = filtr schowany pod przyciskiem + Filtr. Przypinaj 2–4 najczęściej używane filtry — reszta niech nie zabiera miejsca. Parametry wymagane są widoczne zawsze, niezależnie od tego ustawienia.

Opis

Tekst pomocniczy wyświetlany użytkownikowi przy filtrze — napisz, co filtr obejmuje (np. „Filtr miesiąca wystawienia faktury", żeby nikt nie mylił z miesiącem płatności).

Zależy od parametrów (kaskadowanie)

Zaznaczasz, od których innych parametrów zależą opcje tego parametru. Gdy użytkownik zmieni parametr nadrzędny, lista opcji zależnego zostanie przeliczona — a w zapytaniu opcji (patrz „Źródło opcji: SQL" niżej) możesz użyć wartości nadrzędnego jako @kod_nadrzędnego. Klasyczny przykład: parametr podkategoria zależy od kategoria i pokazuje tylko podkategorie wybranej kategorii.

Kolejność

Strzałkami na liście ustalasz kolejność filtrów na pasku w przeglądarce raportu.

Źródło opcji (dla typów Lista wyboru / Lista wielokrotna)

Statyczne

Stała lista opcji wpisana ręcznie — jedna opcja na linię, w formacie wartość|Etykieta (wartość, pionowa kreska, etykieta widoczna dla użytkownika):

1|Styczeń
2|Luty
3|Marzec
4|Kwiecień
5|Maj
6|Czerwiec
7|Lipiec
8|Sierpień
9|Wrzesień
10|Październik
11|Listopad
12|Grudzień

Do SQL trafia wartość (tu: numer miesiąca), użytkownik widzi etykietę (nazwę miesiąca). Używaj dla krótkich, stałych słowników: statusy, miesiące, typy dokumentów.

SQL

Opcje ładowane własnym zapytaniem — lista jest zawsze aktualna (np. słownik kategorii produktów, lista magazynów, handlowców). Zasady:

• Zapytanie powinno zwracać kolumny value (wartość do SQL) i label (etykieta). Zamiast label honorowana jest też kolumna name; gdy nie nazwiesz kolumn, pierwsza = wartość, druga = etykieta.
• Lista jest ograniczona do 100 opcji — dla dłuższych słowników zaprojektuj zapytanie pod wyszukiwarkę (punkt niżej).
• Kontrolka listy ma wyszukiwarkę: fraza wpisana przez użytkownika jest dostępna w zapytaniu jako @SEARCH. Zalecany wzorzec (działa też przy pustej frazie):

SELECT id AS value, nazwa AS label
FROM products.product_categories
WHERE tenant_id = {TENANT_ID}
  AND nazwa ILIKE '%' || coalesce((@SEARCH)::text, '') || '%'
ORDER BY nazwa

• Kaskadowanie: w zapytaniu opcji możesz używać wartości innych parametrów. Przykład dla parametru podkategoria zależnego od kategoria:

SELECT id AS value, nazwa AS label
FROM products.product_categories
WHERE parent_id = @kategoria
ORDER BY nazwa

• Klauzule [[ ... ]] działają także tutaj — możesz zwracać pełną listę, dopóki parametr nadrzędny nie jest wybrany: WHERE tenant_id = {TENANT_ID} [[ AND parent_id = @kategoria ]].

API

Opcje dostarczane przez wewnętrzne źródło API systemu — konfigurowane przez administratora systemu, nie w edytorze raportu. Spotykane w raportach systemowych.

Sugestie filtrów

Po uruchomieniu podglądu zapisanego raportu panel Sugestie filtrów analizuje kolumny wyniku i proponuje parametry z procentem pewności (np. kolumna dat → sugestia zakresu dat, kolumna numeryczna → filtr progu, kolumna o małej liczbie unikalnych wartości → lista wyboru). Przycisk + tworzy gotowy parametr z sensownym typem — pozostaje dopisać warunek @kod w SQL i ewentualnie skonfigurować źródło opcji.

9Zakładka „Metadane"

10Zakładka „Schemat bazy danych"

• Pokazuje wyłącznie tabele dozwolone dla raportów (whitelistę) — jeśli tabeli tu nie ma, zapytanie z jej użyciem zostanie odrzucone. O rozszerzenie listy poproś administratora z uprawnieniem reports.manage_whitelist.
• Drzewo: schemat → tabela → kolumny, z typami danych oraz oznaczeniem kluczy głównych/obcych. Znacznik RLS przy tabeli oznacza, że dane są automatycznie filtrowane per organizacja.
• Kliknięcie tabeli lub kolumny wstawia jej pełną nazwę do edytora SQL — najszybszy sposób na poprawne nazwy ze schematem.
• Wyszukiwarka filtruje drzewo po nazwach tabel i kolumn.
• Dla raportów na połączeniu integracyjnym przeglądarka pokazuje schemat bazy zewnętrznej. Po zapisaniu raportu wybór źródła jest zablokowany.

11Wyniki: tabela, pivot, wykres, eksport, drill-through

Tabela

• Sortowanie po kolumnach (tych z włączonym „Sortowanie"), realizowane po stronie serwera — działa na całym wyniku, nie tylko widocznej stronie.
• Paginacja serwerowa (50/100 wierszy na stronę) — duże raporty nie obciążają przeglądarki.
• Wiersz sum — dla kolumn z ustawioną agregacją; kwoty sumowane osobno per waluta, jeśli wskazano „Pole waluty".
• Użytkownik może spersonalizować widoczność i kolejność kolumn — ustawienia zapisują się per użytkownik i wracają przy następnym otwarciu.

Tabela przestawna (pivot)

Dla raportów w trybie pivot: agregacje (SUM/COUNT/AVG/MIN/MAX) z sumami częściowymi wierszy i kolumn oraz sumą całkowitą, liczone po stronie bazy — szybkie także na dużych danych. Ograniczenie: pole osadzone na osi kolumn może mieć maksymalnie 50 różnych wartości (czytelność tabeli); przy przekroczeniu wybierz pole o mniejszej liczbie wartości lub zawęź filtrem.

Wykres

Zakładka „Wykres" buduje wizualizację na podstawie ról kolumn (wymiar = oś, miara = wartość). Kliknięcie elementu wykresu może uruchamiać drill-through, tak jak w tabeli.

Eksport

Eksport powyżej 100 000 wierszy wykonuje się w tle: nie czekasz przy otwartym oknie — po wygenerowaniu dostaniesz e-mail z linkiem do pobrania pliku (link ważny 24 godziny).

Drill-through — raport szczegółowy po kliknięciu

Raport może mieć drugie zapytanie — drill SQL — uruchamiane po kliknięciu wiersza/wartości w kolumnie z włączonym „Drill". W zapytaniu szczegółowym odwołujesz się do wartości klikniętego wiersza składnią @ROW.nazwa_kolumny:

-- raport główny: sprzedaż wg kontrahentów (kolumny: kontrahent_id, kontrahent, obrot)
-- drill SQL: faktury klikniętego kontrahenta
SELECT numer, data_wystawienia, wartosc_netto
FROM sales.sales_invoices
WHERE contractor_id = @ROW.kontrahent_id
ORDER BY data_wystawienia DESC

Wartości wiersza są podstawiane bezpiecznie (bind). Drill-through działa w widoku tabeli (siatki).

12Przeglądarka raportu i pasek filtrów

• Pasek filtrów (FilterBar) — parametry raportu jako chipy: wymagane oraz oznaczone „Widoczny jako chip" od razu, pozostałe pod przyciskiem + Filtr.
• Filtry stosują się automatycznie chwilę po zmianie wartości — bez osobnego przycisku „Zastosuj".
• Wartości filtrów trafiają do adresu URL — skopiowany link otwiera raport z tymi samymi filtrami. Idealne do udostępniania: „zobacz sprzedaż za czerwiec" to po prostu link.
• Kontrolki są dopasowane do typu parametru: kalendarze, zakres dat z presetami, listy z wyszukiwarką (ładowaną na żywo z zapytania opcji), drzewo miesięcy itd.
• Listy zależne (kaskadowe) przeliczają się po zmianie parametru nadrzędnego.
• Raport otwarty z karty kontrahenta/produktu dostaje automatycznie kontekst tej encji — tokeny {CONTID}/{CUSTID}/{EXTID} wypełniają się same (patrz rozdział 13).

13Przypinanie raportów do encji

Raport można przypiąć do kart encji — obecnie do kart produktów i kontrahentów. W oknie przypinania (Biblioteka → akcja Przypnij, wymaga reports.manage) wskazujesz:

• typ encji — produkt lub kontrahent,
• parametr raportu, który ma otrzymać identyfikator encji (np. parametr produkt_id).

Od tej chwili na karcie każdej encji danego typu pojawia się menu „Raporty" z przypiętym raportem. Otwarcie uruchamia raport w oknie z automatycznie wstrzykniętym ID bieżącej encji — jeden raport „Sprzedaż produktu po miesiącach" obsłuży w ten sposób każdy produkt w systemie. W raportach kontrahenckich analogicznie działają tokeny {CONTID}/{EXTID}/{WAPRO_CUSTID} — także z danymi z zewnętrznego ERP.

14Udostępnianie i kontrola dostępu

• Okno Dostęp (Biblioteka): zaznaczasz grupy użytkowników, które mają widzieć raport.
• Brak zaznaczonych grup = raport widzą wszyscy użytkownicy z uprawnieniem reports.view. Zaznaczenie choć jednej grupy zawęża dostęp wyłącznie do jej członków.
• Ograniczenie obowiązuje wszędzie: na listach, w przeglądarce, przy uruchamianiu — nie da się obejść znajomością adresu raportu.
• Administrator z reports.manage widzi wszystkie raporty niezależnie od grup.
• Niezależnie od dostępu do raportu działają zabezpieczenia danych: zapytania wykonują się na koncie o ograniczonych uprawnieniach, z automatycznym filtrowaniem per organizacja.

15Rozwiązywanie problemów

16Dobre praktyki

• Zaczynaj od SQL, kończ na filtrach. Najpierw poprawny wynik na sztywnych wartościach, potem podmiana na @parametry, na końcu kosmetyka kolumn.
• Parametr wymagany tam, gdzie chroni wydajność. Raport „wszystko od początku świata" to timeout — rok lub zakres dat jako pole wymagane rozwiązuje problem u źródła.
• Filtry niewymagane zawsze w [[ ... ]]. To najczęstszy błąd początkujących autorów raportów.
• Wzbogacanie zamiast rozbudowanych JOIN-ów, gdy dane pochodzą z innej bazy albo drogiego agregatu. Główne zapytanie zostaje proste i szybkie.
• Klucze łączenia agreguj po stronie źródła (GROUP BY do poziomu kluczy) — unikniesz duplikatów i przypadkowych dopasowań.
• Kolumny techniczne ukrywaj, nie usuwaj. ID potrzebne do drill-through i wzbogacania zostają w zapytaniu z wyłączoną widocznością.
• Opisuj filtry. Pole „Opis" rozstrzyga wątpliwości typu „data wystawienia czy sprzedaży?" zanim ktoś zdąży zapytać.
• Publikuj po testach. Buduj przy wyłączonym „Aktywny", sprawdź na danych brzegowych (pusty wynik, brak dopasowań wzbogacania), dopiero wtedy włącz.
• Udostępniaj przez grupy, gdy raport zawiera dane wrażliwe (marże, wynagrodzenia) — pamiętaj, że brak przypisanych grup oznacza dostęp dla wszystkich z prawem do raportów.