Jak połączyć firmowe pliki CSV i Excel w jeden raport za pomocą Pythona?

Pliki CSV i Excel można połączyć w jeden raport za pomocą Pythona, ale samo sklejenie tabel to za mało. Najpierw trzeba ustalić, które dane mają trafić do wyniku, co oznaczają kolumny i jak postępować z błędnymi wierszami. Dopiero potem warto pisać skrypt, który odczyta pliki, ujednolici ich zawartość i przygotuje raport wraz z informacją o problemach.

Takie rozwiązanie ma sens zwłaszcza wtedy, gdy pracownik regularnie wykonuje te same czynności na plikach o podobnej strukturze. Nie wymaga użycia AI ani wysyłania danych do zewnętrznej usługi. Może działać lokalnie, o ile środowisko firmy pozwala zainstalować potrzebne biblioteki i uruchomić skrypt.

Kiedy warto automatyzować raport?

Dobrym kandydatem jest raport przygotowywany co tydzień lub miesiąc z kilku źródeł. Jeżeli jego opracowanie polega na otwarciu plików, zmianie nazw kolumn, sprawdzeniu wartości i obliczeniu tych samych sum, większość tych kroków można opisać jako reguły.

Przed decyzją warto zapisać czas potrzebny na ręczne przygotowanie raportu oraz jego sprawdzenie. Następnie porównać go z szacowanym kosztem przygotowania i utrzymania skryptu. To nie musi być dokładna wycena: chodzi o ustalenie, czy proces powtarza się wystarczająco często, by inwestycja miała sens.

Ręczna praca w arkuszu może wystarczyć, gdy raport jest jednorazowy, plików jest niewiele albo za każdym razem potrzebna jest inna analiza. Automatyzacja nie zastąpi też decyzji o tym, którą z dwóch sprzecznych wartości należy uznać za prawidłową.

Łączenie istniejących plików jest innym zadaniem niż porządkowanie nowych zapytań z formularza przed wysłaniem ich do CRM. W obu przypadkach trzeba jednak ustalić format danych i sposób obsługi braków.

Co ustalić przed napisaniem skryptu?

Najlepszym początkiem jest krótki opis procesu i komplet przykładowych plików, najlepiej obejmujący także przypadki nietypowe. Do pilotażu można użyć danych testowych lub odpowiednio przygotowanych kopii, zamiast udostępniać pełne dane produkcyjne.

• Źródła: jakie pliki mają być dostarczane, przez kogo i gdzie? Czy każdy jest obowiązkowy?
• Częstotliwość: za jaki okres powstaje raport i kiedy dostępne są dane?
• Zakres: które arkusze, kolumny i wiersze mają zostać uwzględnione?
• Znaczenie danych: czy kwoty są netto czy brutto, w jakiej walucie i do jakiej daty się odnoszą?
• Wynik: czy potrzebna jest jedna lista transakcji, zestawienie sum, czy oba widoki?
• Odpowiedzialność: kto dostarcza pliki, wyjaśnia błędy i sprawdza raport przed przekazaniem dalej?

Warto też ustalić zachowanie przy braku pliku. Jeśli raport ma obejmować trzy obowiązkowe źródła, jego wygenerowanie z dwóch bez ostrzeżenia może być bardziej szkodliwe niż zatrzymanie procesu. Podobnie nieznana kolumna lub zmieniona nazwa arkusza powinna uruchomić wcześniej uzgodnioną reakcję.

CSV i Excel: te same dane, różne formaty

Separator, kodowanie i zapis wartości w CSV

Plik CSV jest tekstem tabelarycznym, ale nie każdy wygląda tak samo. Kolumny mogą być rozdzielone przecinkiem lub średnikiem, a pola zawierające separator mogą być ujęte w cudzysłowy. Znaczenie ma także kodowanie, szczególnie dla polskich znaków.

Przykładowo zapis Produkt;Kwota sugeruje separator średnika, ale nie określa jeszcze kodowania ani sposobu zapisu liczb. Wartość 1 250,50 trzeba odczytać inaczej niż 1250.50. Nie należy usuwać wszystkich przecinków bez sprawdzenia ich znaczenia: mogłoby to zmienić kwotę.

Standardowy moduł CSV w Pythonie pozwala określić separator i reguły cytowania. Dokumentacja zaleca otwieranie plików CSV z parametrem newline=''. W praktyce należy też jawnie ustalić kodowanie pliku, zamiast zakładać, że każdy dostawca używa tego samego.

Arkusze i typy danych w Excelu

Skoroszyt Excel może zawierać kilka arkuszy: dane, instrukcję i zestawienie kontrolne. Nie wszystkie powinny automatycznie trafić do raportu. W pandas.read_excel można wskazać konkretny arkusz lub odczytać wiele arkuszy; obsługa zależy od formatu pliku i odpowiedniego silnika.

