Jak przygotować bazę produktów do eksportu?

Najlepsza zasada jest prosta: nie przygotowuj eksportu według tego, co masz w obecnym systemie. Przygotuj go według tego, czego oczekuje system docelowy.

Zanim więc zaczniesz poprawiać arkusz, pobierz przykładowy plik importowy nowego programu albo dokumentację jego API. Dopiero wtedy wiadomo, jakie kolumny są wymagane, które opcjonalne i w jakim formacie muszą zostać zapisane.

Jeden produkt powinien mieć jeden trwały identyfikator

Najważniejszym polem w bazie jest zwykle SKU, czyli wewnętrzny kod produktu.

Nazwę można zmienić.

„Wiertarka udarowa Bosch XYZ” może za pół roku zostać przemianowana na „Bosch XYZ 850 W – wiertarka udarowa”.

SKU powinno pozostać takie samo.

Przykład:

SKU: BOS-XYZ-850
Nazwa: Wiertarka udarowa Bosch XYZ 850 W

To pozwala innemu systemowi jednoznacznie rozpoznać produkt. Szczególnie ważne jest to przy późniejszych aktualizacjach. Jeśli sklep dostanie kolejny plik z tym samym SKU i nową ceną, może zaktualizować istniejącą pozycję zamiast tworzyć jej kopię.

Przed eksportem dobrze więc sprawdzić, czy nie występują:

Nie warto używać nazwy produktu jako głównego identyfikatora. Nazwy są zbyt łatwo zmieniane.

EAN i GTIN zapisuj jako tekst, nie jak zwykłą liczbę

Jeżeli produkt posiada kod EAN/GTIN, zdecydowanie warto go zachować podczas eksportu.

GTIN może mieć 8, 12, 13 lub 14 cyfr. W Polsce najczęściej spotyka się GTIN-13 zapisywany w kodzie EAN-13. Ostatnia cyfra jest cyfrą kontrolną pozwalającą sprawdzić poprawność numeru.

Problem zaczyna się w Excelu.

Arkusz może potraktować identyfikator jako zwykłą liczbę, usunąć zero znajdujące się na początku albo zmienić format komórki. Dlatego kolumny takie jak:

SKU,
EAN,
GTIN,
kod producenta,

najbezpieczniej traktować jako tekst.

Po przygotowaniu pliku dobrze sprawdzić kilka rekordów bezpośrednio w gotowym CSV, a nie tylko w arkuszu.

Jakie dane warto wyeksportować?

Minimalny zakres zależy od tego, dokąd przenoszona jest baza. Przy migracji pomiędzy programami fakturowymi wystarczy znacznie mniej danych niż przy przenoszeniu całego sklepu internetowego.

Dla zwykłej kartoteki towarowej najczęściej potrzebne będą:

SKU – wewnętrzny identyfikator,
nazwa produktu,
EAN/GTIN, jeśli produkt go posiada,
jednostka miary, np. szt., kg, op., m,
stawka VAT,
cena sprzedaży,
cena zakupu, jeśli ma zostać przeniesiona,
stan magazynowy,
kategoria,
kod producenta.

Przy e-commerce dochodzą zazwyczaj opis, opis krótki, marka, zdjęcia, waga, wymiary, atrybuty, warianty, ceny promocyjne i informacje o dostępności.

Nie ma potrzeby eksportować każdej kolumny tylko dlatego, że obecny system ją posiada. Im więcej zbędnych danych, tym większe ryzyko problemów podczas importu.

Netto czy brutto? Tego nie można zostawić do domyślenia

Kolumna:

Cena = 129,00

jest źle opisana.

Nie wiadomo, czy chodzi o cenę netto, brutto, zakupową, detaliczną czy hurtową.

Znacznie lepiej przygotować osobne pola:

cena_netto
cena_brutto
stawka_vat

albo dokładnie taki zestaw, jakiego wymaga importer.

To szczególnie istotne, jeżeli w bazie znajdują się produkty z różnymi stawkami VAT.

Nie powinno się też wpisywać do jednej komórki wartości typu:

129 zł brutto

jeżeli system oczekuje liczby. Do pola ceny powinno trafić 129.00 albo 129,00 – zależnie od wymaganego formatu – bez symbolu waluty i dodatkowego tekstu.

Produkty wariantowe wymagają osobnego przygotowania

Koszulka występująca w pięciu rozmiarach i czterech kolorach nie powinna być traktowana jak jeden zwykły rekord.

Najczęściej występuje produkt nadrzędny oraz jego warianty:

Koszulka Classic
→ czarna / S
→ czarna / M
→ czarna / L
→ biała / S
→ biała / M

Każdy wariant może posiadać własne SKU, EAN, cenę i stan magazynowy.

