Eksport lokali na dane.gov.pl dla Dewelopera - Rozwiązanie

Eksport na dane.gov.pl to w praktyce: jedno źródło danych o lokalach → automatyczny plik XML + suma kontrolna MD5 → zgłoszenie do weryfikacji → cykliczne pobieranie.
Poniżej mamy gotową checklistę, tabelę ról i typowe błędy, które wywracają publikację.

Odpowiedź w 60 sekund

• Trzymamy ofertę (lokale/ceny/statusy) w jednym miejscu, nie w 3 Excelach - PanelDlaDewelopera.pl
• W PanelDlaDewelopera.pl generujemy 2 stałe zasoby: XML i MD5.
• W dane.gov.pl zakładamy konto i prosimy o profil dostawcy + uprawnienia edytora. (gotowe instrukcje i szablony w PDD)
• Wysyłamy do weryfikacji XML + MD5 (jako adresy url do pobrania z PDD).
• Po akceptacji dane.gov.pl pobiera pliki cyklicznie, a Ty aktualizujesz tylko dane w naszym panelu.

Problem i kontekst

Najczęściej eksport “rozsypuje się” dopiero wtedy, gdy zaczyna się dużo dziać: sprzedaż zmienia cenę, marketing poprawia stronę, a ktoś jeszcze trzyma “finalny” arkusz z zeszłego tygodnia.

Mini-scenariusz:

w środę aktualizujemy 8 cen. W czwartek klient dzwoni: “na stronie mam inną cenę niż w mailu od handlowca”. I nagle nie problemem jest dane.gov.pl, tylko to, że nie mamy jednego źródła prawdy.

Dlatego podchodzimy do tego tak:

najpierw porządkujemy ofertę, a dopiero potem “publikujemy ją” w różnych kanałach (strona, CRM/leady, raporty, dane.gov.pl). PDD robi tu robotę, bo trzyma lokale/ceny/statusy + historię zmian + eksporty w jednym miejscu + każdy w zespole ma osobne konto z dostępem do danych.

Checklista: eksport do dane.gov.pl w 7 krokach

1) Porządkujemy dane lokali w jednym miejscu

Minimalny zestaw, który musi być spójny:

• numer lokalu
• budynek / etap
• metraż
• status (np. wolny / zarezerwowany / sprzedany)
• cena (i ewentualnie cena za m², jeśli tak prezentujemy ofertę)

Jeśli to jest spójne w PDD, reszta to “publikacja”.

2) Ustalamy statusy (żeby nie generować chaosu)

Proste zasady:

• Kiedy lokal przechodzi na zarezerwowany?
• Kiedy zmieniamy na sprzedany?
• Kto i gdzie ma prawo zmieniać cenę?

To brzmi jak drobiazg, ale 80% błędów w eksporcie to nie “format pliku”, tylko złe dane źródłowe.

3) Generujemy w PDD plik XML + sumę kontrolną MD5

W PanelDlaDewelopera.pl traktujemy to jak “widok” na ofertę:

• XML = zawartość
• MD5 = podpis spójności (czyli szybka weryfikacja, że plik nie jest “uszkodzony” i odpowiada zawartości)

Klucz: to mają być stabilne zasoby (żeby Dane.gov.pl mogło je pobierać cyklicznie bez proszenia nas o “nowy link”).

4) Zakładamy konto i przygotowujemy profil dostawcy w dane.gov.pl

W praktyce potrzebujesz na tym etapie:

• konta użytkownika
• profilu dostawcy (organizacji)
• uprawnień edytora (żeby móc dodać/edytować zbiór danych)

Tu zwykle jest najwięcej opóźnień, bo dochodzi weryfikacja po stronie portalu — więc robimy to jako pierwszy krok organizacyjny.

W naszym panelu dostarczamy gotową instrukcje i szablony maili.

5) Zgłaszamy do weryfikacji XML + MD5

Nie kombinujemy: zgłoszenie powinno jasno mówić:

• kto jest dostawcą
• czego dotyczy zbiór (inwestycja / oferta lokali)
• gdzie są zasoby do pobrania: XML i MD5

W naszym panelu dostarczamy gotową instrukcje i szablony maili.

6) Po akceptacji ustawiamy proces “jedna zmiana = jedna prawda”

