DHL i GLS w Odoo: moduł OCA, co obejmuje i czego Ci zabraknie

W Odoo 19 jest moduł OCA dla DHL Parcel, ale nie ma modułu OCA dla GLS. delivery_dhl_parcel jest opublikowany w gałęzi 19.0 repozytorium OCA/l10n-spain, w wersji 19.0.1.0.2. delivery_gls_asm obejmuje wersje od 12.0 do 18.0 i nie został zmigrowany. Jeśli planowałeś przejść na Odoo 19 i dalej drukować etykiety GLS z poziomu dokumentu dostawy, to jest pierwsza rzecz do sprawdzenia.

GLS czy DHL: dlaczego to nie jest ta sama decyzja

GLS España to przesyłki paczkowe: małe paczki i sieć oddziałów. Integracja wygrywa lub przegrywa na etykiecie i statusie, a jej sens to wolumen: sto etykiet dziennie, których nikt nie chce wpisywać ręcznie.

DHL w Odoo to nie jedna marka, lecz dwa produkty z różnymi API. Moduł OCA ostrzega o tym w swoim readme/DESCRIPTION.md: „No es válido para otras integraciones de DHL como el Express, que usan otras APIs” (nie obsługuje innych integracji DHL, takich jak Express, które korzystają z innych API). A dokumentacja Odoo 19 w tabeli konektorów wymienia DHL Express i dodaje: „Other services from DHL are not supported”.

Wniosek: jeśli Twoja umowa dotyczy DHL Express, moduł OCA Ci nie pomoże, a natywny konektor nie jest dostępny w Community: w addons/ publicznego repozytorium odoo/odoo, w wersjach 17, 18 i 19, jedynym modułem przewoźnika jest delivery_mondialrelay. Jeśli to DHL Parcel España, moduł OCA jest właściwą drogą. To pytanie raczej do Twojego opiekuna handlowego w DHL niż do integratora.

Który moduł OCA naprawdę istnieje i w jakim repozytorium

Zamieszanie zaczyna się w niewłaściwym miejscu: wyszukujesz „OCA DHL Odoo” i trafiasz do OCA/delivery-carrier, repozytorium logistycznego OCA. Tam go nie ma: w żadnej gałęzi od 12.0 do 19.0 nie ma modułu DHL, a po GLS został tylko katalog-widmo w 16.0 z jednym plikiem w środku, static/description/index.html. Bez manifestu i bez kodu.

Oba działające moduły znajdują się w OCA/l10n-spain i warto urealnić oczekiwania: w gałęzi 19.0 repozytorium OCA/delivery-carrier jedynym modułem, który wywołuje API przewoźnika, jest delivery_correos_express; reszta to infrastruktura. A w 19.0 repozytorium OCA/l10n-spain są trzej przewoźnicy: delivery_dhl_parcel, delivery_mrw i delivery_seur_atlas.

Co obejmuje każdy moduł, odczytane z kodu

W DHL Parcel wszystko wychodzi z jednej metody, _prepare_dhl_parcel_shipping: płaskiego słownika, który czyta się w dwie minuty.

• Etykieta w PDF, ZPL lub EPL dołączona do dokumentu dostawy, z numerem AWB i śledzeniem.
• Pobranie z kwoty całkowitej zamówienia, z podziałem kosztów zależnym od Incoterm.
• Opcjonalne ubezpieczenie, zwroty, zamknięcie dnia za pomocą kreatora i dostawa przed 13:30.
• Trzy ograniczenia zapisane w module: nie wycenia (jego ROADMAP mówi, że przesyłki są „zawsze wyceniane na 0”), imię i nazwisko oraz adres są obcinane do 40 znaków, a minimalna waga w przesyłce to 1 kg, nawet jeśli paczka waży 200 g.

Odpowiednik w GLS to _prepare_gls_asm_shipping, dłuższy, bo API wymaga w każdym wywołaniu pełnych danych nadawcy i odbiorcy:

