Sumy zamówień w Odoo i Shopify się nie zgadzają: 8 prawdziwych przyczyn

Shopify twierdzi, że zamówienie to 128,45. Zamówienie sprzedaży w Odoo pokazuje 106,16. Nikt niczego nie ruszał, konektor nie zgłasza błędów, a mimo to obie liczby są sprzeczne. W praktyce niemal każda rozbieżność kwot między Odoo a Shopify sprowadza się do jednej z ośmiu przyczyn — i każda zostawia inny ślad. Ten przewodnik omawia wszystkie osiem, podaje objaw, który zdradza każdą z nich, i wskazuje dokładne pole do sprawdzenia po obu stronach.

Dotyczy to każdego zamówienia Shopify żyjącego w Odoo, niezależnie od konektora, który je zaimportował: Shopify Odoo Connector od Emipro, Webkul, moduł OCA czy własny most. Nazwy pól poniżej pochodzą ze standardowych modeli Odoo oraz — tam, gdzie to istotne — z ustawień, które konektor zwykle udostępnia na rekordzie swojej instancji.

Najpierw upewnij się, że porównujesz porównywalne liczby

Zanim ruszysz na polowanie na błąd, sprawdź, co właściwie porównujesz. Oba systemy pokazują kilka „sum”, a one nie znaczą tego samego.

• Bieżąca suma Shopify — ile klient jest winien dzisiaj, po zwrotach i edycjach. W Admin API: currentTotalPriceSet.
• Pierwotna suma Shopify — to, co uzgodniono przy płatności, przed późniejszymi zmianami: originalTotalPriceSet.
• Suma zamówienia w Odoo — amount_total na sale.order: to, co zaimportował konektor, plus to, co później zsynchronizował ponownie.
• Zafakturowane netto w Odoo — zaksięgowane faktury sprzedaży minus zaksięgowane korekty (account.move, move_type out_invoice i out_refund).

To, że te cztery liczby się różnią, samo w sobie nie jest problemem. Jedyne realne pytanie brzmi: która para powinna się zgadzać — a to zależy od tego, jak daleko zaszło zamówienie. Zamówienie jeszcze niezafakturowane wymaga innego porównania niż takie, które zafakturowano, zwrócono i zmieniono.

1 Przyczyna 1: ceny z podatkiem w cenie

To najczęstszy fałszywy alarm i najłatwiejszy do wykluczenia. Jeśli ceny w Shopify zawierają podatek, a podatki w Odoo są ustawione jako „Wliczony w cenę”, to suma częściowa Shopify i kwota netto w Odoo mierzą dwie różne rzeczy: pierwsza jest brutto, druga netto.

Objaw jest jednoznaczny: różnica równa się dokładnie stawce podatku. 128,45 wobec 106,16 to nie zaokrąglenie, to 21 % VAT.

Rozwiązaniem jest wybór porównania, które przetrwa to ustawienie. Porównuj sumy brutto — bieżącą sumę Shopify z amount_total w Odoo — albo netto po obu stronach, odejmując w Odoo amount_tax od amount_total. Czego nigdy nie należy robić: porównywać sumy częściowej Shopify z amount_untaxed w Odoo, jeśli nie masz pewności, że obie strony są skonfigurowane tak samo.

2 Przyczyna 2: zamówienie zamarza, faktura żyje dalej

Konektory importują zamówienie Shopify do sale.order. Gdy tylko zostanie ono zafakturowane, większość przestaje wpychać do niego późniejsze zmiany — i słusznie: zafakturowane zamówienie to dokument księgowy, a nie lustro. Od tego momentu zamówienie zapisuje to, co zamówiono, a faktury to, co faktycznie obciążono.

Dlatego gdy zwrot przychodzi po fakturze, bieżąca suma Shopify spada, a zamówienie w Odoo stoi w miejscu. Pieniądze w Odoo owszem się poruszyły, tylko gdzie indziej: w korekcie, czyli account.move z move_type = out_refund.

Gdzie szukać: sale.order.invoice_ids daje wszystkie faktury i korekty powiązane z zamówieniem. Zsumuj zaksięgowane out_invoice, odejmij zaksięgowane out_refund — ta kwota netto powinna zgadzać się z bieżącą sumą Shopify. W wierszu miarodajną ilością jest qty_invoiced, a nie product_uom_qty.

