Poradnik · · 4 min
Integracja XML: sprawdź stan produktu, nie tylko połączenie
Działające pobieranie pliku nie potwierdza aktualnego magazynu. Porównaj identyfikator produktu, stan, cenę i czas aktualizacji.
Połączenie i poprawne dane to dwa testy
Integracja może bez błędu pobierać plik, a nadal mapować niewłaściwy wariant albo pokazywać nieaktualną cenę. Zacznij od jednego produktu z jednoznacznym identyfikatorem. Nie sprawdzaj całego katalogu tylko po nazwie.
W oficjalnych programach z naszej bazy występują XML, CSV i API. To formaty i sposoby przekazywania danych, nie potwierdzenie jakości realizacji. Warunki dostępu oraz aktualizacji sprawdź u wybranego dostawcy.
Zbuduj kartę porównania
Dla produktu zanotuj identyfikator w źródle i w sklepie, wariant, cenę, stan oraz datę odczytu. Nie zakładaj, że nazwa pola quantity zawsze oznacza tę samą rzecz. Może wymagać mapowania zgodnego z dokumentacją integracji.
| Pole | Źródło dostawcy | Widok sklepu | Wynik testu |
|---|---|---|---|
| Identyfikator | Zapisz SKU lub ID | Zapisz SKU lub ID | Czy to ten sam wariant? |
| Cena | Podstawa i waluta | Podstawa i waluta | Czy przeliczenie jest poprawne? |
| Stan | Wartość i jej znaczenie | Dostępność dla klienta | Czy klient może kupić? |
| Aktualizacja | Moment pobrania | Moment aktualizacji | Czy opóźnienie jest znane? |
Wykonaj scenariusz braku towaru
Użyj bezpiecznego produktu testowego lub środowiska testowego, zgodnie z możliwościami integracji. Sprawdź, czy po informacji o niedostępności oferta przestaje przyjmować zamówienia tak, jak zaplanowałeś. Nie zmieniaj rzeczywistego stanu dostawcy w celu próby.
Jeżeli nie masz testowego wariantu, poproś o opis procedury i sprawdź ją na najbliższej rzeczywistej zmianie. Zaznacz, że scenariusz nie został jeszcze wykonany. Sama deklaracja nie jest wynikiem testu.
Cena potrzebuje osobnej kontroli
Wskaż walutę, podstawę podatkową i własną regułę narzutu. Porównaj wynik na dwóch wartościach testowych. Błąd ceny może być bardziej kosztowny niż brak aktualizacji zdjęcia.
Zapisz także, co dzieje się, gdy plik jest niekompletny lub połączenie przestaje działać. Sklep powinien mieć świadomie wybrany sposób obsługi tego stanu, zamiast pokazywać ostatnią wartość bez informacji o jej wieku.
Zachowaj dowód i aktualizuj kartę
Do raportu dołącz fragment danych bez informacji o klientach oraz zrzut swojej oferty. Zapisz spodziewany i faktyczny wynik. Po zmianie mapowania uruchom te same scenariusze ponownie.
W bazie dostawców odróżniamy publiczny opis integracji od własnego zamówienia próbnego. Ta sama zasada działa tu: dostęp do pliku, poprawna synchronizacja i doręczenie produktu to trzy różne dowody.
- Identyfikator odpowiada właściwemu wariantowi.
- Cena i waluta mają świadomie wybrane mapowanie.
- Stan oznacza to, co pokazujemy klientowi.
- Znam moment ostatniej aktualizacji.
- Mam procedurę na brak danych lub awarię.
Przypadek testowy: plik jest nowy, ale informacja stara
Przyjmij fikcyjny odczyt: wariant TEST-B-02 ma stan 8 o godzinie 09:00. Plik pobierasz o 09:12, a sklep pokazuje go od 09:14. Są tu trzy zegary: czas danych, pobrania i zastosowania. Wiek informacji w sklepie o 09:14 wynosi w tym ćwiczeniu 14 minut, nawet jeśli samo ostatnie pobranie zakończyło się dwie minuty wcześniej.
Taki rachunek wymaga porównywalnej strefy czasowej i wiarygodnego znaczenia pól. Brak znacznika czasu w źródle nie pozwala odtworzyć wieku danych. Zapisz wtedy nieznane, a nie zero minut. Nie zakładamy też, że każdy dostawca aktualizuje plik co określoną liczbę minut. To warunek konkretnej integracji do sprawdzenia w jej dokumentacji.
| Zdarzenie | Syntetyczny czas | Pytanie |
|---|---|---|
| Dane źródłowe | 09:00 | Czego dotyczy data? |
| Pobranie | 09:12 | Czy otrzymano cały plik? |
| Zastosowanie | 09:14 | Który wariant zmienił się w sklepie? |
| Wiek informacji | 14 minut | Czy wszystkie zegary są porównywalne? |
Stan do sprzedaży nie zawsze oznacza fizyczny stan magazynu
Oficjalna dokumentacja Shopify rozróżnia między innymi ilość fizycznie posiadaną, dostępną, zarezerwowaną i przychodzącą. Dlatego samo pole o nazwie stock w obcym pliku nie określa, którą ilość powinien zobaczyć klient. Najpierw ustal definicję u źródła; dopiero potem mapuj wartość do platformy sklepu. Nazwy z naszego ćwiczenia nie są schematem XML żadnej hurtowni.
Przykładowo źródło może deklarować 8 jednostek, z których 3 są już zarezerwowane. Nie wolno samodzielnie odejmować tych liczb, jeżeli dokumentacja mówi, że podane 8 to już ilość dostępna. Wtedy odjęcie rezerwacji drugi raz zaniży stan. Jeżeli 8 oznacza ilość fizyczną, reguła może być inna. Najważniejszy wynik próby to udokumentowane znaczenie pola, nie wybór liczby, która wygląda wiarygodnie.
Przerwanie i ponowienie aktualizacji bez ukrytego nadpisania
W środowisku testowym przygotuj drugi odczyt tego samego wariantu ze stanem 0. Sprawdź rezultat po zastosowaniu pliku oraz po odświeżeniu strony klienta. Następnie użyj starszego odczytu ze stanem 8 i zanotuj, co zrobi integracja. Czy wraca nieaktualna dostępność? Nie zakładamy, że system automatycznie rozpoznaje kolejność zdarzeń; to właśnie warunek do zbadania.
Osobny scenariusz dotyczy niepełnego pliku. Nieobecny rekord i rekord z wartością zero nie muszą znaczyć tego samego. Zapisz spodziewane działanie dla obu sytuacji przed próbą. Jeśli integracja nie daje bezpiecznego sposobu odtworzenia awarii, nie wprowadzaj jej na żywym katalogu. Oznacz scenariusz jako niewykonany i uzyskaj opis sposobu obsługi od osoby odpowiedzialnej za system.
Raport odbioru, który pozwala znaleźć błąd mapowania
Raport powinien łączyć identyfikator wariantu, odczyt źródła, daty, regułę mapowania i widok dla klienta. Nie wystarczy zrzut ekranu z napisem synchronizacja zakończona. Gdy stan jest poprawny, ale cena różni się od oczekiwanej, zapisz osobny problem ceny; test dostępności nie potwierdza waluty, podstawy kwoty ani sposobu narzutu.
Do ćwiczenia użyj pobieranego CSV jako własnej karty odczytów, a nie pliku importowego platformy. Zmień czas zastosowania na 09:20 i policz wiek informacji: 20 minut od 09:00. Następnie usuń czas źródła i wskaż, którego wniosku nie można już uzasadnić. Dzięki temu wynik próby jest powtarzalnym zestawem obserwacji, a nie deklaracją, że każdy XML automatycznie rozwiązuje problem stanów.
Kolejność sprawdzenia w tym przykładzie
Czas źródła → Mapowanie wariantu → Widok klienta. To schemat ćwiczenia, nie wynik rzeczywistego sklepu.
Pobierz dane do własnego ćwiczenia
CSV zawiera wyłącznie przypadek syntetyczny opisany powyżej. To karta do samodzielnego sprawdzenia, nie wynik sklepu ani plik do importu w platformie.
Źródła i metoda
Autorska karta zadania i jawny model porównania. Przykłady są ilustracjami, nie wynikami konkretnego sklepu lub testu dostawcy. Sprawdź aktualne warunki w źródłach przed wdrożeniem. Rozwinięcie z 9.10.2026: własny przypadek syntetyczny, karta ćwiczenia i warunki interpretacji. Nie wykonano zamówienia ani testu systemu dostawcy na potrzeby przykładu.
- Shopify: model i przebieg dropshippingu — sprawdzono: 2026-10-08
- Shopify: konfiguracja sklepu — sprawdzono: 2026-10-08
- Shopify: stany zapasów i ich znaczenie — sprawdzono: 2026-10-09
Daty sprawdzenia podano przy źródłach. Przykłady liczbowe są ilustracją obliczeń, a nie danymi konkretnego sklepu.