Przejdź do treści

PORADNIK • e-DEWELOPERSKI AI 360

Błędy w pliku CSV z cenami mieszkań — kontrola raportu dewelopera 2026

Ilustracja schematyczna: Błędy w pliku CSV z cenami mieszkań — kontrola raportu dewelopera 2026 – nieruchomości i analiza inwestycji

Przygotowanie pliku CSV z cenami mieszkań to nie tylko eksport arkusza z programu sprzedażowego. Błędy mogą pojawić się już przy doborze separatora, nazw kolumn, identyfikatorów lokali albo dat obowiązywania ceny. W listopadzie 2026 r. jest to szczególnie istotne ze względu na planowaną zmianę sposobu przekazywania danych w dokumencie elektronicznym. Ustawa z 17 lipca 2026 r. (Dz.U. 2026 poz. 1077) wchodzi w życie 11 listopada, natomiast szczegółowy układ 57 pól wynika z projektu rozporządzenia Ministerstwa Cyfryzacji i wymaga sprawdzenia w wersji ostatecznej.

Ten poradnik przedstawia praktyczne pułapki w raportach CSV i sposób ich wychwytywania. Nie jest instrukcją obchodzenia obowiązków ani certyfikatem zgodności z prawem. Kontrola techniczna nie zastępuje sprawdzenia prawdziwości informacji w systemie sprzedażowym ani potwierdzenia publikacji danych na dane.gov.pl.

1. Nieprawidłowy separator i cudzysłowy

Pliki CSV mogą używać przecinka, średnika albo tabulatora jako separatora kolumn. Problem powstaje wtedy, gdy eksport zawiera w polach przecinki dziesiętne i jednocześnie wykorzystuje przecinek do oddzielania danych. Prawidłowe cytowanie pól jest wtedy niezbędne, ale różne programy mogą interpretować je odmiennie. Jeśli liczba kolumn w kilku wierszach nie jest jednakowa, raport wymaga ręcznego wyjaśnienia.

Przed dalszą analizą sprawdź nie tylko pierwszą linię, lecz także rekordy zawierające znaki specjalne, długie adresy i tekstowe opisy. Nie naprawiaj danych na ślepo przez zastąpienie wszystkich przecinków średnikami, bo możesz uszkodzić zapis kwot.

2. Brakujące lub powtórzone nagłówki

Każda kolumna musi mieć jednoznaczne znaczenie. Nazwa „Cena” pojawiająca się dwukrotnie nie pozwala stwierdzić, czy chodzi o cenę lokalu, miejsca postojowego czy łącznego świadczenia. Podobnie pola opisane ogólnym słowem „Data” trzeba powiązać z rzeczywistą funkcją w systemie źródłowym. Przed mapowaniem należy porównać nazwy nagłówków z aktualnym dokumentem wzorcowym, a nie tylko z przykładowym arkuszem innej firmy.

3. Różna liczba kolumn w kolejnych wierszach

Wiersz zawierający mniej pól niż nagłówek może wynikać z błędnego separatora, niepoprawnego cytowania tekstu albo z niepełnego eksportu. Wiersz z większą liczbą kolumn zwykle wskazuje na rozdzielenie wartości, która powinna pozostać w jednym polu. Oba problemy mogą skutkować przesunięciem ceny do kolumny z innym znaczeniem. W takiej sytuacji plik nie powinien być wykorzystywany do dalszych automatycznych porównań, dopóki nie wyjaśniono przyczyny.

4. Niepoprawne daty i brak historii obowiązywania cen

Data utworzenia raportu nie musi być datą obowiązywania konkretnej ceny mieszkania. W systemie CRM mogą istnieć oddzielne daty wprowadzenia, zatwierdzenia i aktualizacji wartości. Jeśli do eksportu trafia tylko jedna z nich, trzeba potwierdzić jej znaczenie. Szczególnie ryzykowne jest automatyczne uzupełnianie daty bieżącej we wszystkich pustych polach. Może to stworzyć fałszywą historię zmian.

Kontrola formatu sprawdzi, czy zapis przypomina datę według wymaganego wzorca, ale nie dowiedzie, że data jest prawdziwa. Użytkownik musi porównać ją z zatwierdzonymi danymi systemu sprzedażowego i aktualną specyfikacją urzędową.

5. Kwoty w złej precyzji lub innym zakresie