To także powód, dla którego porównywanie zamówienia sprzedaży z Shopify daje coraz więcej fałszywych alarmów, im starsze jest zamówienie: porównujesz zdjęcie zrobione w chwili importu z żywym dokumentem.

3 Przyczyna 3: zwroty — pieniądze zawsze się zgadzają, ilości niekoniecznie

Zwroty w Shopify występują w dwóch odmianach i tylko jedna dotyka magazynu. Zwrot może oddać pieniądze i przyjąć sztuki z powrotem na stan albo oddać pieniądze i zostawić sztuki tam, gdzie są: towar uszkodzony, gest handlowy, częściowa korekta ceny.

W Admin API rozróżnienie żyje w każdym wierszu zwrotu, w polu restockType: NO_RESTOCK, CANCEL, RETURN lub LEGACY_RESTOCK. Dla uzgadniania oznacza to, że zwrot NO_RESTOCK obniża kwotę bez zmiany żywej ilości wiersza, więc kontrola ilości wiersz po wierszu może wyglądać na błędną, choć pieniądze są idealne.

To najczęściej źle odczytywana rozbieżność, bo instynkt każe ufać ilościom bardziej niż kwotom. Tutaj kwoty mają rację, a ilości mówią o czymś innym: o tym, co zafakturowano, wobec tego, co fizycznie wróciło.

4 Przyczyna 4: zamówienie zmieniono w Shopify po fakcie

Edycja zamówień w Shopify zmienia zamówienie w miejscu: wiersze są dodawane, usuwane lub zmieniane ilościowo po tym, jak klient zapłacił. Shopify zachowuje obie liczby — originalTotalPriceSet dla płatności i currentTotalPriceSet dla zamówienia po edycji — a większość konektorów ponownie synchronizuje zamówienie sprzedaży, więc amount_total w Odoo podąża za edycją i przestaje odpowiadać temu, co zamówiono.

Samo w sobie jest to nieszkodliwe. Groźny wariant to edycja, która przychodzi po fakturze: wiersz już zafakturowany w Odoo zostaje usunięty w Shopify. Teraz Odoo zafakturowało więcej, niż Shopify kiedykolwiek pobierze. To nie jest artefakt wyświetlania, to realne nadmierne zafakturowanie i wymaga korekty.

Objaw: kwota netto z faktur w Odoo przewyższa bieżącą sumę Shopify, zamówienie nie ma zwrotu, a pierwotna suma Shopify jest wyższa od bieżącej. Gdy te trzy rzeczy zachodzą naraz, zamówienie zmieniono po zafakturowaniu.

5 Przyczyna 5: karty podarunkowe, sprzedane i wykorzystane

Karty podarunkowe wywołują dwie zupełnie różne rozbieżności w zależności od tego, po której stronie transakcji się znajdują — warto je starannie rozdzielić.

Sprzedaż karty podarunkowej. W Shopify wiersz ma znacznik isGiftCard i zwykle nie ma żadnego SKU. Konektory nie dopasowują go po SKU: wykrywają znacznik przy imporcie i kierują wiersz na dedykowany produkt skonfigurowany na instancji konektora (w Emipro gift_card_product_id). Jeśli twoje uzgadnianie dopasowuje wiersze po SKU, ta sama karta pojawia się jako dwa niepełne wiersze: jeden po stronie Shopify z nazwą i bez SKU, drugi po stronie Odoo z referencją wewnętrzną produktu syntetycznego. Karta jest w porządku; zły jest klucz dopasowania.

Płatność kartą podarunkową. Tutaj Shopify nie ma żadnego wiersza: karta użyta jako płatność jest środkiem płatniczym i pojawia się wyłącznie wśród bramek płatności zamówienia. Konektory, które muszą zbilansować płatność w Odoo, dodają wiersz ujemny — „Gift card for …” — wskazujący na ten sam produkt syntetyczny. Odoo ma wtedy o jeden wiersz więcej niż Shopify, a każdy naiwny widok wiersz po wierszu pokazuje wiersz bez odpowiednika.

6 Przyczyna 6: rabaty, gratisy i produkty-artefakty

Shopify i Odoo modelują ten sam gest handlowy w różnych kształtach. Gratis w Shopify to drugi wiersz za 0,00. Rabat to kwota niesiona przez sam wiersz. Konektory Odoo często wyrażają jedno i drugie jako dodatkowy wiersz wskazujący na produkt syntetyczny skonfigurowany na instancji: zwykle produkt rabatowy, produkt korekty zwrotów, produkt ceł, produkt napiwku i produkt wysyłki.

