Automatyzacja importu i eksportu CSV/XML/API dla e-commerce
Projektujemy importy i eksporty, które nie kończą się na odczytaniu pliku. Proces sprawdza identyfikatory, warianty, ceny, stany i kategorie przed zapisem, a wynik trafia do sklepu, ERP, raportu albo systemu obsługi zamówień w przewidywalnym formacie.
Gdzie najczęściej powstaje chaos integracyjny?
Ta strona dotyczy procesu łączącego kilka systemów: hurtownię, ERP, BaseLinkera, marketplace i sklep. Jeżeli szukasz jednorazowego lub cyklicznego importu katalogu do konkretnej platformy, właściwym miejscem jest import produktów do Shopera z CSV/XML.
Ręczne przeklejanie plików
Zespół traci czas na powtarzalne eksporty, formatowanie i poprawianie arkuszy.
Każdy system ma inny format
Sklep, hurtownia, ERP i marketplace wymagają innych nazw pól, kodowania i struktury.
Brak kontroli zmian
Nie wiadomo, co zmieniło się od ostatniego importu: cena, stan, opis, zdjęcie czy kategoria.
Eksport zamówień jest ręczny
Zamówienia trzeba przepisywać do ERP albo wysyłać w arkuszach bez jednego standardu.
Integracja nie ma logów
Gdy proces się wyłoży, nikt nie wie na którym rekordzie i z jakiego powodu.
Pliki są za duże dla ręcznej pracy
Przy tysiącach produktów Excel staje się narzędziem podglądu, nie bezpiecznym systemem procesu.
Co musi być poukładane, żeby import albo eksport działał stabilnie?
Największy problem w integracjach nie leży w samym pliku CSV, XML czy API, tylko w wyjątkach: brakujących polach, innych nazwach kategorii, wariantach bez relacji, różnicach cen i stanach magazynowych z kilku źródeł. Dlatego proces projektujemy z walidacją, logami i etapem testowym.
Pipeline ma wychwycić problem zanim dotknie sklepu, ERP albo zamówień
W praktyce import nie wykłada się na samym formacie pliku, tylko na wyjątkach. Dlatego przed zapisem sprawdzamy rekordy, relacje i skutki biznesowe zmiany — nie tylko to, czy CSV lub XML da się odczytać.
Duplikaty i błędne klucze
Wykrywamy powtórzone SKU, puste EAN-y, kolizje identyfikatorów i rekordy, które mogłyby nadpisać dobry produkt złym wariantem.
Niespójna struktura katalogu
Sprawdzamy kategorie, warianty parent-child, atrybuty i mapowania pól, żeby import nie tworzył pustych listingów ani produktów bez właściwej relacji.
Ceny, stany i skutki operacyjne
Walidujemy zakresy cen, spadki stanów, brakujące źródła oraz rekordy odstające od reguł, zanim zmiana trafi do sprzedaży lub raportu dla zespołu.
Jeżeli ten sam proces ma obsługiwać zamówienia partnerów, osobnym etapem projektujemy eksport zamówień B2B do ERP: z pozycjami, danymi klienta, statusem, logiem i formatem zgodnym z realną pracą handlowca.
Co automatyzujemy
Jak uruchamiamy pipeline, żeby nie wywrócić produkcji
Źródło i cel
Ustalamy skąd dane wychodzą, dokąd trafiają i które pola są krytyczne.
Format pośredni
Tworzymy format pośredni: jeden sposób opisu produktu, zamówienia lub stanu, zanim dane trafią do kolejnego systemu.
Walidacja
Blokujemy błędy przed zapisem lub eksportem.
Dry-run
Pokazujemy podgląd operacji i raport.
Automatyzacja
Uruchamiamy proces cykliczny albo skrypt do kontrolowanego użycia.
Efekt: import lub eksport, który da się sprawdzić przed zapisem
Stabilny pipeline pokazuje, co zostanie zapisane, co zostanie pominięte i z jakiego powodu. W raporcie dry-run widać nowe rekordy, aktualizacje, pominięcia, błędne EAN/SKU, konflikty wariantów i wartości, których nie wolno opublikować automatycznie.
- Mniej ręcznego przepisywania i formatowania plików.
- Spójny format między sklepem, hurtownią i ERP.
- Lepsza kontrola błędów przed publikacją.
- Możliwość rozwijania procesu o AI i API.
Z czym najczęściej spina się ten proces
Integracje API
Architektura wymiany: REST, webhooki, kolejki, retry i źródło prawdy.
Import Shoper CSV/XML
Ten sam pipeline zawężony do katalogu jednego sklepu na Shoperze.
Eksport zamówień B2B
Zamówienie jako dokument wychodzący do ERP, nie jako plik katalogu.
Walidacja danych
Reguły i progi błędów, które decydują, co wolno zapisać automatycznie.
Poradnik: integracja z hurtownią
Porównanie API, XML i CSV jako źródła danych: aktualność i koszt utrzymania.
Dane produktowe e-commerce
Model danych, do którego pipeline musi doprowadzić każde źródło.
Sześć etapów, przez które przechodzi każdy plik i każde wywołanie API
Ta strona nie dotyczy jednego sklepu. Dotyczy procesu, który spina hurtownię, ERP, BaseLinkera i sklep — i który ma działać bez nadzoru przez kolejne miesiące.
Pobranie
Plik z serwera dostawcy, feed pod adresem albo odpowiedź API. Każde źródło ma określone okno czasowe i alert, gdy dane nie przyjdą.
Normalizacja
Kodowanie, separatory, formaty liczb i dat, jednostki, nazwy kolumn. Dane różnych dostawców sprowadzamy do jednego wewnętrznego formatu.
Walidacja
Reguły wymagane, typy, zakresy i słowniki. Wynik dzieli rekordy na poprawne, wymagające decyzji i odrzucone.
Transformacja
Mapowanie na model docelowy: kategorie, warianty, atrybuty, ceny, jednostki sprzedaży. Tu powstaje właściwy ładunek zapisu.
Zapis
Paczkami, z kontrolą tempa, ponowieniem i kluczem idempotencji. Zapis idzie tylko do pól objętych zakresem procesu.
Raport i archiwum
Podsumowanie przebiegu, log operacji i archiwizacja pliku źródłowego — żeby dało się odtworzyć, co dokładnie przyszło danego dnia.
Skrypt uruchamiany raz to nie jest pipeline
Różnica nie polega na złożoności kodu, tylko na tym, co się dzieje, gdy coś pójdzie nie tak o trzeciej w nocy.
| Aspekt | Jednorazowo | Utrzymywany pipeline |
|---|---|---|
| Uruchomienie | ręczne | harmonogram |
| Brak pliku źródłowego | widać od razu | alert po przekroczeniu okna |
| Błąd w połowie | start od nowa | wznowienie od miejsca przerwania |
| Zmiana struktury źródła | poprawka doraźna | walidacja schematu zatrzymuje zapis |
| Historia | brak | archiwum plików i logów |
| Rozliczalność | trudna | raport z każdego przebiegu |
Co przez ten proces najczęściej przepływa
Szczegóły importu do konkretnego sklepu opisuje osobna strona: import produktów do Shopera. Tutaj chodzi o proces łączący kilka systemów naraz.
Eksport oferty do marketplace i porównywarek to też pipeline
Kanał zewnętrzny nie przyjmuje katalogu sklepu w takiej formie, w jakiej on istnieje. Wymaga własnego zestawu pól, własnej kategoryzacji i własnej definicji dostępności. Feed generowany „na żywo" z bazy sklepu zwykle działa do pierwszej zmiany po stronie odbiorcy.
Co realnie trzeba przetworzyć
- mapowanie kategorii na drzewo odbiorcy, nie na własne nazwy,
- identyfikatory: GTIN/EAN, SKU i kod producenta w formacie wymaganym przez kanał,
- ceny: brutto, waluta, cena promocyjna i jednostkowa jako osobne pola,
- dostępność: próg, poniżej którego produkt wypada z feedu, zamiast wysyłania stanu 0,
- warianty: czy kanał chce jedną ofertę z opcjami, czy osobne pozycje,
- zdjęcia: stabilne URL-e o wymaganym minimalnym rozmiarze,
- walidacja przed publikacją: pozycja bez wymaganego pola nie trafia do pliku.
Ten sam mechanizm obsługuje feed do porównywarki, plik dla hurtowni i eksport oferty do BaseLinkera. Różni się mapa pól, nie architektura procesu.
Struktura pliku, od której zaczyna się każdy import
Zanim ustalimy harmonogram i logi, musi być zgoda co do tego, co reprezentuje jeden wiersz. Te dwa pliki są punktem wyjścia rozmowy — możesz je wypełnić własnymi danymi zamiast opisywać strukturę słowami.
Wzór importu produktów (UTF-8)
Nagłówki kolumn, rodzina wariantowa i EAN zapisany jako tekst — czyli minimalny kontrakt danych wejściowych.
Pobierz wzór CSVMacierz kontroli wariantów
Sprawdzenia, które w utrzymywanym procesie uruchamiamy automatycznie przy każdym przebiegu.
Pobierz macierz wariantówIntegracja z hurtownią
Porównanie API, XML i CSV jako źródła danych: aktualność stanów, obsługa błędów i koszt utrzymania.
Otwórz poradnikImporty i eksporty — pytania
Opisz, co dziś przepisujecie między systemami ręcznie
Nie musisz mieć gotowej specyfikacji. Wystarczy przykładowy plik, link do źródła danych albo opis ręcznego procesu, który dziś zabiera czas zespołu.