Czy sprzedawcy powinni outsourcować pan-europejski fulfillment?
24 maja 2026
Co kara DSA dla Temu oznacza dla obowiązków bezpieczeństwa produktów sprzedawców cross-border w UE
30 maja 2026
FLEX. Logistics
Świadczymy usługi logistyczne dla sprzedawców internetowych w Europie: przygotowanie do Amazon FBA, przetwarzanie zamówień usunięcia FBA, przekazywanie do Centrów Realizacji Zamówień — zarówno przesyłek FBA, jak i Vendor.
Program Prac Komisji Europejskiej na 2026 rok w zakresie VAT w erze cyfrowej (ViDA) nie jest odległą dyskusją polityczną. Jest to sekwencyjny mandat techniczny z terminem pierwszej fali w styczniu 2027 r., który bezpośrednio wpływa na sposób, w jaki transgraniczni sprzedawcy z UE rejestrują się, raportują i przemieszczają zapasy między państwami członkowskimi. Dla marek prowadzących wielonarodowe sieci dystrybucji pytanie nie brzmi już, czy się dostosować, lecz które obowiązki pojawią się jako pierwsze, kto w organizacji jest za nie odpowiedzialny oraz czy obecny stos technologiczny VAT jest w stanie wygenerować pola danych wymagane przez nową architekturę. Niniejszy artykuł analizuje sześć aktów wykonawczych, mapuje wdrożenie etapowe od 2027 do 2030 r. oraz identyfikuje operacyjne punkty kontrolne, w których rozdrobnione starsze systemy najprawdopodobniej zawiodą pod presją nadchodzącego scentralizowanego modelu raportowania.
Sześć aktów wykonawczych: analiza Programu Prac na 2026 rok
Program Prac na 2026 rok strukturyzuje transformację ViDA w sześć odrębnych aktów wykonawczych, z których każdy dotyczy konkretnej warstwy istniejącej infrastruktury VAT. Pierwszy akt dotyczy standaryzacji technicznej pól danych wymaganych dla transakcji wewnątrzwspólnotowych, ustanawiając minimalny zestaw danych, który musi zawierać każde zgłoszenie raportowania cyfrowego. Drugi akt reguluje przebudowę Systemu Wymiany Informacji o VAT (VIES), przenosząc go z modelu okresowego zapytania wsadowego w kierunku architektury weryfikacji zbliżonej do czasu rzeczywistego. Trzeci akt definiuje rozszerzone moduły Unii One Stop Shop (OSS), w tym nowe kategorie dla określonych dostaw mediów, które wchodzą w życie 1 stycznia 2027 r. Czwarty i piąty akt stanowią podstawę prawną i techniczną dla obowiązkowej Jednolitej Rejestracji VAT (SVR) oraz mechanizmu Transferu Własnych Towarów (TOOG), oba zaplanowane na lipiec 2028 r. Szósty akt obejmuje przepisy przejściowe i okna derogacji dla państw członkowskich. Każdy akt tworzy odrębną warstwę zgodności, a sprzedawcy, którzy traktują je jako jedną niezróżnicowaną reformę, błędnie rozlokują wysiłki przygotowawcze i przegapią logikę sekwencjonowania.
Wymagania dotyczące raportowania cyfrowego: co należy rejestrować
Wymagania Raportowania Cyfrowego (DRR) w ramach ViDA nakładają obowiązek, aby dane na poziomie transakcji były ustrukturyzowane, opatrzone znacznikiem czasu i możliwe do przesłania w standardowym formacie w momencie dostawy. Dla sprzedawców transgranicznych oznacza to, że każda transakcja B2B wewnątrzwspólnotowa musi zawierać określony zestaw pól danych: numer VAT dostawcy, numer VAT klienta, datę faktury, kwotę opodatkowaną, zastosowaną stawkę VAT oraz referencję transakcji, którą można dopasować do rekordu przychodzącego nabywcy. Kluczowym punktem kontroli operacyjnej jest to, że dane te muszą istnieć w czystym, możliwym do wyodrębnienia stanie przed zgłoszeniem transakcji — a nie być rekonstruowane po fakcie z logów systemu zarządzania magazynem czy manifestów przewoźnika. Sprzedawcy korzystający z systemów ERP, które agregują dane transakcyjne miesięcznie zamiast rejestrować je na poziomie pozycji, napotkają strukturalną niezgodność z architekturą DRR. Warstwa danych musi być wbudowana w przepływ pracy od zamówienia do faktury, a nie dodawana na etapie raportowania.
Co się psuje, gdy brakuje warstwy danych
Gdy stos technologiczny VAT sprzedawcy nie jest w stanie na żądanie wygenerować czystych danych transakcyjnych na poziomie pól, konsekwencje w nowym modelu DRR nie ograniczają się do opóźnionego zgłoszenia. Przebudowany VIES będzie krzyżowo porównywał zgłoszenia dostawcy z rekordami po stronie nabywcy w czasie zbliżonym do rzeczywistego. Niezgodność — spowodowana brakującym numerem VAT, nieprawidłową datą faktury lub kwotą opodatkowaną, która nie zgadza się z zadeklarowanym przez nabywcę — uruchamia automatyczną flagę niezgodności. W obecnym systemie okresowym takie niezgodności są często rozwiązywane cicho podczas rocznego uzgodnienia. W nadchodzącej architekturze oznaczona niezgodność może zawiesić status zwrotu VAT dla transakcji do czasu poprawienia błędu i ponownego zgłoszenia. Dla sprzedawców przemieszczających duże wolumeny zapasów B2B przez wiele granic UE, wzorzec flag niezgodności nie jest uciążliwością zgodności. Jest to ryzyko przepływu gotówki, które kumuluje się przy każdej dotkniętej transakcji, dopóki źródło danych nie zostanie naprawione na poziomie systemu.
Przebudowa VIES: przygotowanie do audytu w czasie rzeczywistym
Techniczna przebudowa VIES to zmiana infrastrukturalna, która sprawia, że reszta ViDA staje się egzekwowalna. W obecnej formie VIES umożliwia weryfikację numeru VAT na podstawie zapytania, ale nie porównuje krzyżowo danych transakcyjnych między państwami członkowskimi w czasie rzeczywistym. Przebudowany system będzie przyjmował ustrukturyzowane rekordy transakcji z obu stron dostawy wewnątrzwspólnotowej i automatycznie flagował asymetrie. Dla sprzedawców fundamentalnie zmienia to model ekspozycji na audyt. Wcześniej audyt VAT był procesem okresowym, wymagającym wielu dokumentów, uruchamianym przez określony sygnał ryzyka. W nowej architekturze VIES każda transakcja wewnątrzwspólnotowa jest skutecznie wstępnie audytowana na poziomie warstwy danych, zanim jakikolwiek inspektor ludzki się zaangażuje. Sprzedawcy, którzy polegali na ręcznym uzgadnianiu VAT lub oprogramowaniu VAT dla jednego kraju, odkryją, że te narzędzia nie generują ustrukturyzowanego wyjścia, którego oczekuje nowy system. Praktycznym krokiem przygotowawczym jest analiza luk w obecnych polach danych faktur w stosunku do standardowego zestawu DRR, przeprowadzona na długo przed terminem pierwszej fali w 2027 r.
Rozszerzenie OSS i ścieżka Jednolitej Rejestracji VAT
Ramy One Stop Shop są znacznie rozszerzane w ramach ViDA, a zmiany z stycznia 2027 r. wprowadzają nowe moduły Unii OSS, które obejmują kategorie dostaw niekwalifikujące się wcześniej do scentralizowanego raportowania. Sprzedawcy e-commerce już korzystający z OSS w przypadku sprzedaży na odległość B2C, rozszerzony zakres oznacza konieczność sprawdzenia, czy nowo kwalifikujące się typy dostaw w ich asortymencie mogą być skonsolidowane w istniejącej rejestracji OSS, czy wymagają oddzielnego wyboru modułu. Znaczącą zmianą strukturalną jest wprowadzenie w lipcu 2028 r. obowiązkowej Jednolitej Rejestracji VAT (SVR), która zastąpi obecny wymóg posiadania lokalnych rejestracji VAT w każdym państwie członkowskim, w którym sprzedawca posiada zapasy. W ramach SVR sprzedawca przemieszczający zapasy do polskiego centrum realizacji, niemieckiego hubu dystrybucyjnego i francuskiego obiektu przetwarzania zwrotów będzie zarządzał tymi obowiązkami poprzez jeden punkt rejestracyjny, a nie trzy oddzielne zgłoszenia krajowe. Mechanizm Transferu Własnych Towarów (TOOG), uruchamiany wraz z SVR, zajmie się traktowaniem VAT transgranicznych przemieszczeń zapasów między własnymi magazynami sprzedawcy — typem transakcji, który obecnie wymaga starannego ręcznego traktowania w każdej jurysdykcji. Dla sprzedawców prowadzących strategię dystrybucji pan-europejskiej w wielu węzłach magazynowych, SVR i TOOG razem stanowią najważniejszą operacyjnie zmianę w całym pakiecie ViDA.
Co należy zweryfikować przed styczniem 2027 r.
Pierwszym praktycznym krokiem jest ustrukturyzowana weryfikacja obecnego śladu rejestracji VAT w odniesieniu do nadchodzącego zakresu modułów OSS. Sprzedawcy powinni potwierdzić, które typy dostaw w ich unijnym katalogu produktów są nowo kwalifikowane do raportowania w ramach Unii OSS od stycznia 2027 r. i czy obecne zgłoszenie OSS obejmuje te kategorie, czy domyślnie je wyklucza. Druga warstwa weryfikacji to architektura danych faktur: czy obecny system ERP lub zarządzania zamówieniami rejestruje standardowe pola DRR na poziomie transakcji, czy agreguje dane w sposób, który wymagałby ręcznego wyodrębniania i przeformatowania przed zgłoszeniem? Trzecie sprawdzenie to spójność numerów EORI i VAT we wszystkich aktywnych korytarzach handlowych — każda niezgodność między identyfikatorami używanymi w deklaracjach celnych przywozowych a tymi używanymi w zgłoszeniach OSS tworzy lukę uzgodnieniową, którą ujawni nowe krzyżowe referencjonowanie VIES. Sprzedawcy korzystający z usług odprawy celnej UE powinni potwierdzić, że ich agent celny rejestruje i przesyła te same identyfikatory VAT, które są używane na koncie OSS.
Gdzie rozdrobnione stosy VAT zawodzą w ramach SVR
Najczęstszym błędnym założeniem wśród sprzedawców działających w wielu krajach jest to, że termin SVR w lipcu 2028 r. daje im wystarczająco dużo czasu na odłożenie przygotowań. W praktyce przejście na SVR wymaga od sprzedawców zmapowania każdej obecnej lokalnej rejestracji VAT na nową strukturę pojedynczej rejestracji, migracji historycznych danych zgłoszeniowych oraz zapewnienia, że ich systemy zarządzania magazynem i routingu zamówień będą w stanie prawidłowo przypisać przemieszczenia zapasów do ram TOOG od pierwszego dnia przejścia. Sprzedawcy, którzy rozbudowywali swoją obecność w UE stopniowo — dodając niemiecki magazyn, potem francuski hub zwrotów, a następnie polski węzeł realizacji — często mają rejestracje VAT zarządzane przez różnych lokalnych doradców korzystających z różnych wyjść oprogramowania. Skonsolidowanie ich w jedno spójne zgłoszenie SVR wymaga prac standaryzacji danych, których nie da się wykonać w ostatnich tygodniach przed terminem. Tryb awarii nie polega na przekroczeniu daty zgłoszenia. Polega na dotarciu do przejścia SVR z niezgodnymi formatami danych w trzech jurysdykcjach i bez ujednoliconego rejestru historycznych przemieszczeń zapasów wewnątrzwspólnotowych.
Mapa odpowiedzialności: kto jest właścicielem każdego obowiązku ViDA
Praktyczna mapa odpowiedzialności za zgodność z ViDA rozdziela obowiązki według funkcji, zamiast traktować je jako pojedyncze zadanie działu podatkowego. Architektura danych DRR należy do operatora systemu ERP lub zarządzania zamówieniami — zazwyczaj zespołu systemów IT lub finansów — ponieważ ustrukturyzowane pola danych muszą być wbudowane w warstwę rejestrowania transakcji, a nie dodawane downstream. Obowiązek składania zgłoszeń OSS należy do funkcji zgodności VAT, niezależnie od tego, czy jest realizowana wewnętrznie, czy zlecana doradcy podatkowemu, ale ta funkcja zależy od czystych danych wejściowych z warstwy systemów. Ramy TOOG, po uruchomieniu, będą wymagały od zespołu operacji logistycznych oznaczania każdego transgranicznego przemieszczenia zapasów między własnymi węzłami magazynowymi jako odrębnego typu transakcji z własnym traktowaniem VAT. Jeśli system zarządzania magazynem nie rozróżnia przesyłki na zamówienie klienta od transferu zapasów między magazynami, rekord TOOG będzie niekompletny. Dla sprzedawców korzystających z zewnętrznego dostawcy usług logistycznych (3PL) do magazynowania w UE, kwestią umowną jest to, czy system WMS 3PL generuje dane na poziomie przemieszczeń, których będą wymagać ramy TOOG.
Etapowy plan: przejście na Jednolitą Rejestrację VAT
Wdrożenie ViDA podąża za przemyślaną logiką etapowania, z której sprzedawcy mogą korzystać do sekwencjonowania własnych przygotowań. Fala styczniowa 2027 r. to przede wszystkim rozszerzenie zakresu OSS i wprowadzenie standardów technicznych DRR — nie nakłada jeszcze obowiązku raportowania transakcji w czasie rzeczywistym dla wszystkich sprzedawców, ale ustanawia wymagania dotyczące formatu danych, które będą egzekwowane w kolejnych falach. Fala lipcowa 2028 r. to moment, w którym następuje zmiana strukturalna: SVR staje się obowiązkowe, TOOG wchodzi w życie, a przebudowa VIES osiąga status operacyjny. Faza 2030 r. rozszerza obowiązki DRR na dodatkowe kategorie transakcji i zamyka pozostałe okna derogacji dla państw członkowskich, którym pozwolono na utrzymanie starszych systemów raportowania. Praktycznym błędem przygotowawczym jest traktowanie 2028 r. jako horyzontu planowania, podczas gdy prace nad infrastrukturą danych wymagane do wsparcia SVR i TOOG muszą zostać ukończone na długo przed datą przejścia. Sprzedawca, który rozpocznie przegląd architektury danych ERP na początku 2027 r. — po uruchomieniu zmian pierwszej fali — będzie miał około dwunastu miesięcy na ukończenie projektu standaryzacji danych, który w złożonej konfiguracji wielonarodowej zazwyczaj trwa od sześciu do dziewięciu miesięcy. Jest to wykonalne, ale ciasne okno i zakłada brak znaczących cykli poprawek. Sprzedawcy, którzy odkładają przegląd na koniec 2027 r., budują ryzyko wykonania, którego logika etapowania miała właśnie uniknąć. Sekwencjonowanie Komisji nie jest arbitralne: zmiany z 2027 r. stanowią podstawę techniczną, na której zbudowane są zmiany strukturalne z 2028 r.
Lista kontrolna gotowości danych przed 2027 r.
- Mapowanie pól DRR: Potwierdź, że Twój system ERP rejestruje numer VAT dostawcy, numer VAT klienta, datę faktury, kwotę opodatkowaną, stawkę VAT i referencję transakcji na poziomie pozycji.
- Przegląd zakresu OSS: Zidentyfikuj wszystkie typy dostaw w swoim unijnym katalogu i potwierdź, które z nich są nowo kwalifikowane do modułów Unii OSS od stycznia 2027 r.
- Spójność identyfikatorów EORI i VAT: Zweryfikuj, czy identyfikatory używane w deklaracjach celnych dokładnie zgadzają się z tymi na koncie OSS.
- Test ekstrakcji danych faktur: Przeprowadź próbną ekstrakcję transakcji wewnątrzwspólnotowych z ostatniego kwartału w formacie kompatybilnym z DRR i sprawdź luki.
- Dopasowanie danych brokera celnego: Potwierdź, że Twój dostawca odprawy celnej w UE przesyła te same identyfikatory VAT, które są używane w Twoim zgłoszeniu OSS.
Lista kontrolna gotowości SVR i TOOG przed 2028 r.
- Audyt rejestracji VAT: Zmapuj każdą aktywną lokalną rejestrację VAT we wszystkich państwach członkowskich UE i zidentyfikuj doradcę lub system zarządzający każdą z nich.
- Konsolidacja historycznych zgłoszeń: Oceń, czy historyczne dane zgłoszeniowe z każdej jurysdykcji są w formacie, który można migrować do struktury SVR.
- Oznaczanie przemieszczeń magazynowych: Potwierdź, że Twój system zarządzania magazynem rozróżnia przesyłki na zamówienia klientów od transferów zapasów między magazynami jako odrębne typy transakcji.
- Przegląd umowy danych 3PL: Sprawdź, czy system Twojego dostawcy usług logistycznych generuje dane na poziomie przemieszczeń kompatybilne z wymaganiami raportowania TOOG.
- Harmonogram przejścia na SVR: Opracuj plan projektu, w którym faza standaryzacji danych zakończy się najpóźniej w I kwartale 2028 r., aby umożliwić testowanie przed terminem lipcowym.
Budowa stosu technologicznego VAT na okres 2027–2030
Praktyczna sekwencja wdrożenia zaczyna się od warstwy danych, a nie od warstwy zgłoszeń. Zanim sprzedawca będzie mógł ocenić, które moduły OSS mają zastosowanie, które przemieszczenia TOOG należy śledzić lub czy jego plan przejścia na SVR jest wykonalny, musi wiedzieć, czy obecne systemy generują czyste, ustrukturyzowane dane transakcyjne na poziomie pól. Ta ocena powinna zostać przeprowadzona jako odrębny projekt z określonym rezultatem: dokument analizy luk, który mapuje obecne pola danych ERP na standard DRR i identyfikuje każde pole, które jest brakujące, zagregowane lub wypełniane niekonsekwentnie. Druga faza to remediacja — albo skonfigurowanie istniejącego ERP do rejestrowania brakujących pól, albo wdrożenie warstwy middleware, która wyodrębnia i strukturyzuje dane przed przekazaniem ich do systemu raportowania VAT. Trzecia faza to testowanie: uruchomienie równoległego zgłoszenia w formacie DRR na rzeczywistych danych transakcyjnych w celu weryfikacji, że wyjście jest czyste przed żywym terminem. Czwarta faza to przegląd modułów OSS, który można dokładnie ukończyć dopiero po potwierdzeniu warstwy danych. Sprzedawcy, którzy próbują odwrócić tę sekwencję — zaczynając od pytania o zgłoszenie OSS i cofając się do architektury danych — zazwyczaj odkrywają luki danych w najgorszym możliwym momencie: podczas żywego cyklu zgłoszeniowego z zbliżającym się terminem. Dla sprzedawców prowadzących wielowęzłową dystrybucję w UE warstwa fizycznych zapasów dodaje kolejny wymiar. Każdy węzeł magazynowy przechowujący zapasy generuje rekordy przemieszczeń wewnątrzwspólnotowych, a te rekordy muszą być przypisywalne do prawidłowego traktowania VAT zarówno zgodnie z obecnymi zasadami, jak i nadchodzącymi ramami TOOG. Strategia dystrybucji pan-europejskiej zbudowana na czystych danych przemieszczeń zapasów to pod ViDA nie tylko kwestia efektywności logistycznej — to warunek wstępny zgodności.
Dane o przemieszczeniach zapasów jako aktywo zgodności
W nadchodzącej architekturze ViDA rekord tego, gdzie fizycznie przemieszczają się zapasy między węzłami magazynowymi w UE, to nie tylko log operacyjny — jest to źródło danych do traktowania VAT w ramach TOOG. Sprzedawca przemieszczający paletę z holenderskiego hubu konsolidacyjnego do niemieckiego centrum realizacji generuje zdarzenie Transferu Własnych Towarów, które będzie wymagało ustrukturyzowanego rekordu VAT w ramach z 2028 r. Jeśli system zarządzania magazynem rejestruje to przemieszczenie tylko jako wewnętrzny transfer zapasów bez pól danych istotnych dla VAT, rekord TOOG nie może zostać zrekonstruowany z dostępnych danych. Praktyczną implikacją jest to, że sprzedawcy powinni oceniać swoje obecne systemy zarządzania magazynem i śledzenia zapasów nie tylko pod kątem efektywności operacyjnej, ale także pod kątem zdolności do generowania rekordów na poziomie przemieszczeń w formacie kompatybilnym z przyszłym zautomatyzowanym miesięcznym raportowaniem OSS. Dostawcy zewnętrznych usług logistycznych (3PL), którzy prowadzą międzynarodową infrastrukturę magazynową i śledzą szczegółowe transgraniczne przemieszczenia zapasów z czystymi śladami danych, są bezpośrednio przygotowani do wsparcia tego wymagania — ponieważ dane zgodności i rekord fizycznego przemieszczenia pochodzą z tego samego systemu, a nie są uzgadniane po fakcie na różnych platformach.
Styczeń 2027: Pierwsza fala
Nowe moduły Unii OSS dla określonych kategorii dostaw mediów wchodzą w życie. Techniczne standardy danych DRR są publikowane i egzekwowalne. Sprzedawcy muszą potwierdzić pokrycie zakresu OSS i ukończyć analizę luk w polach danych ERP przed tą datą.
Lipiec 2028: Zmiana strukturalna
Obowiązkowa Jednolita Rejestracja VAT zastępuje lokalne wielonarodowe zgłoszenia. Ramy Transferu Własnych Towarów aktywują się dla przemieszczeń zapasów między magazynami. Krzyżowe referencjonowanie VIES w czasie zbliżonym do rzeczywistego osiąga status operacyjny we wszystkich państwach członkowskich.
2030: Pełny zakres DRR
Wymagania Raportowania Cyfrowego rozszerzają się na dodatkowe kategorie transakcji. Pozostałe okna derogacji państw członkowskich zamykają się. Sprzedawcy korzystający ze starszego oprogramowania VAT dla jednego kraju stają w obliczu pełnej ekspozycji, jeśli remediacja architektury danych nie została ukończona.
Co sprzedawcy transgraniczni powinni ustalić już teraz
Logika etapowania ViDA daje sprzedawcom okno przygotowawcze, ale to okno jest krótsze niż sugerują nagłówkowe terminy. Pierwsza fala ze stycznia 2027 r. nie jest miękkim uruchomieniem — ustanawia standardy danych, od których zależą strukturalne zmiany z lipca 2028 r. Sprzedawca, który traktuje 2027 r. jako rok monitorowania, a 2028 r. jako rok działania, kompresuje wielofazowy projekt architektury danych w jeden sprint wykonawczy bez marginesu na poprawki. Decyzje, które należy podjąć już teraz, to: który zespół lub doradca jest właścicielem analizy luk DRR, czy obecny ERP może generować dane transakcyjne na poziomie pól w wymaganym formacie oraz czy infrastruktura logistyczna generująca rekordy przemieszczeń zapasów wewnątrzwspólnotowych jest zdolna do generowania danych kompatybilnych z TOOG od pierwszego dnia przejścia w 2028 r. Dla sprzedawców działających w wielu węzłach magazynowych w UE warstwa fizycznej dystrybucji i warstwa zgodności VAT nie są już oddzielnymi strumieniami pracy. Rekord przemieszczenia zapasów jest rekordem zgodności. Sprzedawcy, którzy nie zmapowali jeszcze swojego śladu dystrybucji w UE w odniesieniu do nadchodzących ram TOOG, powinni traktować to mapowanie jako natychmiastowy priorytet, a nie zadanie na 2027 r. Infrastruktura realizacji B2B w Europie, z której sprzedawca korzysta dzisiaj, albo wesprze, albo utrudni jego postawę zgodności z ViDA — i tę ocenę można przeprowadzić już teraz, przed wejściem w życie pierwszego aktu wykonawczego.
FLEX. prowadzi międzynarodową infrastrukturę magazynową w całej UE z systemami śledzenia zapasów, które generują dane na poziomie przemieszczeń na poziomie transakcji i transferu. Jeśli Twój obecny setup logistyczny nie jest w stanie wyraźnie rozróżnić przesyłek na zamówienia klientów od transferów zapasów między magazynami — lub jeśli Twój 3PL nie może potwierdzić, że jego system WMS będzie generował rekordy kompatybilne z TOOG — jest to luka operacyjna, którą warto rozwiązać przed terminem 2027 r., a nie po nim. Zweryfikuj swoje obowiązki prawne i podatkowe z wykwalifikowanym doradcą VAT. W zakresie warstwy operacyjnej i logistycznej — czyste dane przemieszczeń zapasów, wielowęzłowe magazynowanie w UE oraz infrastruktura dystrybucji transgranicznej dostosowana do nadchodzącej architektury zgodności — skontaktuj się z FLEX., aby omówić swój obecny setup.