Te wiersze-artefakty nie mają odpowiednika w lineItems Shopify. Wiersz po wierszu wyglądają jak duchy; w sumie są dokładnie tym, co sprawia, że obie kwoty się zgadzają. Ich usunięcie zepsułoby zamówienie, a nie naprawiło.

Jak porównywać poprawnie: agreguj wiersze po SKU przed dopasowaniem i wyklucz produkty skonfigurowane jako artefakty na instancji konektora. Gdy te dwie reguły działają, pozostałe różnice są prawdziwe.

7 Przyczyna 7: wysyłka, cła i opłaty

Wysyłka to w Shopify osobne pojęcie — wiersz wysyłki z własną ceną i podatkiem — podczas gdy w Odoo trafia zwykle jako zwykły wiersz zamówienia oznaczony is_delivery, wyceniony z produktu wysyłkowego konektora. Cła, napiwki i dopłaty do płatności działają tak samo.

Praktyczny skutek jest taki, że liczba wierszy prawie nigdy się nie zgadza, nawet przy idealnie zsynchronizowanym zamówieniu, a każde porównanie sum częściowych dziedziczy tę różnicę. Najpierw porównuj sumy; wiersze porównuj dopiero po wykluczeniu wierszy wysyłki i opłat po stronie Odoo.

To samo dotyczy osi dostawy: za wierszem usługi nie stoi żaden ruch magazynowy, więc jego ilość dostarczona zostaje na zawsze zerowa. To zachowanie poprawne, a nie zaległa wysyłka.

8 Przyczyna 8: waluta, presentment money i zaokrąglenia

Shopify zwraca każde pole pieniężne podwójnie: shopMoney w walucie twojego sklepu i presentmentMoney w walucie, którą faktycznie widział klient. Jeśli sprzedajesz w wielu walutach, konektor zaimportował jedną z nich, a ty możesz czytać tę drugą.

Odoo dokłada własne, drugie przeliczenie: zamówienie jest zapisane we własnej walucie i przeliczane na walutę firmy po kursie z danego dnia. Nieaktualny kurs daje niewielką różnicę, która zawsze przechyla się w tę samą stronę — to wiarygodna wskazówka, bo prawdziwe błędy rzadko bywają aż tak konsekwentne.

Jest też zwykłe zaokrąglenie. Różnice rzędu jednego do trzech groszy przy zamówieniach wielowierszowych z procentowymi rabatami w wierszach to zaokrąglenie, a gonienie za nimi to stracone popołudnie. Wszystko większe ma za sobą jedną z powyższych przyczyn.

Szybki przewodnik: od objawu do przyczyny

Pięciominutowa kontrola, którą można powtarzać

Gdy rozbieżność ląduje na twoim biurku, ta kolejność rozwiązuje ją szybciej niż wpatrywanie się w dwa ekrany:

1. Otwórz zamówienie w Shopify. Zapisz bieżącą sumę i sprawdź, czy ma zwroty albo czy było edytowane.
2. Otwórz zamówienie sprzedaży w Odoo. Zapisz amount_total i spójrz na invoice_status.
3. Jeśli jest zafakturowane: zsumuj zaksięgowane faktury, odejmij zaksięgowane korekty i porównaj tę liczbę — nie sumę zamówienia — z bieżącą sumą Shopify.
4. Jeśli nie jest jeszcze zafakturowane: porównaj z amount_total i traktuj wynik jako tymczasowy. Zmieni się w chwili zaksięgowania faktury.
5. Jeśli nadal się nie zgadzają, przejdź osiem przyczyn po kolei: najpierw podatek, potem fakturowanie, zwroty, edycje, karty podarunkowe, artefakty, wysyłka, waluta. Pierwsza, która pasuje, prawie zawsze jest odpowiedzią.

Pięć minut na zamówienie jest w porządku, gdy zdarza się to dwa razy w miesiącu. Przestaje być w porządku, gdy pracownik obsługi klienta musi to robić przed odpowiedzią na każdy e-mail „naliczyliście mi złą kwotę”, albo gdy ktoś musi wyrywkowo sprawdzić dzień zamówień przed zamknięciem okresu.

Czytaj dalej

• Przewodnik użytkownika
• Cennik
• Historia zmian