Przy eksporcie trzeba zachować relację pomiędzy wariantem a produktem nadrzędnym. W przeciwnym razie nowy sklep może zaimportować dwadzieścia osobnych produktów zamiast jednej koszulki z dwudziestoma kombinacjami.

Przykładowo:

TSHIRT-CLASSIC – produkt główny
TSHIRT-CLASSIC-BLK-S – wariant
TSHIRT-CLASSIC-BLK-M – wariant

Sposób wskazywania produktu nadrzędnego zależy już od systemu docelowego. Nie warto tworzyć własnego formatu, jeśli importer posiada ustaloną strukturę.

Kategorie też trzeba uporządkować

Bałagan w kategoriach jest jednym z najczęstszych problemów ujawniających się podczas migracji.

W starej bazie można spotkać jednocześnie:

Elektronika
elektronika
Elektronika użytkowa
Elektronika > Akcesoria
Akcesoria elektroniczne

Jeżeli wszystko zostanie bez kontroli przeniesione do nowego sklepu, powstanie podobny bałagan.

Eksport jest dobrym momentem na uporządkowanie struktury.

Przy hierarchii kategorii trzeba też sprawdzić sposób jej zapisu wymagany przez importer. Jeden system może oczekiwać osobnych kolumn:

Kategoria główna | Podkategoria

a drugi zapisu:

Elektronika > Akcesoria > Kable

Nie należy tego zgadywać.

Co ze zdjęciami?

Plik CSV nie przenosi samych zdjęć tak, jak archiwum ZIP.

Najczęściej zawiera ich adresy URL albo nazwy plików.

Przykładowo:

https://sklep.pl/media/produkt-123.jpg

Jeżeli system docelowy ma pobrać fotografie z internetu, adres musi być publicznie dostępny. Link prowadzący do panelu administracyjnego, prywatnego Dysku Google albo strony wymagającej logowania może nie zadziałać.

Przy kilku zdjęciach jednego produktu trzeba sprawdzić sposób ich rozdzielania wymagany przez konkretną platformę.

Dobrze również zachować informację, które zdjęcie jest główne. Po imporcie pięciu fotografii w przypadkowej kolejności zdjęciem głównym może zostać detal opakowania zamiast właściwego zdjęcia produktu.

CSV jest prosty, dopóki nie pojawią się przecinki, polskie znaki i Excel

Najczęściej używanym formatem eksportu jest CSV. Jego zaletą jest to, że obsługuje go praktycznie każdy system.

Problem polega na tym, że CSV nie zawsze wygląda tak samo.

Separatorem może być przecinek albo średnik. Tekst może być zapisany w UTF-8 albo innym kodowaniu. Jeden importer oczekuje kropki w cenie 12.50, drugi przecinka 12,50.

Jeżeli opis produktu zawiera przecinki, cudzysłowy lub znaki nowej linii, również muszą zostać prawidłowo zapisane.

Dlatego przed eksportem dużej bazy najlepiej zrobić próbę.

Zamiast zaczynać od 40 000 produktów, wybierz 10–20 możliwie różnych pozycji:

produkt prosty,
produkt z polskimi znakami,
produkt z długim opisem,
produkt z kilkoma zdjęciami,
produkt wariantowy,
produkt bez EAN,
produkt z inną stawką VAT.

Zaimportuj je do systemu testowego i zobacz, co rzeczywiście się wydarzyło.

Taki test wykrywa większość problemów znacznie szybciej niż poprawianie całego katalogu po nieudanej migracji.

Uważaj na puste pola

Puste pole może oznaczać dwie różne rzeczy:

„nie zmieniaj istniejącej wartości”

albo:

„usuń istniejącą wartość”.

To zależy od importera.

Ma to ogromne znaczenie przy aktualizacji istniejących produktów.

Załóżmy, że produkt ma już opis w sklepie, a eksportowany plik zawiera jedynie SKU, cenę i stan. Jeżeli system interpretuje pustą kolumnę „opis” jako polecenie usunięcia treści, po imporcie można wyczyścić tysiące opisów.

Dlatego do aktualizacji cen lub stanów najlepiej używać tylko tych kolumn, które rzeczywiście mają zostać zmienione, jeśli importer na to pozwala.

Stany magazynowe wymagają szczególnej ostrożności

Eksport stanów jest tylko zdjęciem magazynu w określonej chwili.

O godzinie 10:00 eksportujesz:

Produkt A – 50 sztuk.

O 10:15 klient kupuje 8 sztuk.

O 11:00 importujesz stary plik do nowego systemu i nadal wpisujesz 50.

W rzeczywistości powinny być 42.