Trzeba również sprawdzić, jak odczytywane są daty, puste komórki i identyfikatory. Kod produktu 00123 nie powinien zmienić się na 123, jeśli zera są częścią identyfikatora. Jeżeli jednak Excel przechowuje liczbę i tylko wyświetla zera za pomocą formatowania, samo ustawienie typu tekstowego przy odczycie może nie odtworzyć oryginalnego kodu. Taką regułę trzeba ustalić na podstawie źródła.

Przykład: trzy pliki sprzedażowe

Załóżmy hipotetycznie, że firma otrzymuje co miesiąc trzy pliki. Pierwszy to CSV z kolumnami „Produkt” i „Kwota”. Drugi to Excel z kolumnami „Nazwa produktu” i „Wartość sprzedaży”. Trzeci zawiera dwa arkusze z danymi dla różnych działów. Celem jest jedna lista sprzedaży i zestawienie sum według produktu.

Przed łączeniem trzeba potwierdzić, że wszystkie kwoty opisują tę samą miarę, okres i walutę. Sama zmiana nazwy kolumny nie sprawi, że sprzedaż brutto stanie się porównywalna ze sprzedażą netto.

Źródło	Kolumna źródłowa	Kolumna w raporcie	Reguła
CSV	Produkt	produkt	Usuń zbędne spacje na początku i końcu.
Excel 1	Nazwa produktu	produkt	Zachowaj nazwę jako tekst.
Excel 1	Wartość sprzedaży	kwota	Odczytaj zgodnie z ustalonym formatem liczby.
Excel 2	Produkt i kwota w dwóch arkuszach	produkt, kwota	Uwzględnij oba wskazane arkusze i zapisz ich nazwy.

Do każdego wiersza warto dodać nazwę pliku i arkusza oraz, jeśli to możliwe, numer wiersza źródłowego. Dzięki temu osoba sprawdzająca raport może odnaleźć problem bez przeszukiwania wszystkich dokumentów. Numer musi odnosić się do rzeczywistego układu pliku, także wtedy, gdy przed nagłówkiem znajdują się dodatkowe wiersze.

Proces może przebiegać w pięciu krokach:

1. Sprawdzenie obecności wymaganych plików i arkuszy oraz wymaganych kolumn.
2. Odczyt danych zgodnie z formatem właściwym dla każdego źródła.
3. Zmiana nazw kolumn i przekształcenie wartości według uzgodnionych reguł.
4. Oddzielenie wierszy z błędami od danych dopuszczonych do raportu.
5. Połączenie poprawnych danych, obliczenie zestawienia i przygotowanie kontroli.

Przykładowy wiersz bez nazwy produktu może trafić do listy błędów z powodem „brak produktu”. Jeśli kwota ma nieznany format, nie należy zastępować jej zerem. Wiersz powinien zachować wartość źródłową i informację potrzebną do wyjaśnienia problemu.

Jak wygląda samo łączenie w pandas?

Poniższy fragment pokazuje wyłącznie mechanizm połączenia wcześniej wczytanych i sprawdzonych tabel. Zakłada, że każda ma już te same kolumny, a błędne wiersze zostały oddzielone. Nie jest kompletnym skryptem produkcyjnym.

import pandas as pd

# Tabele przygotowane wcześniej z trzech plików i wybranych arkuszy.
tabele = [csv_poprawne, excel1_poprawne, arkusz_a_poprawne, arkusz_b_poprawne]

polaczone = pd.concat(tabele, ignore_index=True)
raport = polaczone.groupby("produkt", as_index=False)["kwota"].sum()

concat dokłada wiersze z kolejnych tabel, a grupowanie tworzy sumę dla każdego produktu. To odpowiednie podejście, jeśli źródła opisują ten sam rodzaj zdarzeń. Gdy jeden plik zawiera transakcje, a drugi słownik produktów, może być potrzebne łączenie po kluczu, a nie dokładanie wierszy. Wtedy należy sprawdzić, czy klucz jest unikalny i czy każda transakcja znalazła właściwy odpowiednik.

Przy kwotach pieniężnych ustal sposób reprezentacji i zaokrąglania, na przykład pełne grosze lub liczby dziesiętne. Nie opieraj kontroli finansowych wyłącznie na przypadkowym zaokrągleniu wartości zmiennoprzecinkowych. Dokumentacja pandas pokazuje także podstawy odczytu i zapisu tabel, ale parametry trzeba dopasować do własnych plików.

Jak sprawdzić, czy raport jest kompletny?

Poprawnie uruchomiony skrypt nie dowodzi, że dane źródłowe są prawdziwe ani że raport obejmuje wszystko. Kontrola powinna odpowiadać na dwa pytania: czy przetworzono właściwe dane oraz czy wynik odpowiada ustalonym regułom.

