IdoSell Bridge: modele integracji IdoSell z systemami magazynowo-księgowymi

IdoSell Bridge przekazuje dane między panelem IdoSell a obsługiwanym programem magazynowo-księgowym. Gotowy konektor realizuje określony zakres funkcji dla danego ERP, a Uniwersalny Tryb Pracy (UDB) umożliwia połączenie IdoSell z innym systemem przez wspólną strukturę bazy danych.

W UDB Bridge komunikuje się z panelem i bazą UDB, natomiast aplikacja firmy przenosi dane pomiędzy UDB a ERP. IdoSell opisuje UDB jako bufor i wskazuje silniki MS SQL Server oraz MySQL Server. Własna integracja przez API korzysta z udostępnionych metod, ale nie każda operacja dostępna w panelu ma odpowiednik w API. IdoSell Downloader obsługuje węższy przypadek: aktualizację danych towarowych z XML lub CSV.

IdoSell publikuje listę obsługiwanych programów ERP oraz tabelę funkcji Bridge dla poszczególnych programów. Tabela rozróżnia funkcje dostępne, niemożliwe technicznie i planowane, więc sama obecność ERP na liście nie potwierdza obsługi każdego pola. Jeśli firma korzysta także z BaseLinkera, integracja BaseLinkera dla sprzedaży wielokanałowej może być osobnym elementem przepływu zamówień i stanów, a nie zamiennikiem IdoSell Bridge.

Źródło prawdy należy ustalić osobno dla produktów, cen, stanów i zamówień przed uruchomieniem synchronizacji. Gotowy Bridge obsługuje funkcje wskazane dla danego ERP, UDB obejmuje towary, zamówienia i inne obszary, a Downloader aktualizuje wyłącznie dane towarowe z pliku.

IdoSell opisuje, że Downloader mapuje kolumny lub tagi XML na pola towarów i może identyfikować rekordy po ID, kodzie zewnętrznym lub kodzie producenta. UDB obejmuje m.in. towary, stany, ceny, zamówienia, zwroty, wpłaty i konta klientów; szczegóły opisuje dokumentacja UDB. Zakres gotowego Bridge sprawdź w tabeli funkcji według programu ERP. Stan dokumentacji sprawdzony w 10.2026.

Tabela wskazuje zakres opisany dla UDB i Downloadera oraz ogólną rolę Bridge; dla gotowego konektora sprawdź konkretną komórkę tabeli producenta. Zapisz, czy system docelowy wartość zapisuje, odczytuje, czy tylko ją wyświetla.

Gotowy Bridge pasuje do obsługiwanego ERP i procesu mieszczącego się w funkcjach konektora, UDB przenosi dane przez strukturę buforową, Downloader importuje dane towarowe z pliku, a API pozwala zaprojektować przepływy przez dostępne metody. Modele różnią się zakresem i odpowiedzialnością za transfer.

Opis IdoSell Downloadera ogranicza jego rolę do aktualizacji towarów. Dokumentacja Admin API podaje, że nie każda funkcja panelu jest dostępna jako metoda API. Zakres sprawdziliśmy w dokumentacji producenta w 10.2026.

Gotowy konektor ogranicza prace własne, gdy jego funkcje pokrywają proces. UDB wymaga aplikacji przenoszącej dane między ERP i strukturą UDB. API daje swobodę w granicach metod udostępnionych przez IdoSell i możliwości zespołu, który będzie utrzymywał aplikację.

Integracja standardowa wystarczy, gdy konektor przekazuje wymagane dane i respektuje reguły magazynu, cen oraz dokumentów. Zgodność nazwy ERP z listą IdoSell nie potwierdza obsługi niestandardowych pól, zmodyfikowanej bazy ani każdego wyjątku procesu.

Rozpisz magazyny, warianty, cenniki, kanały sprzedaży i przypadki ręcznej edycji zamówień, a następnie porównaj je z tabelą funkcji Bridge dla konkretnego programu. Dla Downloadera sprawdź przykładowy plik, schemat, harmonogram generowania oraz sposób oznaczania wycofanych i niedostępnych rekordów.

Pobierz dokumentację funkcji dla danego ERP i potwierdź każdy wymagany przepływ przed wyceną. Jeśli ERP ogranicza dostęp do danych, dostawca systemu powinien potwierdzić bezpieczny sposób eksportu.

Mapowanie przypisuje polom i identyfikatorom jednego systemu ich odpowiedniki w drugim. Zacznij od audytu danych, a produkcyjną synchronizację uruchom po testach na kopii lub kontrolowanym zestawie rekordów.

