Mapowanie danych w integracji systemów: jak zapewnić spójność i poprawność

Mapowanie danych przypisuje pole źródłowe do pola docelowego oraz określa sposób przekształcenia jego wartości. SKU z ERP może trafić do pola SKU w sklepie bez zmiany, a cena wymagać uzgodnienia waluty, podstawy netto lub brutto i sposobu naliczenia VAT.

Reguła mapowania określa znaczenie pola, format wartości i oczekiwany wynik. Transformacja danych oznacza zmianę wartości lub formatu, na przykład zamianę statusu "w realizacji" na kod "processing", jeśli taki status ma system docelowy.

API, czyli interfejs programistyczny, określa sposób komunikacji systemów. Mapowanie określa znaczenie przesyłanych danych. Więcej o całym przepływie między aplikacjami opisujemy w przewodniku po integracji systemów i API.

Przy wymianie danych sklepu i BaseLinkera trzeba uzgodnić obiekty oraz reguły przesyłania ich między wykorzystywanymi systemami. Integracja z BaseLinkerem może obejmować analizę tych przepływów przed uruchomieniem synchronizacji.

Przed wdrożeniem zmapuj produkty, warianty, stany, ceny, klientów, adresy, płatności, dostawy i statusy. Najpierw ustal pola, które identyfikują rekord, zmieniają wartość transakcji lub warunkują realizację zamówienia.

Tabela ułatwia sprawdzenie, które informacje wymagają reguły i jak wykryć błąd przed zapisem.

Walidacja powinna sprawdzać także powiązania między rekordami. Pozycja zamówienia bez istniejącego produktu może przejść kontrolę formatu, ale nie pozwoli poprawnie zrealizować zamówienia.

Lista obiektów wynika z faktycznej ścieżki danych. Jeśli sklep wysyła zamówienie do ERP, a ERP odsyła status, opisz pola w obu kierunkach.

Tabela mapowania powinna zawierać obiekt, pole źródłowe i docelowe, format, regułę, wartość domyślną, walidację oraz właściciela decyzji. Dodaj przykład wejścia i oczekiwanego wyniku, aby osoba wdrażająca mogła odtworzyć regułę.

Przykład ceny zakłada, że cena źródłowa wynosi 100,00 PLN netto, produkt ma stawkę VAT 23%, a sklep oczekuje ceny brutto w PLN; oczekiwany wynik to 123,00 PLN brutto. Inna stawka VAT, waluta lub typ ceny wymaga osobnej reguły.

Pełna karta powinna wskazywać wartość domyślną, wersję reguły i osobę zatwierdzającą. Wartości domyślnej używaj tylko wtedy, gdy brak pola nie zmienia znaczenia operacji. Brak SKU nie powinien tworzyć produktu z przypadkowym kodem.

Administrator potwierdza format techniczny, a właściciel procesu zatwierdza znaczenie danych i wyjątki. Zapisz też datę zatwierdzenia i identyfikator reguły.

Różnice w słownikach rozstrzygaj zatwierdzoną tabelą wartości źródłowych i docelowych, a formaty normalizuj przed zapisem. Przykłady w tabeli pokazują reguły, które należy dopasować do słowników używanych w firmie.

Przy różnych walutach zapisz, czy integracja tylko przekazuje cenę, czy również ją przelicza. Reguła przeliczenia powinna wskazywać źródło kursu i moment jego pobrania.

Nieznanego statusu nie zamieniaj automatycznie na podobną wartość docelową. Skieruj go do wyjątku do czasu zatwierdzenia nowej reguły przez właściciela procesu.

Dla dat określ strefę czasową i zachowanie przy braku informacji o strefie, jeśli wpływa to na zamówienia lub dokumenty. Zgodny zapis daty nie gwarantuje, że systemy rozumieją moment zdarzenia identycznie.

System źródłowy określaj osobno dla każdego pola, zgodnie z tym, gdzie informacja powstaje i kto może ją zmieniać. ERP może być źródłem ceny, system magazynowy źródłem stanu, a sklep źródłem opisu marketingowego.

W karcie przepływu zapisz źródło, kierunek synchronizacji, częstotliwość i sposób rozstrzygania konfliktu. Jeśli oba systemy mogą zmienić to samo pole, ustal pierwszeństwo albo wymagaj ręcznego zatwierdzenia rozbieżności.

Gdy ERP i sklep zmienią cenę przed synchronizacją, integracja powinna zapisać konflikt i wskazać osobę odpowiedzialną za decyzję. Automatyczne nadpisanie utrudnia ustalenie, która wartość jest właściwa.

