Español
English
Català
Deutsch
Français
Português
Italiano
Nederlands
Prawie każda firma, która łączy Amazon Seller Central z Odoo, przechodzi przez to samo: w pierwszym miesiącu w testach wszystko działa dobrze, a po kilku tygodniach pracy przy realnym wolumenie zaczynają pojawiać się te same objawy. Stan magazynu, który się nie zgadza, zamówienia, które się dublują, tracking, który dociera z opóźnieniem, API, które zaczyna zwracać błędy 429, albo token, który przestaje działać w poniedziałek rano bez żadnego ostrzeżenia.
Kluczowa myśl: prawie żaden z tych błędów nie jest problemem samego Amazona ani samego Odoo. Pojawiają się w warstwie synchronizacji, gdy konektor nie respektuje asynchronicznego modelu SP-API (powiadomienia w czasie rzeczywistym, limity żądań na każdy endpoint, tokeny OAuth o krótkiej ważności), a zamiast tego robi proste odpytywanie co X minut i liczy na to, że wszystko dotrze na czas.
Dlaczego integracja Amazon-Odoo zawodzi (i nie zawsze jest to oczywiste)
SP-API Amazona to nie proste REST API typu żądanie-odpowiedź. Łączy wywołania synchroniczne z asynchronicznym systemem powiadomień (Notifications API, dostarczanym przez SQS lub EventBridge), modelem raportów generowanych w tle, które trzeba odpytywać, aż będą gotowe, oraz limitem żądań na sekundę innym dla każdej operacji, a nie jednym globalnym dla całego konta. Uwierzytelnianie odbywa się przez Login With Amazon (LWA): access token wygasa co godzinę i trzeba go odnowić za pomocą refresh_token, zanim straci ważność.
Wiele integracji (zwłaszcza zbudowanych na ogólnych automatyzacjach typu Zapier, Make albo iPaaS bez logiki specyficznej dla Amazona) upraszcza to wszystko do crona, który co X minut sprawdza zamówienia, i zakłada, że to wystarczy. To uproszczenie jest bezpośrednim źródłem większości błędów z poniższej tabeli.
Tabela: objaw, prawdopodobna przyczyna i jak tego uniknąć
Osiem realnych objawów, które widzimy w firmach sprzedających na Amazonie z poziomu Odoo, z najbardziej prawdopodobną przyczyną techniczną w każdym przypadku i rozwiązaniem, które stosuje konektor zbudowany do prawdziwej pracy, a nie tylko do przejścia dema.
| Objaw | Prawdopodobna przyczyna | Jak tego uniknąć |
|---|---|---|
| Rozjechany stan magazynu / oversell na Amazonie | Synchronizacja przez odpytywanie co 30-60 minut; Notifications API dla stanów magazynowych w czasie rzeczywistym nie jest wykorzystywane | Subskrypcja powiadomień o stanach magazynowych z natychmiastowym wysłaniem po każdym ruchu magazynowym w Odoo, plus konfigurowalny bufor bezpieczeństwa |
| Zduplikowane zamówienia w Odoo | Ponowienia konektora bez idempotentności; AmazonOrderId nie jest używany jako unikalny klucz | Idempotentny upsert indeksowany po AmazonOrderId, z ograniczeniem unikalności na poziomie bazy danych |
| Tracking dociera do Amazona za późno (rośnie Late Shipment Rate) | Tracking jest wysyłany w nocnym cronie wsadowym, zamiast w momencie zatwierdzenia dostawy | Automatyczna akcja, która wywołuje Shipping API w chwili zatwierdzenia dostawy w Odoo |
| Błędy 429 / „Request throttled” | Nie jest respektowany limit żądań właściwy dla każdej operacji SP-API (każdy endpoint ma własny bucket) | Kolejka zadań z wykładniczym backoffem i własnym rate limiterem dla każdego endpointu, a nie jednym globalnym |
| Wygasły token OAuth lub nieprawidłowy refresh_token | Brak automatycznego odnawiania access tokena LWA albo zgoda została cofnięta w Seller Central bez wiedzy kogokolwiek | Automatyczne odnawianie z zapasem bezpieczeństwa, plus alert, gdy odnowienie się nie powiedzie (a nie dopiero wtedy, gdy zawiedzie prawdziwe zamówienie) |
| Różne ceny na Amazonie i w pozostałych kanałach | Brak jednego źródła prawdy; cena jest edytowana ręcznie w Seller Central | Odoo jako źródło prawdy dla cen, z jawnymi regułami konfliktów, gdy wykryta zostanie ręczna edycja na Amazonie |
| Zwroty i reklamacje, które nie zgadzają się w księgowości | Przetwarzane są tylko zamówienia; raporty Returns/Refunds z Amazona nie są importowane | Automatyczny import Returns Reports do zapisów księgowych not kredytowych, a nie tylko do magazynu |
| Działa w testach, ale zawodzi przy kilku kontach lub marketplace’ach | Dane dostępowe i stan synchronizacji zapisane na sztywno dla jednego konta sprzedawcy | Model danych uwierzytelniających per firma/marketplace wbudowany w sam model danych, a nie łatka dodana później |
Checklista: co powinien mieć dobrze zbudowany konektor Amazon-Odoo
Zanim uznasz konektor Amazon-Odoo za dobry (własny albo taki, który rozważasz kupić), przejdź przez tę listę. To nie teoria: to dokładnie te punkty, w których widzieliśmy zawodzące realne integracje.
- Korzysta z Notifications API Amazona (SQS/EventBridge), zamiast polegać tylko na okresowym odpytywaniu
- Importuje zamówienia idempotentnie, używając AmazonOrderId jako unikalnego klucza
- Wysyła tracking do Amazona w momencie zatwierdzenia dostawy, a nie wsadowo w nocnym cronie
- Stosuje rate limiter i wykładniczy backoff dla każdego endpointu, a nie przybliżony limit globalny
- Odnawia token OAuth (LWA) automatycznie, z wczesnym alertem, jeśli odnowienie się nie powiedzie
- Zapisuje w logu każde wywołanie API z kodem odpowiedzi i payloadem, a nie tylko ogólne „sync OK”
- Obsługuje wiele kont i marketplace’ów już w samym modelu danych, a nie jako późniejszy dodatek
Co robimy w FlexigoTech: nasz Konektor Amazon dla Odoo
Nasz Konektor Amazon dla Odoo został zbudowany z FBA i FBM działającymi w prawdziwej produkcji przez SP-API, właśnie po to, by nie wpaść w żaden z ośmiu punktów z powyższej tabeli: idempotentny import po AmazonOrderId, wysyłka trackingu przy zatwierdzeniu dostawy i automatyczne odnawianie tokenów, między innymi. To nie jest ogólna warstwa automatyzacji nałożona na API: to natywny moduł Odoo zaprojektowany do pracy przy realnym wolumenie, a nie tylko do przejścia dema.
Jeśli masz już Odoo, ale obecny konektor (własny lub zewnętrzny) daje Ci któryś z tych objawów, często problemem nie jest zmiana konektora, lecz sprawdzenie, jak został wdrożony w Twojej instancji. Zwykle rozwiązuje się to w ramach dobrze przeprowadzonego projektu wdrożenia Odoo 19, z synchronizacją marketplace’ów w zakresie od samego początku, a nie jako późniejsza łatka.
Przydatne linki w FlexigoTech
Najczęstsze pytania
Dlaczego stan magazynu rozjeżdża się między Amazonem a Odoo, mimo że mam zainstalowany konektor?
Prawie zawsze dlatego, że konektor synchronizuje przez odpytywanie (polling) co jakiś czas, zamiast reagować na powiadomienia Amazona o stanach magazynowych w czasie rzeczywistym. Między jednym przebiegiem a następnym jest okno, w którym Amazon i Odoo się nie zgadzają, a przy katalogach o dużej rotacji to wystarczy, by sprzedać coś, czego już nie masz.
Jak uniknąć duplikatów zamówień, gdy Amazon ponownie wysyła to samo powiadomienie?
Amazon może wysłać to samo powiadomienie o zamówieniu więcej niż raz; to normalna część jego modelu dostarczania. Rozwiązaniem nie jest ręczne filtrowanie powtórzeń, lecz konektor, który używa AmazonOrderId jako unikalnego klucza i wykonuje idempotentny upsert: jeśli zamówienie już istnieje, aktualizuje je; jeśli nie, tworzy je. Nigdy nie wstawia dwa razy.
Czym jest błąd 429 w Amazon SP-API i jak go rozwiązać z poziomu Odoo?
To błąd throttlingu: przekroczono limit żądań na sekundę dla tego konkretnego endpointu (każda operacja SP-API ma własny limit, a nie jeden globalny). Rozwiązuje się go kolejką zadań, która respektuje limit każdego endpointu i ponawia z wykładniczym backoffem, a nie ponownym wywołaniem po kilku sekundach.
Co się stanie, jeśli mój token OAuth Amazona wygaśnie na produkcji?
Amazon używa Login With Amazon (LWA): access token wygasa co godzinę i trzeba go odnowić za pomocą refresh_token, zanim straci ważność. Jeśli konektor nie automatyzuje tego odnawiania albo sprzedawca cofnął zgodę w Seller Central bez poinformowania kogokolwiek, wywołania zaczynają kończyć się błędami autoryzacji, dopóki konto nie zostanie ponownie połączone ręcznie.
Czy tracking, który dociera do Amazona z opóźnieniem, naprawdę wpływa na moje konto?
Tak. Amazon mierzy Late Shipment Rate i jeśli przekroczy on próg, może to wpłynąć na kondycję konta i widoczność Twoich ofert, nie mówiąc o bezpośrednim wpływie na doświadczenie kupującego. Jeśli tracking jest wysyłany w nocnym cronie, a nie w momencie zatwierdzenia dostawy w Odoo, to opóźnienie jest winą konektora, a nie Amazona.
Co robimy w tej sprawie
Chcesz, żebyśmy przejrzeli Twoją integrację z Amazonem?
Napisz nam, jaki objaw masz (stan magazynu, duplikaty zamówień, tracking lub tokeny), a w pierwszej rozmowie powiemy Ci, czy to punktowa korekta, czy konektor wymaga głębszego przeglądu. Napisz do nas na comercial@flexigobe.com lub zadzwoń pod numer +34 616 809 504.