Integracja Magento 1.x z enova365: synchronizacja i plan wdrożenia

Przed integracją spisujemy wersje Magento i enova365, używane rozszerzenia, liczbę sklepów, podmiotów, magazynów i walut oraz procesy wykonywane obecnie ręcznie. Sama nazwa systemu nie potwierdza zgodności: trzeba sprawdzić konfigurację i zakres dostępnych interfejsów dla konkretnej instalacji.

Po stronie enova365 potwierdzamy dostępny interfejs, licencję i uprawnienia. Według oficjalnych stron enova365 sprawdzonych w październiku 2026 WebAPI udostępnia interfejs REST z autoryzacją JWT, a Soneta.Integrator obsługuje wymianę XML i JSON przez SOAP oraz REST. Producent opisuje te moduły jako sposoby integracji z systemami zewnętrznymi, ale ich opis nie potwierdza gotowej zgodności z konkretnym sklepem Magento.

Do inwentaryzacji dołączamy schemat zamówienia, statusy, sposoby płatności, reguły cenowe, jednostki miary i identyfikatory produktów. Jeśli Magento ma łączyć się z enova365 przez BaseLinker, sprawdzamy, czy planowany przepływ i wymagane operacje mieszczą się w zakresie tej integracji. Firmy, które chcą zlecić taki wariant, mogą omówić wdrożenie integracji BaseLinker jako osobny zakres prac.

Zakres synchronizacji określa właściciel danych, kierunek przepływu i częstotliwość dla każdej encji. Źródło prawdy to system, w którym dana informacja jest tworzona i zatwierdzana; przypisanie go ogranicza ryzyko nadpisania poprawnych danych przez starszą kopię.

Przykładowy podział pokazuje, które decyzje firma powinna zatwierdzić przed konfiguracją. Rzeczywiste częstotliwości zależą od mechanizmu konektora i wymaganego czasu reakcji.

Tabela jest modelem do zatwierdzenia, a nie deklaracją funkcji konkretnego konektora. Wniosek: każda encja wymaga właściciela, kierunku przepływu i uzgodnionego momentu aktualizacji.

Dokument sprzedażowy nie powinien powstawać wyłącznie dlatego, że sklep przyjął zamówienie. Firma ustala, czy jego utworzenie następuje po opłaceniu, potwierdzeniu, wysyłce czy innym zdarzeniu oraz jak obsłużyć korektę i zwrot.

Reguły synchronizacji muszą wskazywać moment rezerwacji towaru, potwierdzenia płatności, wystawienia dokumentu i zlecenia wysyłki. Rezerwacja w sklepie może zmniejszać dostępność przed zaksięgowaniem operacji w ERP, dlatego integracja powinna rozstrzygać, czy blokuje stan, czy zmienia go dopiero zrealizowane zamówienie.

Przed konfiguracją firma zatwierdza decyzje procesowe:

• Czy zamówienie trafia do enova365 od razu, czy po potwierdzeniu płatności?
• Czy sklep prezentuje stan fizyczny, dostępny po rezerwacjach, czy stan wybranego magazynu?
• Który system nadaje status wysyłki i jak obsługiwane jest częściowe wydanie?
• Czy anulowanie zamówienia zwalnia rezerwację automatycznie?
• Jak rejestrowany jest zwrot częściowy i korekta dokumentu?

Z naszych wdrożeń wynika, że nieporozumienia często dotyczą różnych definicji statusu zamówienia i dostępności produktu. Zalecamy opisać każdą regułę jako zdarzenie, warunek i oczekiwany skutek w obu systemach.

Konektor zgodny z Magento 1.x nie jest automatycznie zgodny z Magento 2.x, ponieważ wersje mogą wymagać innych rozszerzeń i zależności. Producent łącznika powinien wskazać obsługiwane wydania, wymagane moduły, wersję PHP i zakres przetestowanych operacji.

Tabela pokazuje różnice, które należy sprawdzić przed wyborem konektora. Zgodność potwierdzamy dla konkretnej instalacji i operacji, a nie na podstawie samej nazwy platformy.

Migrację testujemy na kopii sklepu i środowisku testowym ERP. Adobe publikuje politykę cyklu życia dla wskazanych linii Adobe Commerce; dokumentacja sprawdzona w październiku 2026 nie stanowi podstawy do automatycznego przypisania tych samych dat do Magento 1.x. Dlatego status utrzymania i bezpieczeństwa konkretnej instalacji trzeba potwierdzić osobno.

