Jeśli zamówienia, statusy albo dokumenty przechodzą przez kilka programów, uporządkuję ten proces bez dokładania kolejnego panelu do ręcznej obsługi.
Sprzedajesz w sklepie internetowym albo na marketplace, a księgowość i magazyn siedzą w Subiekcie GT, Nexo, Optimie lub enova365. Ktoś w firmie codziennie przenosi zamówienia, stany i ceny między jednym programem a drugim, bo gotowa wtyczka albo nie obsługuje Twojego przypadku, albo obsługuje go połowicznie. To jest moment, w którym warto połączyć te systemy na stałe.
Zamówienie trzeba przepisać z e-commerce do ERP, a pomyłkę widać dopiero przy fakturze.
Statusy wysyłki, płatności albo dostępności nie zgadzają się w dwóch miejscach.
API istnieje, ale po zmianie tokenu, wersji albo pola integracja przestała działać.
Stan magazynowy wraca z opóźnieniem, a duplikaty lub odrzucone rekordy wymagają ręcznego szukania.
Plik CSV lub XML jest jedynym łącznikiem między programami i nie wiadomo, co nie przeszło.
Gotowy konektor (Base.com, BaseLinker, wtyczki do IdoSell czy Shopera) wystarcza, gdy masz standardową kartotekę, jeden magazyn, proste ceny i typowy obieg zamówienia. Piszę integrację na zamówienie wtedy, gdy w grę wchodzą ceny indywidualne i rabaty per kontrahent, kilka magazynów i rezerwacje, zestawy i warianty, dokumenty inne niż faktura albo własny portal B2B. Mówię, która droga jest tańsza, zanim wystawię wycenę.
Najpierw ustalam, który system rozstrzyga dla stanu, ceny i statusu — bez tego każda synchronizacja jest zgadywaniem. Potem uruchamiam jeden przepływ (zwykle zamówienie albo stan), dokładam logi i raport wyjątków, a resztę zdarzeń dopinam etapami.
Subiekt GT rozmawia przez Sferę, Nexo przez Sferę dla Nexo, Optima przez własne mechanizmy. Gdy licencja albo wersja tego nie obejmuje, zostaje bezpieczny odczyt bazy i wymiana plikowa: XML, CSV, katalog wymiany. Sprawdzam wersję i licencję, zanim cokolwiek obiecam.
Nie zakładam gotowego konektora. Najpierw sprawdzam wersję, licencję, dostępne API i jeden rzeczywisty przypadek.
Jeśli własny portal lub aplikacja potrzebuje klientów, cen, stanów, zamówień albo dokumentów z Subiekta, sprawdzam Sferę, modele danych i sposób zapisu. Zaczynam od odczytu, a zamówienia i dokumenty dokładam później.
Przy desktopowym Optimie analizuję, które dane można bezpiecznie wystawić na zewnątrz i jak zabezpieczyć odczyt. Pierwszy etap to jeden model danych i jasny sposób obsługi błędów.
Gdy stany, zamówienia, zwroty, korekty lub dokumenty rozjeżdżają się między sklepem, Optimą i WMS, zaczynam od raportu różnic i ustalenia, który system jest źródłem prawdy.
Mogę osobno sprawdzić synchronizację zamówień, stanów, faktur, e-paragonów, PZ i WZ. Przy większej kartotece najważniejsze jest mapowanie SKU, magazynów i wyjątków.
Jeśli gotowe połączenie nie pokazuje stanu fizycznego, dostępnego lub rezerwacji, sprawdzam mapowanie magazynów i SKU. Wynikiem może być raport różnic, mały adapter, log operacji lub plan poprawki.
Po zmianie .NET, x64 albo wersji Nexo własny dodatek może wymagać przebudowy i sprawdzenia. Mogę przygotować scenariusze i przykładowe dane, a potem sprawdzić zgodność, zanim aktualizacja wejdzie na produkcję.
Dobieram narzędzia do konkretnego przepływu. Nie zakładam z góry wymiany systemu ani budowy dużej platformy.
Sprawdzam, skąd wychodzą dane, kto je zmienia i gdzie powinien powstać potwierdzony status.
Buduję mały, opisany punkt połączenia zamiast mieszać logikę kilku systemów w jednym skrypcie.
Integracja powinna powiedzieć, co się stało, a nie tylko przestać działać po cichu.
Przygotowuję przykładowe dane, scenariusze testowe i krótką instrukcję dla osoby, która będzie nadzorować przepływ.
Porównuję jeden konkretny przypadek zamówienia, dokumentu lub stanu magazynowego od źródła do końca przepływu.
Jeśli integracja przestała działać po aktualizacji, oddzielam przyczynę od skutku i poprawiam możliwie mały fragment adaptera.
Pierwsza rozmowa jest bezpłatna. Cenę podaję po zobaczeniu procesu, nie z cennika. Jeśli da się to rozwiązać prościej albo gotowym narzędziem, mówię o tym na początku.
Najlepiej na przykładzie kilku prawdziwych, zanonimizowanych rekordów: wejście, oczekiwany wynik i miejsce, w którym dziś powstaje błąd.
Na zanonimizowanym przypadku sprawdzam kolejność zdarzeń, identyfikatory, statusy oraz miejsce, w którym ERP, e-commerce lub WMS przestają się zgadzać.
Najpierw działa jeden przepływ z obsługą błędów. Dopiero potem dokładam kolejne zdarzenia lub typy dokumentów.
Dostajesz opis mapowania, wynik testów i listę rzeczy do sprawdzenia, kiedy któryś z systemów się zmieni.
Najpierw jeden przepływ, potem reszta. Zakres, kolejność prac i jedna cena na piśmie, zanim zacznę.
Logi, raport odrzuconych rekordów i dokumentacja. Przy aktualizacji ERP wiadomo, co się stało i gdzie szukać.
Po wdrożeniu zostaję do obsługi i rozwoju. Płatna miesięcznie, bez umowy rocznej. Rozmawiasz ze mną, nie z działem.
Przejmuję też rozwiązania, które zrobił ktoś inny: najpierw diagnoza cudzego kodu i logów, potem możliwie mała poprawka, na końcu dokumentacja przepływów i sposobu restartu.
Wystarczy krótki opis: jakie systemy są zaangażowane, co robisz ręcznie i jaki wynik chcesz sprawdzać. Odpowiadam w 24 h. Rozmawiasz bezpośrednio ze mną.