Filtr wziął 357 z 418 wierszy eksportu. Reszta ma datę zapisaną tekstem i nie trafiła do żadnego miesiąca

Filtr kosztów w raporcie ma warunek „data księgowania nie wcześniej niż 1 września”. W kolumnie daty 61 z 418 wierszy eksportu to tekst, a nie data. Tekst nie spełnia warunku porównania z datą, więc te 61 wierszy nie weszło do września – i nie weszło do żadnego innego miesiąca.

Arkusz nie zgłosił niczego, bo nie miał czego zgłosić. Policzył to, co dostał, z pominięciem tego, czego nie rozpoznał jako liczby. Objaw ujawnia się dopiero przy ponownym wyciągnięciu tego samego pliku: wrzesień rośnie o 164 900 zł, choć w systemie źródłowym nie zmieniło się nic. Poniżej mechanizm, trzy miejsca, w których typ kolumny się psuje, i jedna kontrola, która to zatrzymuje przed wysłaniem.

Dlaczego raport pominął 61 wierszy i nie pokazał ani jednego błędu?

Przykład liczbowy, warunki podaję jawnie – to konstrukcja obliczeniowa, nie dane z żadnej firmy. Eksport kosztów ma 418 wierszy na 1 147 300 zł. Raport pokazał 982 400 zł, bo 61 wierszy na 164 900 zł wypadło z filtra. To 14,6 proc. wierszy i 14,4 proc. kosztu miesiąca.

Mechanizm ma dwa niezależne piętra i oba są udokumentowane. Pierwsze: daty nie są w arkuszu tekstem ani formatem, tylko liczbami. Dokumentacja Microsoftu stwierdza, że „program Excel przechowuje daty jako uporządkowane liczby kolejne, których można używać w obliczeniach”, gdzie 1 stycznia 1900 r. to liczba 1, a 1 stycznia 2008 r. to 39 448. Napis „03.09.2026” wyglądający na datę jest ciągiem znaków i w porównaniu z liczbą 46 266 nie jest ani mniejszy, ani większy w sensie, którego oczekuje filtr. Wypada z zakresu w obie strony.

Drugie piętro dotyczy sumowania i jest jeszcze cichsze. Dokumentacja funkcji SUMA mówi wprost: „Funkcja SUMA zignoruje wartości tekstowe i zwróci sumę tylko wartości liczbowych”. Kwota zapisana tekstem nie daje błędu, nie daje zera w widocznym miejscu, nie daje żadnego znaku – po prostu nie wchodzi do sumy. Ta sama strona zaznacza, że błąd wartości pojawia się przy zapisie =A1+B1+C1, czyli w konstrukcji, której w raportach prawie nikt nie używa. Przejście z dodawania komórek na SUMA zamienia głośny błąd na cichą różnicę.

Skutek zarządczy: przy przychodzie 1 480 000 zł raport z kosztem 982 400 zł pokazuje marżę 33,6 proc., a z kosztem pełnym 22,5 proc. Jedenaście punktów procentowych rozbieżności, bez jednego komunikatu na ekranie.

Jak w pół minuty policzyć, ile wierszy ma zły typ?

Nie przez patrzenie. Wyrównanie do lewej krawędzi jest sygnałem tylko w arkuszu, w którym nikt nie ustawiał wyrównania ręcznie, a w raporcie po trzech latach formatowania taki warunek nie jest spełniony. Typ trzeba policzyć.

Funkcja CZY.TEKST zwraca PRAWDA, gdy – jak podaje dokumentacja – „wartość odwołuje się do tekstu”, a CZY.LICZBA zwraca PRAWDA, gdy „wartość odwołuje się do liczby”. Istotna jest uwaga z tej samej strony: argumenty tych funkcji nie są konwertowane, więc =CZY.LICZBA("19") zwraca FAŁSZ. To dokładnie ta właściwość, która czyni je użytecznymi do audytu – nie udają, że tekstowa dziewiętnastka jest liczbą.

Dwie formuły do wklejenia obok arkusza surowego, zanim raport cokolwiek policzy:

• Liczba wierszy z datą zapisaną tekstem: =SUMA.ILOCZYNÓW(--CZY.TEKST(surowe!D2:D419))
• Liczba wierszy z kwotą zapisaną tekstem: =SUMA.ILOCZYNÓW(--CZY.TEKST(surowe!F2:F419))