• Usługa i przedział czasowy dla każdej metody dostawy, etykieta PDF i etykieta zwrotna.
• Śledzenie z pełną historią i potwierdzeniem dostawy dołączonym do dokumentu dostawy.
• Odbiory jako osobny proces: dwanaście kodów usług oznaczonych jako odbiór, z osobnym przyciskiem i statusami.
• Anulowanie z zabezpieczeniem: odświeża status i anuluje tylko wtedy, gdy przesyłka nadal ma status „registrado en el transportista”; w przeciwnym razie zgłasza błąd i odsyła do załatwienia sprawy mailowo z GLS.
• Jego ograniczenia: referencja nie może przekraczać 15 znaków (GLS ją obcina i dochodzi do kolizji), również nie wycenia, a kraj nadawcy jest na stałe ustawiony na Hiszpanię w kodzie, z komentarzem always 34=Spain.

Cło i eksport: pola, które OCA zostawia puste

Luka ma konkretny kształt: Odoo dostarcza pola, a moduły OCA ich nie używają. Nie brakuje informacji: po prostu nie jest przesyłana. Co Odoo 19 faktycznie ma, w stock_delivery:

• product.template.hs_code, z etykietą „HS Code” i podpowiedzią „Standardized code for international shipping and goods declaration”. To kod taryfy celnej.
• product.template.country_of_origin, z etykietą „Origin of Goods”, relacja do res.country.
• Klasa DeliveryCommodity (docstring dosłownie: „Commodities information are needed for Commercial invoices with each provider”) z produktem, ilością, wartością pieniężną i krajem pochodzenia, plus dwie metody, które ją budują. Jeśli produkt nie ma kraju pochodzenia, używany jest kraj magazynu wysyłającego.

Co z tym robią moduły OCA: nic. Wyszukanie hs_code, customs, aduana, arancel, incoterm lub country_of_origin w całym module GLS daje zero wyników. W module DHL Parcel te pola się pojawiają i właśnie to jest interesujące, bo pojawiają się puste:

delivery_dhl_parcel · models/delivery_carrier.py · _prepare_dhl_parcel_shipping

Trzy pola przewidziane przez API i wszystkie trzy wysyłane puste: wartość deklarowana, waluta i opis towaru. Incoterm jest przesyłany, ale zwróć uwagę, skąd pochodzi (z self, z metody dostawy, a nie z dokumentu dostawy), a w kodzie są tylko dwie wartości, CPT i EXW: jedna stała dla całego tego przewoźnika. W GLS odpowiednikiem jest pole declarado, które również wychodzi puste. A żaden z czterech przewoźników, którzy zostali w 19.0 tych dwóch repozytoriów (DHL Parcel, MRW, SEUR i Correos Express), nie wspomina o DeliveryCommodity, hs_code ani country_of_origin: instalacja, którą Odoo przygotowało, jest niepodłączona.

Czego Ci brakuje w dniu eksportu:

• Kod taryfy celnej i kraj pochodzenia, dla każdej pozycji. Istnieją w produkcie, ale nie trafiają do przewoźnika.
• Wartość deklarowana i jej waluta. Przewidziane w API DHL Parcel. Wysyłane puste.
• Opis towaru. Pole przewidziane. Wysyłane puste.
• Dokument handlowy. Proforma wygenerowana z dokumentu dostawy i dołączona do przesyłki. Nie istnieje w żadnym z modułów.
• Incoterm dla każdej przesyłki. Istnieje dla przewoźnika, i to z dwiema wartościami.

To nie przeoczenie tych dwóch modułów: to wzorzec. delivery_schenker wysyła "customsClearance": False z komentarzem „Customs Clearance not supported for now as it needs a full customs implementation”, a jego ROADMAP zalicza odprawę celną do rzeczy nieobsługiwanych; ten moduł dochodzi do 18.0 i również nie ma go w 19.0. Gdy moduł OCA naprawdę obsługuje cło, nie rozwiązuje tego jednym polem: dodaje własny model z kodem taryfy i krajem pochodzenia dla każdej pozycji towaru. To realna miara pracy.