Najprostsza zasada operacyjna:

• zmieniamy dane lokalu tylko w PDD
• strona / raporty / publikacje są “odbiornikami” tych samych danych

Efekt: zamiast “kto ma najnowszy arkusz”, mamy historię zmian i spójny stan oferty.

7) Kontrolujemy po wdrożeniu (5 minut tygodniowo)

Robimy prosty rytuał:

• raz w tygodniu sprawdzamy, czy pobieranie działa
• przy większych zmianach (np. nowy etap) robimy szybki test spójności: 3 losowe lokale (status, metraż, cena)

Tabela: kto co robi, żeby zamknąć temat z zespołem

Najczęstsze błędy (i szybka naprawa)

1. Trzy źródła prawdy (Excel + strona + CRM)
   Naprawa: jedna oferta w PDD, reszta to publikacje/eksporty.
2. Zmiany “na szybko” bez historii
   Naprawa: zmieniamy w narzędziu, które trzyma historię zmian i raport.
3. Statusy typu “prawie sprzedany”, “wstępnie”
   Naprawa: 3–4 statusy max. Reszta w notatkach, nie w ofercie.
4. Ktoś zmienia ceny, a nikt nie wie
   Naprawa: prosta reguła: jedna osoba/rola zatwierdza ceny - W PDD otrzymujesz konta użytkowników i pełną historie zmian.
5. Wrzucanie nowego pliku za każdym razem
   Naprawa: stałe zasoby (XML + MD5), które system pobiera cyklicznie - 2 gotowe niezmienne linki.
6. Brak kontroli po publikacji
   Naprawa: 5 minut tygodniowo na szybki test losowych lokali.
7. Bałagan w etapach/budynkach
   Naprawa: najpierw porządek w strukturze inwestycji, dopiero potem eksport.
8. Zbyt późno zaczęty proces (gdy sprzedaż już “na pełnej”)
   Naprawa: ustawiamy eksport, zanim ruszymy z masową komunikacją cen.

FAQ

Czy musimy publikować wszystko od razu (całą inwestycję)?

Nie. Operacyjnie najlepiej publikować to, co faktycznie jest w sprzedaży i ma spójne dane. Klucz to konsekwencja w źródle.

Co to daje biznesowo poza “odhaczeniem obowiązku”?

Mniej chaosu. Gdy oferta jest spójna, spada liczba pomyłek, reklamacji “bo na stronie było inaczej” i gaszenia pożarów między działami.

Po co jest plik MD5?

To szybka kontrola spójności: dane.gov.pl może zweryfikować, czy pobrany XML jest dokładnie tym, co powinien (bez “uciętych” danych).

Jak często aktualizować dane?

Najbezpieczniej przyjąć zasadę: każda zmiana w ofercie → od razu aktualny eksport (a cykliczne pobieranie robi resztę). Nie odkładaj “na koniec dnia”, bo to rodzi chaos.

Co jeśli mamy kilka spółek (SPV) i kilka inwestycji?

Procesowo: trzymamy rozdzielność danych i odpowiedzialności. Mniej mieszania = mniej błędów przy publikacji i raportowaniu.

Czy da się to wdrożyć bez angażowania IT?

Tak, jeśli źródło danych to PDD, a nie niestabilne pliki. Najwięcej czasu schodzi na porządkowanie danych i zasad, nie na “technologię”.

Skąd mam wiedzieć, że “wszystko działa”?

Po wdrożeniu PDD zrób krótki test kontrolny: sprawdź kilka losowych lokali w wyszukiwarce dane.gov.pl i czy publikacja jest aktualna względem tego, co dodałeś/aś w PanelDlaDewelopera.pl

Podsumowanie

Eksport na dane.gov.pl przestaje być projektem, gdy traktujemy go jako kolejny kanał publikacji tej samej oferty. My robimy to tak: PDD jest “jednym źródłem prawdy”, a XML + MD5 to automatyczny efekt dobrze poukładanych danych.

Jeśli chcesz zobaczyć, jak wygląda to w praktyce (oferta → historia zmian → eksport XML/MD5 → spójność danych), odpal wersję demonstracyjną PanelDlaDewelopera.pl i przejdź ten proces na przykładowej inwestycji.