Obie muszą dać zero. Jeśli dają 61 i 0, masz przypadek z początku tekstu: miesiąc jest niekompletny, ale sumy w obrębie tego, co weszło, są prawidłowe. Jeśli dają 0 i 61, sumy są niedoszacowane, a liczba wierszy się zgadza – i to jest wariant, w którym najtrudniej zauważyć cokolwiek.

Skąd biorą się tekstowe daty: które trzy miejsca na drodze z systemu do arkusza je produkują?

Pierwsze to sam import pliku. Dokumentacja Excela stwierdza, że przy plikach CSV program „interpretuje sposób importowania poszczególnych kolumn danych przy użyciu bieżących domyślnych ustawień formatu danych”, i podaje własny przykład kolumny w formacie miesiąc-dzień-rok, która zostaje potraktowana jako rok-miesiąc-dzień. Interpretacja należy do programu i do ustawień komputera, nie do pliku. Dwie osoby otwierające ten sam plik mogą dostać dwa różne wyniki.

Drugie to separatory. Ta sama strona lokuje ustawienie separatora dziesiętnego w opcjach zaawansowanych, w pozycji „Używaj separatorów systemowych”, i ostrzega, że zmiana separatora listy przez ustawienia regionu systemu „spowoduje globalną zmianę na komputerze”. Kwota „1 234.56” z kropką dziesiętną w arkuszu z przecinkiem jako separatorem jest tekstem. Kwota ze spacją nierozdzielającą jako separatorem tysięcy jest tekstem nawet przy prawidłowej kropce.

Trzecie to konwencje systemu źródłowego, których nikt nie zamawiał: minus zapisany na końcu zamiast na początku, zera wiodące w numerach kont i zleceń, nawias zamiast znaku ujemnego. Dokumentacja wprost radzi tu kierunek odwrotny do intuicji – „Możesz też przekonwertować kolumnę liczb zawierającą zera wiodące na tekst” – bo numer konta ma być tekstem i ma zostać tekstem. Problem pojawia się, gdy tekstem zostaje kolumna, która ma być liczbą. Przy pierwszym podejściu do nowego eksportu sprawdź przy okazji jego kompletność, bo eksport bywa obcięty po stronie narzędzia źródłowego, a wtedy typ kolumn jest problemem drugim w kolejności.

Ten sam plik, dwa różne miesiące: co robi kolejność dzień-miesiąc przy 03.09.2026?

Najdroższy wariant nie polega na tym, że wiersz wypada z raportu. Polega na tym, że wchodzi do niego pod inną datą. Przy niejednoznacznym zapisie dnia i miesiąca wiersze z dniem do dwunastego dają się odczytać na dwa sposoby i trafiają do złego miesiąca bez protestu. Wiersze z dniem od trzynastego nie dają się odczytać w złej kolejności i zostają tekstem. Jeden plik rozpada się więc na trzy grupy, a nie na dwie.

Potwierdza to zachowanie funkcji DATA.WARTOŚĆ. Dokumentacja podaje, że =DATA.WARTOŚĆ("22.08.11") zwraca 40777, i zaznacza, że wyniki „mogą być inne niż w tym przykładzie ze względu na ustawienie daty” na komputerze. Do tego dochodzi zachowanie przy pominiętym roku: funkcja przyjmuje bieżący rok z zegara komputera, co w dokumentacji ilustruje przykład zapisu „5-LIP” rozpoznanego jako rok 2011.

Z tej tabeli wynika jedna praktyczna decyzja dotycząca formatu, o który można poprosić dostawcę systemu albo administratora: zapis rok-miesiąc-dzień jest jedynym, który nie ma drugiego odczytu. Jeśli eksport przychodzi w tym formacie, trzy pierwsze wiersze tabeli przestają być Twoim problemem.

Arkusze Google: co zmienia ustawienie regionalne pliku, a czego nie rusza?

W Arkuszach ta sama warstwa nazywa się inaczej i siedzi na poziomie pliku, nie komputera. Dokumentacja podaje, że zmiana ustawień regionalnych i strefy czasowej arkusza zmienia domyślny format waluty, daty i liczb w tym arkuszu, i osobno zaznacza, że zmiana ustawień regionalnych nie zmienia ustawień języka.

