Files

9.8 KiB
Raw Permalink Blame History

Strony prawne — Impressum, Polityka prywatności, Polityka cookies

/impressum (id 10), /polityka-prywatnosci ↔ /datenschutzerklarung (id 8), /polityka-cookies ↔ /cookie-richtlinie (id 9). Wszystkie trzy obecnie puste ("Treść w przygotowaniu").

Granica odpowiedzialności — zgodnie z wymagania-prawne.md §6: „Nie jesteśmy kancelarią. Nie piszemy treści prawnych ani nie doradzamy prawnie." Ten plik dostarcza strukturę i punkty do wypełnienia, nie gotowy tekst prawny do wklejenia i publikacji. Każdy fragment oznaczony [DO POTWIERDZENIA] wymaga danych od klienta lub jego prawnika/doradcy podatkowego przed publikacją. Dołączone przez Ciebie pliki polityka-prywatnosci.txt, polityka-plikow-cookies.txt, warunki-korzystania-ze-strony-internetowej.txt dotyczą innej firmy (The Clean Team — firma sprzątająca, VAN STEV Sp. z o.o., Opole) — traktuję je jako wzorzec STRUKTURY dokumentu (jakie sekcje, jaki poziom szczegółowości), nie jako źródło treści do skopiowania z podmianą nazwy. Podmiana samej nazwy administratora przy zachowaniu cudzej treści merytorycznej (cele przetwarzania, podstawy prawne, okresy przechowywania) byłaby błędem — te elementy muszą odzwierciedlać RZECZYWISTĄ działalność Janusza Kędzierskiego, nie sklepu sprzątającego.

Ważna różnica jurysdykcyjna: działalność klienta jest zarejestrowana w Niemczech (Ludwigshafen am Rhein — adres do potwierdzenia, patrz 10-architektura-cms.md §1) i działa jako Beratungsstelle stowarzyszenia b.b.h. Lohnsteuerhilfeverein e.V. Impressum strony niemieckiej podlega niemieckiemu Digitale-Dienste-Gesetz (DDG, dawniej TMG) §5 — inny reżim formalny niż polska ustawa o świadczeniu usług drogą elektroniczną, mimo że RODO/DSGVO (to ta sama regulacja UE 2016/679) i tak obowiązuje w obu wersjach językowych. Rekomendacja: treść wersji niemieckiej (Impressum, Datenschutzerklärung) powinien zweryfikować niemiecki prawnik lub doradca podatkowy klienta — polski wzorzec RODO nie pokrywa niemieckich wymogów Impressumspflicht i specyficznych obowiązków informacyjnych dla Lohnsteuerhilfevereine (np. wskazanie właściwego organu nadzoru — Aufsichtsbehörde — który przyznał uznanie na mocy §4 Nr. 11 StBerG).


1. Impressum

Strona istnieje tylko jako pojedynczy tytuł bez wersji PL merytorycznie odrębnej od DE w praktyce niemieckiej (Impressum to niemiecki wymóg prawny — nawet polska wersja UI strony pokazuje te same dane rejestrowe, bo dotyczą niemieckiego podmiotu). Wymagane elementy do zebrania od klienta:

Element Status Notatka
Pełna nazwa firmy [DO POTWIERDZENIA] z danych: „Finanz- & Lohnbuchhaltung Dipl.-Ing. Janusz Kędzierski" — potwierdzić dokładną formę rejestrową (Einzelunternehmen? Gewerbe angemeldet unter...?)
Adres siedziby [DO POTWIERDZENIA] dwie sprzeczne wersje w dotychczasowych ustaleniach (Böhlstraße 2 vs Bismarckstr. 112, Ludwigshafen) — wymaga jednoznacznego potwierdzenia, nie zgadywać
Telefon, e-mail [DO POTWIERDZENIA] placeholder w danych (+49 123 456 789, [email protected])
Steuernummer / USt-IdNr. [DO POTWIERDZENIA] jeśli dotyczy formy działalności
Wskazanie stowarzyszenia i podstawy uznania [DO POTWIERDZENIA z prawnikiem] typowy dla Lohnsteuerhilfeverein/Beratungsstelle wymóg: nazwa stowarzyszenia (b.b.h. Lohnsteuerhilfeverein e.V.), właściwy Aufsichtsbehörde (organ nadzoru, który przyznał uznanie wg §4 Nr. 11 StBerG), często też odesłanie do rejestru Lohnsteuerhilfevereine — to jest specyficzny dla tej branży wymóg, którego NIE ma w dołączonych wzorcach (branża sprzątająca) — wymaga osobnej weryfikacji prawnej, nie da się go wywnioskować z ogólnego szablonu RODO
Odpowiedzialny za treść (redaktor) [DO POTWIERDZENIA] zwykle Janusz Kędzierski jako Beratungsstellenleiter
Link do platformy ODR (jeśli dotyczy B2C UE) do oceny z prawnikiem standardowy element niemieckich Impressów

