Jak synchronizować stany Microsoft Dynamics NAV z PrestaShop

W typowym scenariuszu NAV przekazuje do PrestaShop identyfikator artykułu i ilość dostępną do sprzedaży, a zakres cen, nazw i statusów ustala się osobno. SKU to kod używany do jednoznacznego dopasowania produktu lub wariantu między systemami.

Przed mapowaniem ustal źródło prawdy dla każdego pola i kierunek aktualizacji. Jeżeli oba systemy mogą edytować tę samą cenę lub nazwę, integracja potrzebuje reguły rozstrzygającej konflikt, na przykład pierwszeństwa NAV albo blokady edycji po stronie sklepu.

Tabela poniżej pokazuje przykładowy podział źródła danych i reguł aktualizacji. Użyj jej jako listy pól do uzgodnienia z administratorem NAV i osobą obsługującą PrestaShop.

Najpierw uzgodnij identyfikatory i regułę dostępności, bo te decyzje wpływają na poprawność pozostałych danych. PrestaShop Webservice udostępnia zasób `stock_availables`; dokumentacja opisuje pola produktu, kombinacji i sklepu oraz aktualizację ilości.

Administrator NAV powinien przed integracją potwierdzić wersję systemu, dostępne usługi, strukturę artykułów i sposób obliczania dostępności. Wersja oraz konfiguracja środowiska wpływają na sposób publikowania usług i dostępne zabezpieczenia.

Przed rozmową o integracji poproś administratora o konkretne materiały:
- wersję i kompilację NAV oraz informację, czy system działa lokalnie;
- listę opublikowanych usług SOAP lub OData i adres środowiska testowego;
- nazwę oraz kod lokalizacji przeznaczonej do realizacji zamówień internetowych;
- przykładowe numery artykułów, jednostki miary i kody wariantów;
- regułę uwzględniania rezerwacji, stanów ujemnych i zamówień w toku;
- sposób autoryzacji, wymagane uprawnienia i kontakt do administratora.

Administrator może również przygotować eksport przykładowych rekordów obejmujących produkt prosty, wariant i brak towaru. Dane te pozwalają sprawdzić jakość identyfikatorów przed pracami integracyjnymi i wykryć powtarzające się numery.

Microsoft dokumentuje publikowanie usług NAV opartych na stronach i codeunitach przez SOAP oraz stronach i zapytaniach przez OData. Polecenie administracyjne `New-NAVWebService` tworzy i opcjonalnie publikuje usługę na podstawie obiektu NAV; dostęp do konfiguracji powinien zapewnić administrator środowiska.

Wybór połączenia zależy od zgodności z wersją NAV, wymaganych procesów i tego, kto będzie utrzymywał błędy. Gotowy łącznik może wystarczyć przy standardowym obiegu, platforma integracyjna daje centralne mapowanie i kolejkę, a rozwiązanie dedykowane pozwala dopasować logikę do reguł firmy.

Porównaj warianty według sposobu obsługi błędów, aktualizacji i integracji z istniejącymi usługami NAV. Sama nazwa konektora nie potwierdza obsługi konkretnej wersji ani wymaganych pól.

Tabela pomaga zdecydować, jaki wariant sprawdzić w pierwszej kolejności. Przed wyborem poproś dostawcę o demonstrację na przykładowych rekordach NAV i PrestaShop.

W każdym wariancie sprawdź środowisko testowe, możliwość ponowienia żądania i historię zmian. Jeżeli firma rozważa zmianę platformy sklepowej, porównanie WooCommerce i Shopify pod kątem kosztów i integracji pomoże uporządkować decyzję o docelowym ekosystemie. Gdy plan obejmuje również nowy sklep oparty na WooCommerce, projekt i wykonanie sklepu internetowego warto zaplanować razem z przepływem danych z ERP.

Dostępność w sklepie powinna wynikać z jednej jawnej lokalizacji lub zatwierdzonej reguły sumowania magazynów. Stan fizyczny może różnić się od stanu do sprzedaży, ponieważ firma uwzględnia rezerwacje, zamówienia w toku lub bufor bezpieczeństwa.

Najpierw określ, czy zamówienia internetowe mogą być realizowane z jednej lokalizacji, czy z kilku. Przy sumowaniu ustal, czy integracja dodaje dostępność ze wszystkich magazynów, pomija lokalizacje serwisowe i produkcyjne oraz odejmuje rezerwacje. Bez tej decyzji poprawna wartość w NAV może prowadzić do nadmiernej sprzedaży w sklepie.

Tabela pokazuje, jak przełożyć typowe przypadki magazynowe na zachowanie sklepu. Reguły wymagają akceptacji osoby odpowiedzialnej za sprzedaż i logistykę.

Brak nowej aktualizacji wymaga alarmu, ponieważ stara ilość może nadal wyglądać wiarygodnie dla klienta. W PrestaShop ilość w `stock_available` wiąże się z produktem, kombinacją oraz zakresem sklepu; w konfiguracji multistore należy uwzględnić `id_shop` albo `id_shop_group` zgodnie z ustawieniem współdzielenia stanów.

Dopasowanie produktu powinno używać jednego stabilnego klucza, najczęściej numeru artykułu NAV odwzorowanego w SKU PrestaShop. Nazwa produktu nie jest bezpiecznym identyfikatorem, bo może się zmieniać albo powtarzać.