1. Spisz pola i właścicieli danych. Zespół sklepu opisuje informacje widoczne dla klienta, księgowość wskazuje dane dokumentów, a dostawca ERP potwierdza strukturę kartotek i magazynów.
2. Ustal identyfikatory. Zmapuj SKU, ID produktów i wariantów, kody magazynów, płatności, dostawy oraz statusy. Ten sam klucz musi wskazywać ten sam rekord po obu stronach.
3. Uzgodnij reguły biznesowe. Zapisz sposób obsługi cen netto i brutto, stawek podatkowych, rezerwacji, produktów wycofanych, częściowych zwrotów i edytowanych zamówień.
4. Sprawdź format transferu. Dla Downloadera porównaj plik XML lub CSV z wymaganym układem, kodowaniem, identyfikatorami i sposobem oznaczania zmian.
5. Wykonaj testy kontrolowane. Przetestuj nowy produkt, korektę stanu, zmianę ceny, zamówienie, anulowanie i zwrot. Powtórz operację, aby wykryć duplikaty.
6. Ustal monitoring. Właściciel sklepu pilnuje widoku klienta, księgowość poprawności dokumentów, a integrator logów i reakcji na błędy.

Nie testuj równoczesnej ręcznej edycji tego samego pola w ERP i sklepie, ponieważ utrudnia to ustalenie, który zapis powinien być źródłem prawdy.

Diagnostykę błędu synchronizacji zacznij od wskazania rekordu, czasu zmiany i systemu, do którego dotarła operacja. Nie poprawiaj od razu wartości ręcznie, ponieważ kolejny przebieg może ponownie zapisać błędne dane.

Odczytaj log razem z identyfikatorem rekordu, znacznikiem czasu i wynikiem operacji. Przy danych sprzedażowych uzgodnij z księgowością, czy ponowienie nie utworzy drugiego dokumentu. Po naprawie zapisz przyczynę i procedurę odtworzenia.

Pełny koszt integracji obejmuje uruchomienie i utrzymanie połączenia przez cały okres używania. Sama licencja, jeśli występuje, nie obejmuje automatycznie mapowania, testów, monitoringu ani zmian po aktualizacji ERP lub sklepu.

Poproś dostawców o oddzielne zestawienie opłat cyklicznych i prac dodatkowych. Aktualne opłaty za Bridge, Downloader lub ERP potwierdź w obowiązującym cenniku dostawcy, ponieważ kwota zależy od modelu i zakresu. Do kalkulacji wpisz też roboczogodziny potrzebne na ręczne poprawki.

Porównaj koszt pełnego cyklu z czasem pracy na ręczne poprawki. Przez ustalony okres zapisuj czas poświęcony na korekty, duplikaty i przepisywanie zamówień przed oszacowaniem oszczędności.

Wybierz model, który obsługuje wymagane przepływy i ma przypisanego właściciela utrzymania. Mała liczba zamówień sama nie przesądza o wyborze, ponieważ nietypowy ERP lub reguły cenowe mogą wymagać API także w mniejszym sklepie.

Decyzję oprzyj na trzech dowodach: tabeli funkcji dla używanej wersji ERP, próbce danych oraz wyniku testów na przypadkach brzegowych. Gotowy Bridge rozważaj, gdy konektor obsługuje wymagane operacje. Downloader wybierz do aktualizacji towarów z pliku, UDB gdy firma może utrzymywać transfer przez strukturę buforową, a API gdy dostępne metody obejmują potrzebne operacje i zespół przejmie utrzymanie.

Przed zleceniem potwierdź listę danych i kierunków, źródło prawdy, identyfikatory, przypadki testowe, monitoring oraz zasady rozliczania zmian. Jeśli przepływy obejmują kilka kanałów sprzedaży, integracja z BaseLinkerem może obsługiwać osobny etap dystrybucji zamówień, pod warunkiem uzgodnienia roli BaseLinkera względem IdoSell i ERP.

Perspektywa KC Mobile

W projektach integracyjnych najpierw rozdzielamy właścicieli danych i ustalamy przypadki, w których rekord może być zmieniany po obu stronach. Dopiero wtedy dobieramy model i testujemy ścieżkę od zmiany towaru do zamówienia oraz dokumentu. Tabela funkcji producenta pomaga zawęzić wybór, ale nie zastępuje testu na konfiguracji konkretnej firmy.

• Jak zintegrować zamówienia ze sklepu internetowego z systemem księgowym?
• Integracja ERLI z Comarch ERP XL - jak zaplanować synchronizację
• Co to jest BaseLinker, dlaczego firmy go wdrażają i kiedy się opłaca
• Automatyzacja obsługi sprzedaży na Allegro: od zamówienia do wysyłki