Retencja danych w D365FO a wymogi JPK: które dane musisz trzymać, a które tylko myślisz, że musisz

W rozmowach o redukcji bazy Dynamics 365 Finance & Operations najczęstszym hamulcowym nie jest technologia, lecz jedno zdanie: „tego nie możemy ruszyć, bo compliance”. Zdanie to bywa prawdziwe: polskie obowiązki sprawozdawcze, z JPK na czele, rzeczywiście nakładają na część danych wieloletnie okresy przechowywania. Problem w tym, że w praktyce bywa ono rozciągane na całą bazę, także na dane, których żaden przepis nie dotyczy. Skutek: organizacja płaci za przechowywanie wszystkiego, bo nikt nie zmapował, co naprawdę podlega obowiązkom, a co tylko „na wszelki wypadek”.

Ten artykuł porządkuje temat od strony architektury danych: które kategorie w D365FO wiążą się z obowiązkami sprawozdawczymi, które są od nich wolne. Co równie ważne, artykuł wyjaśnia, dlaczego nawet dane objęte obowiązkiem nie muszą mieszkać w najdroższym możliwym miejscu, czyli operacyjnej bazie ERP. Zastrzeżenie na start: okresy i zakresy obowiązków przywołujemy poglądowo. Wiążące decyzje retencyjne należy zawsze skonsultować z działem księgowości lub doradcą podatkowym, bo wymogi zależą od specyfiki organizacji i zmieniają się w czasie.

‍

Dwa mity o retencji: „wszystko trzeba trzymać” i „stare można kasować”

Dyskusję o retencji psują dwa symetryczne uproszczenia. Mit pierwszy, „wszystko trzeba trzymać”, traktuje całą bazę jako materiał dowodowy: skoro gdzieś istnieją obowiązki przechowywania, bezpieczniej nie usuwać niczego. To podejście pozornie ostrożne, w rzeczywistości kosztowne podwójnie: finansowo (każdy gigabajt konsumuje płatny limit) i operacyjnie (rosnąca baza spowalnia środowisko). Mit drugi, „stare można kasować”, idzie w przeciwną skrajność i traktuje wiek danych jako jedyne kryterium, ignorując fakt, że część rekordów sprzed lat wciąż podlega obowiązkom. Prawda leży w mapowaniu: redukcja nie polega na kasowaniu wszystkiego, co stare, lecz na mądrym zarządzaniu cyklem życia danych: system powinien przechowywać system przechowywał te informacje, które faktycznie są potrzebne biznesowi, raportowaniu i zgodności, a pozostałe opuszczały bazę według ustalonych reguł.

‍

Mapa danych vs obowiązki sprawozdawcze

Punktem wyjścia jest zestawienie kategorii danych z obowiązkami, które ich dotyczą, ponieważ obowiązki są przypisane do rodzajów informacji, nie do tabel jako takich.

Transakcje magazynowe a JPK magazynowy

Tabele transakcji magazynowych należą do najcięższych w typowej instalacji D365FO. Zarazem należą do tych, które w polskich rozwiązaniach bywają potrzebne do JPK magazynowego. To klasyczny przykład danych, których nie wolno traktować myszką „delete”. Zanim cokolwiek zostanie zredukowane, trzeba ustalić, jaki zakres i horyzont danych magazynowych organizacja musi być w stanie raportować.

Linie faktur sprzedaży a JPK księgowe i finansowe

Analogicznie jest w przypadku linii faktur sprzedaży. To tabela o dużej wadze, powiązana z JPK księgowymi i finansowymi, które są obligatoryjne do przechowywania przez dłuższy okres. I tu jednak warto zauważyć sformułowanie, które celowo powtarzamy: „bywają potrzebne”. Zakres obowiązku zależy od profilu organizacji i wymagań konkretnych struktur raportowych. Dlatego mapowanie wykonuje się z księgowością, nie w dziale IT.

Okresy przechowywania: pięć, siedem lat i przypadki szczególne