Layout: prosty, jednokolumnowy tekst — to strona typu Read, zero dekoracji, żadnej tekstury papieru (tu akurat dosłowność „dokumentu" nie potrzebuje metafory, bo TO JEST dokument formalny). Czytelna typografia, sticky-progress opcjonalnie (raczej niepotrzebne, strona krótka).


2. Polityka prywatności / Datenschutzerklärung

Struktura oparta na sekcjach z dołączonego wzorca (polityka-prywatnosci.txt), ale z rzeczywistymi celami przetwarzania danych DLA TEJ strony i tej działalności — nie kopiować sekcji „Złożenie zamówienia w Sklepie" (nie ma tu sklepu):

Sekcja Treść realna dla tego projektu
Administrator danych Dane firmy Janusza (patrz Impressum wyżej) — [DO POTWIERDZENIA]
Twoje uprawnienia (RODO) Standardowy katalog art. 15–21 RODO — struktura ze wzorca jest tu poprawna do przeniesienia niemal 1:1 (to prawa ustawowe, nie treść specyficzna dla branży sprzątającej)
Cel: kontakt przez WhatsApp/formularz [NOWE — nie ma odpowiednika we wzorcu] trzeba opisać wprost: dane podane w wiadomości WhatsApp/formularzu przetwarzane w celu udzielenia odpowiedzi i przygotowania oferty rozliczenia podatkowego; podstawa — działania przed zawarciem umowy (art. 6 ust. 1 lit. b RODO) lub zgoda
Cel: realizacja usługi rozliczenia podatkowego [NOWE] to jest GŁÓWNY cel przetwarzania tej firmy i we wzorcu (firma sprzątająca) nie występuje w ogóle — wymaga opisania: jakie dane osobowe/podatkowe klient przekazuje (Lohnsteuerbescheinigung, IdNr/PESEL, dane o dochodach), komu są przekazywane (Finanzamt, stowarzyszenie b.b.h.), jak długo przechowywane (przepisy o przechowywaniu dokumentacji podatkowej w Niemczech mają własne, dłuższe terminy niż ogólne RODO — do potwierdzenia z doradcą podatkowym klienta, nie zgadywać)
Cel: analiza/cookies statystyczne Zależne od decyzji w 11-integracje-seo-wydajnosc.md §3 — jeśli GA4/Plausible zostanie wdrożone, opisać tu zgodnie z realnym narzędziem
Odbiorcy danych b.b.h. Lohnsteuerhilfeverein e.V. (jako stowarzyszenie, w ramach którego świadczona jest usługa), niemiecki Finanzamt, dostawca hostingu/poczty — lista do potwierdzenia z klientem, nie zgadywać dostawców
Przekazanie danych poza UE Do zweryfikowania w zależności od dostawcy hostingu (patrz 10-architektura-cms.md — jeśli Hetzner/UE, odpowiedź: „nie ma miejsca"; jeśli inny dostawca spoza UE, wymaga osobnej klauzuli)
Bezpieczeństwo danych SSL/TLS — struktura ze wzorca poprawna do przeniesienia

Layout: identyczny jak Impressum — czysty tekst, długie akapity, spis treści/kotwice do sekcji na początku strony (skoki nawigacyjne ułatwiają znalezienie interesującego fragmentu na długiej stronie prawnej).


Tu wzorzec (polityka-plikow-cookies.txt) jest strukturalnie bardzo blisko tego, co faktycznie potrzebne — tabela cookies ma być realna dla TEGO stacku technicznego, nie skopiowana z cudzej strony:

Cookie Cel Okres Kategoria Źródło
ipal-locale zapamiętanie wybranej wersji językowej (PL/DE) sesyjny funkcjonalny plugin ipal-kit (potwierdzone w kodzie)
payload-token uwierzytelnienie w panelu administracyjnym (tylko zalogowani redaktorzy, nie zwykli odwiedzający) 2h (domyślny czas życia tokena) niezbędny Payload CMS (potwierdzone w kodzie)
theme (next-themes) zapamiętanie wybranego motywu jasny/ciemny trwały (localStorage, nie cookie — do weryfikacji technicznej, next-themes domyślnie używa localStorage, nie ciasteczka — jeśli tak, ta pozycja idzie do sekcji „localStorage", nie do tabeli cookies) funkcjonalny next-themes
_ga, _ga_<id> jeśli GA4 zostanie wdrożone — patrz 11 §3 2 lata (Google default) statystyczny Google Analytics (WARUNKOWE — tylko jeśli faktycznie wdrożone)
Cookie zgody na baner (cookie-consent / nazwa z ConsentProvider) zapamiętanie wyboru użytkownika w bannerze cookies do potwierdzenia w kodzie pluginu niezbędny ipal-kit consent

Uwaga: tabela MUSI zostać zweryfikowana względem faktycznego audytu przeglądarki (DevTools → Application → Cookies) na wdrożonej stronie staging, nie tylko na podstawie czytania kodu — zgodnie z narzędziem „Cookiebot audit" / „DevTools → Application" w wymagania-projektowe-strony.md §3. Publikowanie listy cookies, która nie odpowiada rzeczywistości technicznej, to sam w sobie błąd zgodności RODO/ePrivacy.

Layout: tabela (nie proza) — to jedyna z trzech stron prawnych, gdzie tabelaryczne zestawienie jest czytelniejsze niż akapity, spójnie z tym, jak wzorzec polityka-plikow-cookies.txt już to robi.


4. Baner zgody na cookies (element techniczny, nie treść strony)

Patrz wymagania-prawne.md §2 — plugin ipal-kit dostarcza CookieBanner/ CookieButton/ConsentProvider z 4 kategoriami (necessary/functional/ analytics/marketing) i enforcementem („Odrzuć" na równi z „Akceptuj"). Do zweryfikowania w 10-architektura-cms.md §4, czy komponent jest już podłączony w layout.tsx — w przeglądanych plikach kodu (Header, Footer, Providers) nie natrafiłem na jawne wywołanie <CookieBanner/>, co może oznaczać, że jest jeszcze do wpięcia.

Wygląd banera (jeśli jeszcze do zbudowania/dostosowania wizualnie): spójny z resztą serwisu — karta w stylu „dokumentu" (biały/kremowy panel, cienka ramka, przycisk akcentowy), umieszczona jako pasek dolny (nie modal na środku ekranu blokujący całą treść — mniej agresywne, lepiej konwertujące UX), z linkiem do /polityka-cookies przez getSystemPagePath.