• Liczba wierszy: dla każdego źródła porównaj liczbę wczytanych wierszy z liczbą przyjętych i odrzuconych. Ustal, jak traktować puste wiersze i nagłówki.
• Sumy: porównaj kwoty w plikach z kwotami przyjętymi i odrzuconymi. Jeśli części wierszy nie da się odczytać jako liczb, oznacz sumę jako niepełną zamiast sugerować pełne uzgodnienie.
• Braki: pokaż liczbę brakujących produktów, dat lub kwot oraz źródła tych braków.
• Duplikaty: ustal klucz, na przykład identyfikator transakcji i pozycję. Dwa wiersze o tej samej kwocie nie muszą być duplikatem. Najpierw je oznacz, a usuwanie zastosuj tylko według zatwierdzonej reguły.
• Zakres: sprawdź okres, walutę, komplet plików i liczbę uwzględnionych arkuszy.

Przy pierwszym uruchomieniu warto porównać wynik z raportem przygotowanym ręcznie dla tego samego zestawu danych. Różnicę trzeba prześledzić do konkretnych wierszy: może wynikać z błędu skryptu, ale też z wcześniej niezauważonej reguły stosowanej przez pracownika.

Raport kontrolny powinien zawierać informację o czasie uruchomienia, użytych plikach, liczbie błędów i statusie procesu. Z góry ustal, czy pojedynczy błędny wiersz oznacza wstrzymanie całego raportu, czy dopuszczalny jest wynik częściowy. Jeśli wynik jest częściowy, odbiorca musi widzieć to oznaczenie.

Bezpieczeństwo plików i koszt utrzymania

Pliki wejściowe, lista błędów i raport mogą zawierać te same poufne informacje. Określ więc dostęp do każdego z nich, miejsce przechowywania, czas retencji oraz sposób bezpiecznego przekazania wyniku. Lista błędów nie powinna trafiać do szerszego grona tylko dlatego, że jest plikiem pomocniczym.

Osobnym zagrożeniem jest CSV injection opisany przez OWASP: program arkuszowy może potraktować zawartość pola z niezaufanego źródła jako formułę. Problem dotyczy na przykład nazw lub komentarzy eksportowanych do pliku otwieranego później w arkuszu. OWASP zaznacza, że nie ma jednego zabezpieczenia odpowiedniego dla wszystkich programów i zastosowań. Ustal sposób traktowania takich pól, przetestuj go w używanym programie i rozważ wpływ na dalsze przetwarzanie danych. Nie zakładaj, że samo ujęcie wartości w cudzysłów rozwiązuje problem.

Python można wykorzystywać bezpłatnie także komercyjnie. Przy rozwiązaniu lokalnym nie ma osobnej opłaty za zewnętrzną usługę raportową, ale pozostają koszty przygotowania reguł, testów, utrzymania i ewentualnej infrastruktury. Trzeba też uwzględnić aktualizacje bibliotek oraz czas potrzebny na reakcję, gdy dostawca zmieni plik.

Warto zaplanować, kto otrzyma komunikat o błędzie i jak wznowić pracę po poprawieniu źródła. Jeśli proces ma działać bez stałego nadzoru, przydadzą się także zasady ponawiania oraz zapobiegania ponownemu przetworzeniu tych samych danych. Powiązane problemy opisujemy w artykule o błędach, ponowieniach i kontroli duplikatów w automatyzacjach.

Plan pierwszego pilotażu

1. Wybierz jeden raport. Najlepiej taki, którego wynik jest regularnie potrzebny, a sposób przygotowania można opisać.
2. Przygotuj dane testowe. Uwzględnij poprawne pliki oraz przykłady braków, duplikatów, zmienionych nagłówków i nieprawidłowych kwot.
3. Spisz reguły i kryteria akceptacji. Określ wymagane źródła, kolumny wyniku, dopuszczalne błędy oraz sposób uzgodnienia liczby wierszy i sum.
4. Uruchom próbę równolegle z dotychczasowym procesem. Porównaj wyniki za ten sam okres i wyjaśnij różnice przed wykorzystaniem raportu w pracy.
5. Wyznacz osoby odpowiedzialne. Ustal, kto sprawdza wynik, kto naprawia dane źródłowe i kto aktualizuje skrypt.
6. Zdecyduj o kolejnym kroku. Jeśli formaty zmieniają się często albo pliki są zbyt duże dla dostępnego środowiska, rozważ inne narzędzie lub dodatkowe mechanizmy kontroli.

Do rozmowy o pilotażu wystarczą przykładowe pliki, opis obecnego raportu i lista decyzji, które dziś podejmuje pracownik. Jeśli potrzebujesz pomocy w ocenie procesu, zobacz rozwiązania i automatyzacje dla firm. Sam raport nie musi zawierać AI: najważniejsze, aby jego reguły były zrozumiałe, a wynik możliwy do sprawdzenia.