Dla danych księgowych typowe horyzonty przechowywania to pięć lub siedem lat, w zależności od konkretnych wymagań. Część organizacji potrzebuje przechowywać wybrane obszary dłużej, czy to z powodu przepisów branżowych, czy własnych polityk. Stąd w architekturze retencji nie ma jednej daty granicznej: granica jest specyficzna dla każdego klienta i każdego obszaru danych osobno. Właśnie ta obserwacja jest fundamentem sensownej polityki. Zarazem jest powodem, dla którego gotowe, uniwersalne „ustawienia retencji” nie istnieją.

‍

Dane bez żadnego wymogu retencyjnego, które i tak zalegają

Po zmapowaniu obowiązków ujawnia się druga strona medalu: znaczna część ciężaru bazy przypada na kategorie, których żaden przepis nie każe przechowywać. Alerty systemowe tracą ważność po siedmiu dniach od wystąpienia. Ich wieloletnia historia nie służy ani biznesowi, ani sprawozdawczości. Logi zmian, potrzebne do celów administracyjnych i audytu wewnętrznego, nie muszą rezydować w bazie operacyjnej, by pełnić swoją funkcję. Tabele stagingowe integracji i tabele parm po księgowaniach to dane czysto techniczne, pozbawione jakiejkolwiek wartości dowodowej po zakończeniu procesu. Dla tych kategorii istnieje pełna swoboda czyszczenia. Ponieważ przyrastają nieprzerwanie, to od nich należy zacząć, bo dają uzysk bez jednej rozmowy z doradcą podatkowym.

‍

Gdzie przechowywać dane objęte obowiązkiem, żeby nie płacić za nie jak za operacyjne

Najważniejsze rozróżnienie całego tematu brzmi: obowiązek przechowywania danych to nie obowiązek przechowywania ich w operacyjnej bazie ERP. Baza produkcyjna jest najdroższym miejscem składowania. Każdy gigabajt konsumuje limit Database Storage Capacity, którego przekroczenie kosztuje od 337,20 do 448,80 EUR rocznie (stan na 2026 rok). Przy tym obciąża wydajność środowiska. Alternatywy istnieją na trzech poziomach. Dla danych, które muszą pozostać dostępne w kontekście systemu, Microsoft oferuje mechanizm archiwizacji z warstwą Long Term Data Retention. Dane opuszczają tabele operacyjne, pozostając w zasięgu rozwiązania. Dla danych o charakterze czysto dowodowym wchodzi w grę eksport do zewnętrznego, zimnego składowania, o koszcie ułamkowym względem bazy ERP. Wybór warstwy per obszar danych to decyzja architektoniczna, którą podejmuje się raz. Oszczędności przynosi ona co roku.

‍

Jak zbudować politykę retencji per obszar danych. Szablon decyzyjny

Praktyczna procedura składa się z czterech pytań zadawanych dla każdego obszaru danych osobno.

1. Czy obszar podlega obowiązkowi przechowywania?
Jeżeli tak, przez ile lat i w jakim zakresie?
Odpowiada: księgowość lub doradca podatkowy.

2. Jaki horyzont danych jest potrzebny operacyjnie?
Czy dane są potrzebne do korekt, śledzenia pochodzenia transakcji lub bieżącego raportowania?
Odpowiada: biznes.

3. W której warstwie dane mają być przechowywane w poszczególnych fazach życia?
Do wyboru: baza operacyjna, archiwum lub składowanie zewnętrzne.
Odpowiada: architektura we współpracy z IT.

4. Jaki mechanizm będzie egzekwował regułę?
Może to być zadanie czyszczące, proces archiwizacji lub eksport. Polityka bez automatu egzekwującego pozostaje dokumentem, a nie stanem bazy.

Wynik: tabela decyzyjna obejmująca wszystkie ciężkie obszary danych. Kończy ona erę argumentu „nie ruszamy, bo compliance”, zastępując go zdaniem: „ruszamy dokładnie to, co wolno, i dokładnie tak, jak ustalono”.

‍

Chcesz oddzielić dane, które musisz trzymać, od tych, za które tylko płacisz? Skontaktuj się z nami. Wyślemy prostą instrukcję self-checku. Wystarczą zrzuty z Power Platform Admin Center i wynik skryptu SQL badającego rozmiary tabel na środowisku testowym. Przygotujemy estymację możliwych uzysków i ofertę fixed price na ich realizację.