Perspektywa KC Mobile. W projektowaniu integracji oddzielamy odpowiedzialność za dane od odpowiedzialności za ich przesłanie. Taki podział wskazuje, kto zatwierdza zmianę, gdy systemy przechowują różne wartości.

Dokumentacja Comarch ERP XL 2024 opisuje mechanizm wersjonowania XL API, w którym pole "Wersja" pozwala dopasować strukturę przekazywaną przez aplikację do struktur używanych wewnętrznie. Dokument utworzono 28.04.2020; sprawdziliśmy wersję dokumentacji 2024 dnia 18.10.2026. W integracji opartej na XL API ustal wersję używaną przez połączenie i sprawdź zgodność struktur przy zmianie interfejsu.

Walidacja mapowania powinna sprawdzać wymagane pola, formaty, zakresy, unikalność i powiązania między rekordami. Przed uruchomieniem automatyzacji przygotuj próbkę danych typowych oraz przypadki brzegowe.

Sprawdź co najmniej:

• obecność SKU i identyfikatora zamówienia;
• zgodność ceny z walutą, typem ceny i stawką VAT;
• istnienie produktu wskazanego w pozycji zamówienia;
• dozwoloną wartość statusu i jednostki;
• unikalność klucza używanego do aktualizacji rekordu.

Próbka powinna zawierać rekord poprawny, rekord z brakującym polem, duplikat, wartość spoza zakresu i wartość nieznaną słownikowi. Dla każdego przypadku określ, czy integracja go zaakceptuje, odrzuci czy skieruje do kolejki korekt.

Sprawdź wynik w systemie docelowym, a nie wyłącznie w logu technicznym. Poprawny format nie potwierdza, że rekord zachował znaczenie biznesowe.

Ustal kryterium poprawności dla każdego pola. Dla stanu magazynowego sprawdź wartość i właściwy magazyn, a dla klienta poprawne przypisanie zamówienia do kartoteki.

Błędne dane odrzucaj, kieruj do kolejki korekt albo uzupełniaj wartością domyślną zgodnie z zatwierdzoną regułą. Wybór zależy od tego, czy brak zmienia znaczenie lub bezpieczeństwo operacji.

Brak SKU powinien zatrzymać import produktu, ponieważ bez stabilnego klucza system może utworzyć duplikat. Brak opcjonalnego opisu może pozwolić na synchronizację, jeśli system docelowy dopuszcza pustą wartość.

Log błędu powinien zawierać identyfikator rekordu, pole, wartość wejściową, przyczynę odrzucenia i czas próby. Alert kieruj do osoby, która może poprawić dane. Ponawiaj synchronizację po korekcie wartości lub reguły.

Ustal limit ponowień i ochronę przed podwójnym utworzeniem dokumentu. Ponowienie tej samej wiadomości powinno aktualizować właściwy rekord albo zakończyć się bez duplikatu.

Oddziel błędy danych od awarii technicznych. Niepoprawny NIP wymaga sprawdzenia wartości wejściowej, a niedostępność systemu docelowego może wymagać ponowienia transmisji.

Właściciel procesu powinien utrzymywać dokumentację mapowania, historię zmian i testy regresji. Aktualizacja systemu może dodać pole, zmienić słownik lub format, dlatego przed wdrożeniem zmiany sprawdź jej wpływ na reguły.

Porównaj nową specyfikację z tabelą mapowania, wskaż zmienione reguły i zatwierdź je z właścicielami danych. Test regresji powinien ponownie sprawdzić rekord poprawny, brak wartości, konflikt, duplikat i ponowienie.

Checklistę odbioru zamknij po potwierdzeniu, że:

• każde pole ma źródło, cel i właściciela decyzji;
• każda transformacja ma przykład wejścia i oczekiwany wynik;
• wymagane pola i wartości brzegowe mają regułę walidacji;
• błędy trafiają do logu i wskazanej osoby;
• ponowienie nie tworzy niezamierzonych duplikatów.

Opis powiązanych przepływów wielokanałowych znajdziesz w poradniku o integracji Allegro z WooCommerce. Jeśli mapowanie obejmuje sklep i BaseLinker, wdrożenie integracji dla sprzedaży może objąć analizę obiektów, reguły pól i testy przed uruchomieniem synchronizacji.

• Błędy we wdrożeniach integracji systemów i sposoby ich wykrywania
• Jak zaprojektować przenoszenie i aktualizację zamówień między ERP a sklepem
• Jak zintegrować zamówienia ze sklepu internetowego z systemem księgowym?
• Integracja API krok po kroku: jak połączyć sprzedaż z operacjami
• Integracja Comarch EDI z Comarch Optima: dokumenty, mapowanie i kontrola błędów