Ustal osobny klucz dla każdej kombinacji sprzedawanej jako odrębny wariant. PrestaShop rozróżnia produkt i kombinację, a zasób `stock_availables` zawiera identyfikator produktu oraz atrybutu produktu. Integracja musi więc kierować ilość wariantu do właściwego rekordu, a nie wyłącznie do produktu nadrzędnego.

Tabela przedstawia przykładowe mapowania oraz skutek błędnego klucza. Puste i powielone identyfikatory powinny zatrzymać aktualizację i trafić do kolejki błędów.

Przed startem wykryj puste i powielone kody, porównaj jednostki miary oraz uzgodnij obsługę opakowań zbiorczych. Przykładowo NAV może przechowywać stan w sztukach, a sklep sprzedawać opakowanie zawierające kilka sztuk; przelicznik musi być jawny i testowalny. Z naszych wdrożeń wynika, że błędne mapowanie jednostek łatwo pomylić z problemem synchronizacji, dlatego log powinien przechowywać identyfikator źródłowy i docelowy.

Test akceptacyjny powinien potwierdzić, że właściwa ilość trafia do właściwego produktu po udanym połączeniu i po jego wznowieniu. Testuj normalne aktualizacje oraz sytuacje, w których integracja ma zatrzymać zapis i utworzyć czytelny błąd.

Przed publikacją sprawdź scenariusze obejmujące:
- nowy artykuł z poprawnym SKU i artykuł z brakującym SKU;
- zmianę stanu w wybranej lokalizacji, rezerwację i stan równy zero;
- wariant z własnym kodem oraz właściwą kombinacją w sklepie;
- niedostępny interfejs NAV, a następnie ponowienie po przywróceniu połączenia;
- duplikat SKU oraz zmianę jednostki miary.

Kryterium akceptacji określa właściwy rekord, oczekiwaną ilość, uzgodniony czas przetworzenia i widoczny zapis błędu dla przypadków odrzuconych. Nie przyjmuj testu jako zaliczonego, jeśli integracja zmieniła ilość, ale nie da się ustalić, z jakiego artykułu i lokalizacji pochodziła wartość.

Test wznowienia rozpocznij od zablokowania połączenia na środowisku testowym, zmień stan w NAV, a następnie przywróć komunikację. Wynik powinien potwierdzić przetworzenie zaległej zmiany bez pominięcia rekordu i bez utworzenia duplikatów. Zapisz czas awarii, czas wznowienia i identyfikator zmienionego artykułu, aby administratorzy obu systemów mogli odtworzyć przebieg.

Brak aktualizacji diagnozujemy od harmonogramu i komunikacji, a następnie sprawdzamy lokalizację oraz identyfikator artykułu. Taka kolejność oddziela awarię połączenia od synchronizacji działającej według niewłaściwej reguły danych.

Zapisz czas ostatniego poprawnego przebiegu, identyfikator artykułu i pełny komunikat z logu integratora. W NAV administrator sprawdza publikację usługi i uprawnienia, a w PrestaShop rekord `stock_available` dla właściwego produktu, kombinacji i sklepu.

Tabela przyporządkowuje objaw do kolejnego sprawdzenia. Zacznij od problemu o najszerszym zasięgu, jeśli nie aktualizuje się cały katalog.

Jeżeli działa harmonogram, lecz błąd dotyczy jednego produktu, sprawdź mapowanie SKU przed zmianą poświadczeń. Gdy problem występuje w całej integracji, porównaj czas ostatniego żądania, odpowiedź usługi i stan kolejki. Przy długofalowej obsłudze sklepu opieka nad sklepem internetowym może objąć aktualizacje i kontrolę działania jego komponentów.

Zakres integracji zależy od wersji NAV, liczby produktów i wariantów, liczby lokalizacji oraz procesów poza samym stanem. Estymacja powinna osobno opisać analizę danych, mapowanie, wykonanie połączenia, testy i utrzymanie.

Przed wyceną przygotuj wersję NAV, listę interfejsów, przykładowe artykuły i regułę dostępności. Dodaj liczbę lokalizacji oraz informację, czy integracja obejmie ceny, warianty i statusy; każdy dodatkowy kierunek danych zwiększa zakres mapowania i testów.

Tabela rozdziela prace wdrożeniowe od decyzji wpływających na późniejsze utrzymanie. Użyj jej do ustalenia odpowiedzialności i materiałów wejściowych.

Zalecamy oddzielnie opisać konfigurację, testy i utrzymanie, ponieważ każdy zakres ma inny rezultat do odbioru. Jeżeli analiza wykaże, że sklep powinien powstać lub zostać przebudowany na WooCommerce, sklepy internetowe tworzone przez KC Mobile opisują zakres budowy tej platformy; integrację z NAV trzeba wycenić według interfejsów, danych i wymaganych reguł.

• Jak zaplanować niezawodną integrację Comarch ERP Optima z PrestaShop
• PrestaShop API: jak skonfigurować dostęp i bezpiecznie zintegrować sklep
• CRM connector do PrestaShop: jak wybrać moduł i połączyć dane
• Magento API w praktyce: endpointy, integracje i bezpieczeństwo