Co się dzieje, gdy brakuje któregoś z tych pól

Nic, i w tym właśnie problem. Pola są w API opcjonalne: przewoźnik przyjmuje przesyłkę, zwraca numer śledzenia, a etykieta wychodzi z drukarki. W Odoo dokument dostawy jest zatwierdzony i na zielono. Błąd pojawia się później, w odprawie celnej w kraju przeznaczenia: paczka staje, a ktoś z Twojej firmy ręcznie wpisuje kod taryfy, opis i wartość, o które prosi przewoźnik. Cicho w Odoo, głośno w obsłudze klienta.

Warto być dokładnym co do tego, kiedy to dotyczy. Nie dotyczy trasy z Barcelony do Monachium: UE to rynek wewnętrzny i nie ma tam granicy celnej. Dotyczy wyjazdu poza to terytorium (Wielka Brytania, Szwajcaria, Norwegia, Andora, Turcja) oraz, nie opuszczając Hiszpanii, Wysp Kanaryjskich, Ceuty i Melilli. Ustawa 37/1992 o VAT mówi o tym w artykule 3: wyłącza Ceutę i Melillę „en cuanto territorios no comprendidos en la Unión Aduanera” (jako terytoria nieobjęte unią celną) oraz Wyspy Kanaryjskie „en cuanto territorios excluidos de la armonización de los impuestos sobre el volumen de negocios” (jako terytoria wyłączone z harmonizacji podatków obrotowych).

I nie oczekuj progu, poniżej którego formalność znika. Po stronie importu, którą szczegółowo opisują przepisy hiszpańskie, dekret z mocą ustawy 7/2021 (BOE-A-2021-6872) wdrożył pakiet VAT dla handlu elektronicznego ze skutkiem od 1 lipca 2021 r.: zniósł zwolnienie importu towarów o niskiej wartości „do 22 euro łącznej wartości towaru” i wyjaśnia, że do 150 euro wartości rzeczywistej „stosuje się zwolnienie celne, więc w momencie importu nie wymaga się pełnej deklaracji w urzędzie celnym”. Czytaj to odwrotnie: poniżej 150 euro deklaracja jest krótsza, nie zerowa. A ten, kto ją wypełnia, nadal potrzebuje opisu, wartości i kodu taryfy: dokładnie tych pól, które moduł wysyła puste.

Kiedy OCA wystarcza, a kiedy potrzeba czegoś więcej

Moduł OCA to właściwa odpowiedź, jeśli wysyłasz w obrębie UE bez przekraczania granicy celnej, jeśli chcesz przestać wpisywać adresy ręcznie, a nie potrzebujesz dokładnej stawki w zamówieniu, i jeśli jesteś na Odoo 18 lub starszym albo na 19 z DHL Parcel.

Potrzebujesz czegoś więcej, jeśli:

• Regularnie eksportujesz albo wysyłasz na Wyspy Kanaryjskie, do Ceuty lub Melilli. Praca nie polega na „zainstalowaniu modułu”: trzeba uzupełnić hs_code i kraj pochodzenia, rozszerzyć payload i wygenerować dokument handlowy.
• Jesteś na Odoo 19 z GLS: dziś nie ma modułu, więc albo migruje się delivery_gls_asm, albo zmienia się rozwiązanie.
• Twoja umowa dotyczy DHL Express albo wysyłasz z GLS spoza Hiszpanii.

Na koniec uwaga metodyczna: rozszerzenie modułu OCA to tania droga, gdy luką jest pole, a przestaje nią być, gdy luką jest dokument. Dodanie kodu taryfy i kraju pochodzenia do payloadu to odziedziczenie _prepare_dhl_parcel_shipping i dopisanie dwudziestu linii. Wygenerowanie proformy zgodnej z księgowością to już moduł, z szablonem, testami i utrzymaniem w trzech wersjach.

Najczęstsze pytania

Czytaj dalej

Co robimy w tym temacie