Jeśli migracja jest planowana, porównujemy koszt tymczasowego utrzymania konektora z zakresem przeniesienia procesów na nową platformę. Przed decyzją sprawdzamy, czy nowe środowisko zachowa identyfikatory produktów, zamówień i kontrahentów.

Wdrożenie dzielimy na etapy, a każdy kończymy dowodem do weryfikacji przed przejściem dalej. Taki podział pozwala zatrzymać projekt na etapie mapowania, jeśli systemy nie obsługują wymaganych danych lub reguł.

Tabela pokazuje etapy prac i rezultat wymagany do ich odbioru. Uruchomienie produkcyjne planujemy po zatwierdzeniu mapowania i pozytywnym wyniku testów krytycznych procesów.

Próbę wykonujemy na ograniczonej grupie danych. Sprawdzamy, czy produkt w Magento otrzymał właściwy identyfikator ERP, a zamówienie zachowało pozycje, ceny, dane klienta i status płatności.

Test odbiorowy przechodzi, gdy dane w obu systemach odpowiadają zatwierdzonemu mapowaniu, a każda operacja ma zapisany dowód. Testy wykonujemy na kopii sklepu lub środowisku testowym, bez kierowania rzeczywistych zamówień do realizacji.

Tabela wskazuje scenariusze, oczekiwane zachowanie i dowód potrzebny do odbioru. Protokół powinien przechowywać dane wejściowe, wynik, identyfikatory transakcji i osobę akceptującą scenariusz.

Test niedostępności usługi powinien sprawdzić, czy ponowienie nie tworzy drugiego zamówienia ani dokumentu. Wynik zapisujemy razem z identyfikatorem operacji i rezultatem ponowienia.

Po uruchomieniu mogą wystąpić duplikaty, błędne mapowanie kontrahenta, różnice jednostek i zadania pozostawione w kolejce. Diagnozę zaczynamy od identyfikatora zamówienia lub zadania, a następnie sprawdzamy log sklepu, warstwy pośredniej i enova365.

Najpierw potwierdzamy czas oraz identyfikator zdarzenia, potem sprawdzamy payload bez danych wrażliwych. Ustalamy ostatni system, który potwierdził operację, weryfikujemy odpowiedź i sprawdzamy regułę ponowienia.

Idempotencja oznacza, że ponowienie tej samej operacji nie tworzy drugiego zamówienia ani dokumentu. Integracja powinna rozpoznawać klucz transakcji i zatrzymywać duplikat albo kierować go do ręcznej weryfikacji.

Nie ponawiamy całej kolejki bez ustalenia przyczyny błędu. Po jej usunięciu testujemy pojedyncze zadanie i sprawdzamy, czy operacja nie utworzyła podwójnego dokumentu.

Koszt integracji zależy od liczby przepływów, reguł biznesowych, stanu sklepu, dostępnych interfejsów i wymaganych testów. Rzetelna wycena wymaga wersji Magento i enova365, listy modułów, przykładowego zamówienia, liczby magazynów oraz opisu zwrotów i korekt.

Tabela porządkuje składniki jednorazowe i powtarzalne, które firma powinna uwzględnić w planie. Nie podaje stawek, ponieważ zakres zależy od konkretnej instalacji i wybranego konektora.

Wniosek: koszt startu, licencję lub abonament konektora oraz prace przy aktualizacji i migracji należy oceniać osobno.

Perspektywa KC Mobile: integracja bez monitoringu może przestać działać po zmianie rozszerzenia, konfiguracji sklepu lub interfejsu ERP, a obsługa zauważy problem dopiero przy realizacji zamówień. Zalecamy przypisać właściciela kolejki błędów, ustalić czas reakcji i przechowywać identyfikator operacji po obu stronach.

Jeśli proces sprzedaży ma być oparty na BaseLinkerze, zakres wdrożenia integracji BaseLinker pozwala omówić połączenie sklepu z systemami obsługującymi sprzedaż.

• enova 365 dla firmy: jak ocenić system, moduły i zakres wdrożenia
• Dlaczego enova365 nie działa? Jak ustalić przyczynę
• Jak zintegrować zamówienia ze sklepu internetowego z systemem księgowym?
• Integracja API krok po kroku: jak połączyć sprzedaż z operacjami