Przy migracji aktywnego sklepu trzeba więc ustalić moment przełączenia systemów. Można na krótko zatrzymać sprzedaż, wykonać końcowy eksport stanów albo po podstawowej migracji wykonać drugi eksport zawierający wyłącznie zmiany powstałe w międzyczasie.

Im większy sklep, tym ważniejsze staje się takie „okno migracyjne”.

Samo skopiowanie bazy produktów można wykonać wcześniej. Aktualny stan magazynowy najlepiej przenieść możliwie blisko momentu uruchomienia nowego systemu.

Nie przenoś automatycznie starych identyfikatorów systemowych

Obecny program może mieć wewnętrzne ID:

12567

Nie oznacza to, że nowy program powinien otrzymać ten sam numer.

ID bazy danych jest zazwyczaj technicznym identyfikatorem konkretnego systemu. Po migracji nowa aplikacja może nadać produktowi własne ID.

Do łączenia danych pomiędzy systemami lepiej wykorzystywać trwałe oznaczenia biznesowe – przede wszystkim SKU, a w odpowiednich zastosowaniach również GTIN.

Stare ID warto zachować w osobnej kolumnie podczas migracji, jeżeli może pomóc w późniejszym porównaniu danych, ale nie należy zakładać, że zastąpi identyfikator nowego systemu.

KSeF również jest argumentem za uporządkowaną kartoteką

W aktualnej strukturze faktury FA(3) KSeF może przy pozycji zawierać nie tylko nazwę towaru lub usługi, lecz również dodatkowe informacje, takie jak wewnętrzny indeks, GTIN, PKWiU czy CN.

Nie wszystkie te pola trzeba wypełniać przy każdej fakturze. Jeżeli jednak firma już przechowuje takie dane, migracja jest dobrym momentem na ich uporządkowanie.

Nie należy natomiast wpisywać PKWiU albo CN „na wszelki wypadek”. Są to konkretne klasyfikacje i błędny kod jest gorszy niż brak fakultatywnej informacji.

Podobnie z GTIN – jeżeli produkt posiada prawidłowy numer, warto go przenieść. Nie powinno się tworzyć przypadkowych numerów tylko po to, żeby kolumna nie była pusta.

Przed eksportem zrób kontrolę jakości

Przy kilku tysiącach produktów nie ma sensu sprawdzać każdego wiersza ręcznie. Da się jednak wykryć większość problemów automatycznie.

Dobrze znaleźć:

Warto też policzyć rekordy.

Jeżeli przed eksportem było 8 427 aktywnych produktów, a po imporcie system pokazuje 8 193, trzeba ustalić, co stało się z pozostałymi 234, zamiast zakładać, że „pewnie były niepotrzebne”.

Nie nadpisuj starej bazy od razu

Przed migracją należy zachować oryginalny eksport.

Najlepiej przygotować przynajmniej trzy pliki:

produkty_oryginal.csv
produkty_po_czyszczeniu.csv
produkty_do_importu.csv

Pierwszego nie edytujemy.

Jeśli podczas czyszczenia danych okaże się, że formuła usunęła fragment SKU albo Excel zmienił część wartości, można wrócić do danych źródłowych.

Przy dużej bazie wykonanie ponownego eksportu ze starego systemu może być trudniejsze, niż się wydaje – szczególnie jeśli migracja jest wykonywana dlatego, że dotychczasowe oprogramowanie ma zostać wyłączone.

Najpierw mały import, później cała baza

Najgorszy scenariusz to wrzucenie kilkudziesięciu tysięcy rekordów do nowego systemu i dopiero później sprawdzanie efektu.

Lepsza kolejność wygląda tak:

najpierw przygotowanie mapowania kolumn, później import kilkunastu produktów testowych, sprawdzenie wyników, poprawienie pliku, większy test i dopiero na końcu właściwa migracja.

Po imporcie nie należy sprawdzać wyłącznie tego, czy liczba produktów się zgadza.

Otwórz kilka losowych pozycji i porównaj:

SKU, EAN, stawkę VAT, ceny, kategorię, jednostkę, warianty, stan magazynowy i zdjęcia.

Dopiero wtedy wiadomo, że baza została rzeczywiście przeniesiona poprawnie.

W praktyce przygotowanie dobrego eksportu polega więc bardziej na uporządkowaniu danych niż na kliknięciu przycisku „Eksportuj”. Jeżeli kartoteka ma jednoznaczne SKU, poprawne GTIN, jasno opisane ceny i VAT, uporządkowane warianty oraz spójną strukturę kategorii, przeniesienie jej do kolejnego systemu jest stosunkowo proste.

Jeżeli tych zasad nie przestrzegano przez kilka lat, eksport tylko ujawnia problemy, które wcześniej były ukryte w bazie.