Cena może być zapisana z przecinkiem dziesiętnym, kropką, bez części ułamkowej albo ze spacjami tysięcznymi. Program importujący może odczytać ją jako tekst, co utrudnia sprawdzanie zmian. W projekcie rozporządzenia opisano wymagania dotyczące formatów części kwot, ale zastosowanie konkretnej reguły powinno wynikać z obowiązującego dokumentu i znaczenia pola.

Co ważniejsze, nie należy porównywać niejednakowych definicji kwot. Cena samego lokalu nie jest równoważna cenie uwzględniającej określone elementy dodatkowe. Jeśli baza nie rozróżnia tych składników, poprawność samej liczby nie wystarczy.

6. Błędy numerów NIP, REGON i KRS

Identyfikatory przedsiębiorcy mogą zostać zmienione przez automatyczne formatowanie w programie arkuszowym. Zera wiodące i liczba cyfr mają znaczenie, a część identyfikatorów wykorzystuje cyfry kontrolne. Sprawdzanie ich składni może wykryć błędnie przepisane numery, ale nie potwierdza, że dane należą do właściwego podmiotu. Do tego potrzebna jest weryfikacja w odpowiednim rejestrze i wewnętrznych danych przedsiębiorstwa.

7. Powtarzające się identyfikatory lokali

Numer mieszkania może powtarzać się w różnych budynkach. Podczas scalania eksportów trzeba użyć identyfikatora jednoznacznego dla całego zbioru. Nie usuwaj drugiego wiersza wyłącznie z powodu podobnej nazwy — najpierw sprawdź źródło danych i przypisanie rekordu w CRM.

8. Lokal, którego nie ma w kolejnym pliku

Brak rekordu w nowym raporcie nie oznacza automatycznie, że lokal został sprzedany. Powodem może być zmiana filtra, identyfikatora, etapu inwestycji albo niepełny eksport. Porównywarka plików może wskazać różnicę, ale interpretacja wymaga sprawdzenia faktycznego statusu w CRM.

9. Uzupełnianie pustych pól bez weryfikacji

W projektowej dokumentacji opisano zasady oznaczania określonych pól niemających zastosowania. Nie należy jednak wpisywać tej samej wartości zastępczej we wszystkich pustych komórkach. Trzeba odróżnić brak informacji, brak zastosowania i wartość zerową. Ostateczny sposób wypełniania zależy od definicji pola w aktualnym wzorcu.

10. Brak potwierdzenia publikacji

Poprawny wynik walidatora nie oznacza, że dane zostały przekazane do urzędowego portalu. W firmowym procesie potrzebny jest osobny etap sprawdzenia rezultatu i zapisania dowodu aktualizacji. Warto także przechowywać numer wersji raportu i informację o osobie odpowiedzialnej. Sam plik CSV nie dowodzi wykonania obowiązku.

11. Wynik techniczny a rzeczywista zgodność danych

Plik CSV może mieć prawidłowe nagłówki i taką samą liczbę kolumn w każdym wierszu, a mimo to zawierać błędne ceny albo daty. Dlatego po kontroli technicznej potrzebna jest odrębna weryfikacja merytoryczna. Sprawdź próbkę rekordów w CRM, dokumenty źródłowe i definicję każdego pola. Dodatni wynik walidatora nie potwierdza jeszcze publikacji danych na dane.gov.pl.

Jak sprawdzić plik i porównać ceny?

Zacznij od bezpłatnego walidatora CSV. Następnie przejdź do mapowania danych CRM, korzystając z właściwego wzorca dokumentu. Jeżeli masz dwa kolejne eksporty, użyj porównywarki zmian cen, która wskaże podwyżki, obniżki oraz brakujące rekordy. Przed przekazaniem danych wykonaj także kontrolę organizacyjną opisaną w checkliście raportowania.

FAQ — najczęstsze błędy raportowania

Czy wolno wpisywać zera zamiast brakujących danych?

Nie należy automatycznie zastępować braku informacji zerem. Prawidłowe wypełnienie pola wynika z jego znaczenia oraz aktualnej specyfikacji.

Czy 57 pól jest już ostatecznym wymaganiem?

Liczba 57 pochodzi z projektu rozporządzenia Ministerstwa Cyfryzacji. Przed produkcyjnym raportowaniem należy sprawdzić aktualnie ogłoszony dokument wykonawczy i właściwy wzorzec.

Czy CSV można przesłać bez dodatkowej kontroli?

Kontrola techniczna nie zastępuje weryfikacji prawdziwości cen, dat ani potwierdzenia rzeczywistego przekazania danych.

Źródła: Dz.U. 2026 poz. 1077 i centrum zmian w ustawie. Stan opracowania: 1 listopada 2026 r.