Konsekwencja dla zespołu jest konkretna: plik raportu ma jedno ustawienie regionalne dla wszystkich, więc osoba wklejająca eksport ze swojego komputera trafia na parsowanie według ustawienia pliku, nie swojego. To dobra wiadomość, bo wynik jest jeden dla całego zespołu, i zła, bo nikt tego ustawienia nie widzi, dopóki go nie otworzy w menu.

Czego dokumentacja nie rozstrzyga: czy zmiana ustawienia regionalnego przekształca dane już wpisane do arkusza. Mówi o formacie domyślnym, a to nie to samo. Zanim zmienisz to ustawienie w pliku z historią, zrób kopię i sprawdź na niej sumy z zamkniętych miesięcy – pytanie jest tanie do rozstrzygnięcia u siebie i drogie do zgadnięcia.

Naprawa formułą czy ponowny import: która droga nie wraca za miesiąc?

Odruchem jest obłożenie kolumny funkcją konwertującą. Działa, ale dokumentacja funkcji WARTOŚĆ sama podpowiada, dlaczego to nie jest rozwiązanie: funkcja „konwertuje ciąg tekstowy reprezentujący liczbę na liczbę”, przyjmuje tekst „w dowolnym formacie stałej liczbowej, daty lub czasu, rozpoznawanym przez program Microsoft Excel”, a przy formacie nierozpoznanym zwraca błąd wartości. Ta sama strona dodaje, że funkcja jest zwykle zbędna, bo Excel konwertuje tekst na liczby sam, gdy jest to potrzebne, i istnieje dla zgodności z innymi arkuszami. Innymi słowy: jeśli jej potrzebujesz, coś wcześniej w drodze danych jest zepsute.

Kolejność jest taka jak w tabeli i nie jest kwestią gustu. Kolumna pomocnicza ratuje konkretne zamknięcie i ma zostać usunięta razem z nim. Typ ustawiany przy imporcie jest właściwym miejscem, bo działa przed jakimkolwiek liczeniem. Zgłoszenie do dostawcy jest jedyną drogą, która kasuje problem, a nie przenosi go o miesiąc – i jedyną, która nie zależy od tego, kto w tym miesiącu wkleja plik.

Jedna kontrola, która zatrzyma to przed wysłaniem raportu

Celowo jedna, nie pięć. Warstwę kontroli w arkuszu zarządczym – sumę na dwóch drogach, uzgodnienie z systemem, licznik pozycji – opisaliśmy osobno w tekście o pięciu formułach kontrolnych i tu jej nie powtarzam. Kontrola typu jest od tamtych niezależna i wychwytuje coś, czego żadna z nich nie widzi: suma na dwóch drogach zgodzi się idealnie, jeśli obie drogi pomijają te same 61 wierszy.

Wiersz do dopisania ma trzy pola. Po lewej liczba wierszy z tekstem w kolumnie daty, obok liczba wierszy z tekstem w kolumnie kwoty, obok nich suma kwot z eksportu porównana z wierszem podsumowania, który system dokłada na końcu pliku. Pierwsze dwa muszą być zerami, trzecie musi się zgodzić do groszy. Jeśli system nie dokłada wiersza podsumowania, poproś o jego dodanie – to jedno pole w konfiguracji raportu, a daje niezależną drogę do liczby, której arkusz sam sobie nie wystawi.

Przed najbliższym zamknięciem zrób jedno: uruchom licznik typu na eksportach z trzech ostatnich miesięcy, nie tylko na bieżącym. To trzy wklejenia tej samej formuły. Jeśli którykolwiek da wynik różny od zera, raport z tego miesiąca poszedł do zarządu z zaniżonym kosztem i zawyżoną marżą, a nie z odwrotnym błędem – kierunek pomyłki przy pomijaniu wierszy jest zawsze ten sam.

Dalszy wybór zależy od tego, co pokaże ten test. Zero we wszystkich trzech miesiącach oznacza, że problem jest potencjalny i wystarczy, by kontrola weszła na stałe. Wynik różny od zera oznacza decyzję większą niż arkuszowa: trzeba ustalić, które miesiące skorygować, a to pytanie do osoby, która podpisuje raport, nie do osoby, która go składa.