DHL und GLS in Odoo: das OCA-Modul, was es abdeckt und was Ihnen fehlen wird

In Odoo 19 gibt es ein OCA-Modul für DHL Parcel, aber keines für GLS. delivery_dhl_parcel ist im Zweig 19.0 von OCA/l10n-spain veröffentlicht, Version 19.0.1.0.2. delivery_gls_asm reicht von 12.0 bis 18.0 und ist nicht migriert. Wenn der Plan war, auf Odoo 19 zu wechseln und weiter GLS-Etiketten aus dem Lieferschein zu drucken, ist das die erste Zahl, die Sie prüfen sollten.

GLS oder DHL: warum es nicht dieselbe Entscheidung ist

GLS España ist Paketversand: kleine Pakete und ein Netz aus Agenturen. Die Integration steht und fällt mit dem Etikett und dem Status, und ihr Sinn liegt im Volumen: hundert Etiketten am Tag, die niemand abtippen will.

DHL in Odoo ist keine einzelne Marke, sondern zwei Produkte mit unterschiedlichen APIs. Das OCA-Modul weist in seiner readme/DESCRIPTION.md darauf hin: «No es válido para otras integraciones de DHL como el Express, que usan otras APIs». Und die offizielle Odoo-19-Dokumentation führt in ihrer Tabelle der Konnektoren DHL Express auf und schließt mit: «Other services from DHL are not supported».

Die Folge: Wenn Ihr Vertrag DHL Express ist, nützt Ihnen das OCA-Modul nichts, und der native Konnektor ist in der Community nicht enthalten: In addons/ des öffentlichen Repositorys odoo/odoo ist in 17, 18 und 19 das einzige Zusteller-Modul delivery_mondialrelay. Wenn es DHL Parcel España ist, ist das OCA-Modul der richtige Weg. Das ist eher eine Frage an Ihren DHL-Ansprechpartner als an Ihren Integrator.

Welches OCA-Modul es wirklich gibt und in welchem Repository

Die Verwirrung beginnt am falschen Ort: Sie suchen «OCA DHL Odoo» und landen bei OCA/delivery-carrier, dem Logistik-Repository der OCA. Dort ist es nicht: In keinem Zweig von 12.0 bis 19.0 gibt es ein DHL-Modul, und von GLS bleibt nur ein Geisterordner in 16.0 mit einer einzigen Datei, static/description/index.html. Weder Manifest noch Code.

Die beiden lebendigen Module liegen in OCA/l10n-spain, und die Erwartung sollte angepasst werden: Im Zweig 19.0 von OCA/delivery-carrier ist das einzige Modul, das die API eines Zustellers aufruft, delivery_correos_express; der Rest ist Infrastruktur. Und im Zweig 19.0 von OCA/l10n-spain gibt es drei Zusteller: delivery_dhl_parcel, delivery_mrw und delivery_seur_atlas.

Was jedes Modul abdeckt, gelesen im Code

Bei DHL Parcel geht alles von einer Methode aus, _prepare_dhl_parcel_shipping: ein flaches Dictionary, das man in zwei Minuten liest.

• Etikett als PDF, ZPL oder EPL, am Lieferschein angehängt, mit AWB und Sendungsverfolgung.
• Nachnahme aus dem Auftragsgesamtbetrag, mit Aufteilung der Kosten nach Incoterm.
• Optionale Versicherung, Retouren, Tagesabschluss per Assistent und Zustellung vor 13:30 Uhr.
• Drei im Modul festgehaltene Grenzen: Es kalkuliert keine Preise (sein ROADMAP besagt, dass Sendungen «siempre se cotizan a 0»), Name und Adresse werden auf 40 Zeichen gekürzt, und das Mindestgewicht, das übermittelt wird, ist 1 kg, auch wenn das Paket 200 g wiegt.

Das Gegenstück bei GLS ist _prepare_gls_asm_shipping, länger, weil die API bei jedem Aufruf vollständige Angaben zu Absender und Empfänger verlangt:

• Service und Zeitfenster je Liefermethode, PDF-Etikett und Retourenetikett.
• Sendungsverfolgung mit vollständigem Verlauf und Zustellnachweis am Lieferschein.
• Abholungen als eigener Ablauf: zwölf Servicecodes als Abholung markiert, mit eigener Schaltfläche und eigenen Status.
• Stornierung mit Sicherung: Sie aktualisiert den Status und storniert nur, wenn die Sendung noch auf «registrado en el transportista» steht; andernfalls wirft sie einen Fehler und verweist Sie darauf, den Fall per E-Mail mit GLS zu klären.
• Ihre Grenzen: Die Referenz darf 15 Zeichen nicht überschreiten (GLS kürzt, und es kommt zu Kollisionen), sie kalkuliert ebenfalls keine Preise, und das Absenderland ist im Code fest auf Spanien gesetzt, mit dem Kommentar always 34=Spain.

Zoll und Export: die Felder, die das OCA-Modul leer lässt

Die Lücke hat eine konkrete Form: Odoo bringt die Felder mit, und die OCA-Module nutzen sie nicht. Es fehlt nicht die Information: Sie wird nur nicht übermittelt. Was Odoo 19 in stock_delivery hat:

• product.template.hs_code, beschriftet «HS Code», mit dem Hilfetext «Standardized code for international shipping and goods declaration». Das ist die Zolltarifnummer.
• product.template.country_of_origin, beschriftet «Origin of Goods», Beziehung zu res.country.
• Eine Klasse DeliveryCommodity (Docstring wörtlich: «Commodities information are needed for Commercial invoices with each provider») mit Produkt, Menge, Geldwert und Ursprungsland, dazu zwei Methoden, die sie aufbauen. Hat das Produkt kein Ursprungsland, wird das des versendenden Lagers verwendet.

Was die OCA-Module damit tun: nichts. Die Suche nach hs_code, customs, aduana, arancel, incoterm oder country_of_origin im gesamten GLS-Modul liefert null Treffer. Im DHL-Parcel-Modul tauchen sie auf, und genau da wird es interessant, denn sie tauchen leer auf:

delivery_dhl_parcel · models/delivery_carrier.py · _prepare_dhl_parcel_shipping

Drei von der API vorgesehene Felder, alle drei leer gesendet: Warenwert, Währung und Warenbeschreibung. Der Incoterm wird übermittelt, aber beachten Sie, woher er kommt (aus self, also von der Liefermethode, nicht vom Lieferschein), und im Code gibt es nur zwei Werte, CPT und EXW: einen festen für den gesamten Zusteller. Bei GLS ist das Gegenstück das Feld declarado, das ebenfalls leer ausgeht. Und keiner der vier Zusteller, die in 19.0 dieser beiden Repositories übrig bleiben (DHL Parcel, MRW, SEUR und Correos Express), erwähnt DeliveryCommodity, hs_code oder country_of_origin: Die von Odoo vorbereitete Leitung ist nicht angeschlossen.

Was Ihnen am Exporttag fehlt:

• Zolltarifnummer und Ursprungsland, pro Position. Sie existieren am Produkt, gehen aber nicht an den Zusteller.
• Warenwert und seine Währung. In der API von DHL Parcel vorgesehen. Wird leer gesendet.
• Warenbeschreibung. Vorgesehenes Feld. Wird leer gesendet.
• Handelsdokument. Eine aus dem Lieferschein erzeugte und der Sendung angehängte Proforma. Gibt es in keinem.
• Incoterm pro Sendung. Existiert pro Zusteller, und mit zwei Werten.

Das ist kein Versehen dieser beiden, sondern das Muster. delivery_schenker sendet "customsClearance": False mit dem Kommentar «Customs Clearance not supported for now as it needs a full customs implementation», und sein ROADMAP zählt die Zollabfertigung zu den nicht unterstützten Funktionen; dieses Modul reicht bis 18.0 und ist ebenfalls nicht in 19.0. Wenn ein OCA-Modul Zoll tatsächlich umsetzt, löst es das nicht mit einem Feld: Es fügt ein eigenes Modell mit Zolltarifnummer und Ursprungsland je Warenposition hinzu. Das ist das wahre Maß der Arbeit.

Was passiert, wenn eines dieser Felder fehlt

Nichts, und genau das ist das Problem. Die Felder sind in der API optional: Der Zusteller nimmt die Sendung an, liefert die Sendungsverfolgung, und das Etikett kommt aus dem Drucker. In Odoo ist der Lieferschein bestätigt und grün. Der Fehler tritt später bei der Zollabfertigung im Zielland auf: Das Paket bleibt hängen, und jemand in Ihrem Unternehmen tippt von Hand die Tarifnummer, die Beschreibung und den Wert ein, die der Zusteller verlangt. Still in Odoo und laut im Kundenservice.

Es lohnt sich, genau zu sein, wann das gilt. Nicht von Barcelona nach München: Die EU ist Binnenmarkt, dort gibt es keine Zollgrenze. Es gilt beim Verlassen des Gebiets (Vereinigtes Königreich, Schweiz, Norwegen, Andorra, Türkei) und, ohne Spanien zu verlassen, bei den Kanarischen Inseln, Ceuta und Melilla. Das spanische Mehrwertsteuergesetz (Ley 37/1992) sagt es in Artikel 3: Es schließt Ceuta und Melilla aus «en cuanto territorios no comprendidos en la Unión Aduanera» und die Kanarischen Inseln «en cuanto territorios excluidos de la armonización de los impuestos sobre el volumen de negocios».

Und erwarten Sie auch keine Schwelle, unterhalb derer der Aufwand entfällt. Auf der Einfuhrseite, die die spanische Norm im Detail regelt, hat das Real Decreto-ley 7/2021 (BOE-A-2021-6872) das Mehrwertsteuerpaket für den E-Commerce mit Wirkung zum 1. Juli 2021 umgesetzt: Es hat die Befreiung für Einfuhren von Waren mit geringem Wert «hasta los 22 euros de valor global de la mercancía» abgeschafft und erläutert, dass bis zu 150 Euro Warenwert «se aplica la franquicia aduanera por lo que no se exige una declaración completa ante la Aduana en el momento de la importación». Lesen Sie es andersherum: Unter 150 Euro ist die Anmeldung kürzer, nicht null. Und wer sie ausfüllen muss, braucht weiterhin Beschreibung, Wert und Tarifnummer: genau die Felder, die das Modul leer sendet.

Wann das OCA-Modul reicht und wann Sie mehr brauchen

Das OCA-Modul ist die richtige Antwort, wenn Sie innerhalb der EU versenden, ohne eine Zollgrenze zu überqueren, wenn Sie aufhören wollen, Adressen abzutippen, und keinen exakten Tarif im Auftrag brauchen, und wenn Sie auf Odoo 18 oder früher sind: oder auf 19 mit DHL Parcel.

Sie brauchen mehr, wenn:

• Sie regelmäßig exportieren oder auf die Kanarischen Inseln, nach Ceuta oder Melilla versenden. Die Arbeit besteht nicht darin, «das Modul zu installieren»: Sie müssen hs_code und Ursprungsland befüllen, den Payload erweitern und das Handelsdokument erzeugen.
• Sie auf Odoo 19 mit GLS sind: Derzeit gibt es kein Modul, also muss entweder delivery_gls_asm migriert oder ein anderer Weg gewählt werden.
• Ihr Vertrag DHL Express ist oder Sie mit GLS von außerhalb Spaniens versenden.

Eine methodische Anmerkung zum Schluss: Ein OCA-Modul zu erweitern ist der günstige Weg, solange die Lücke ein Feld ist, und hört auf, es zu sein, wenn die Lücke ein Dokument ist. Tarifnummer und Ursprungsland in den Payload zu bringen heißt, _prepare_dhl_parcel_shipping zu erben und zwanzig Zeilen hinzuzufügen. Eine Proforma zu erzeugen, die mit der Buchhaltung übereinstimmt, ist schon ein Modul, mit Vorlage, Tests und Wartung über drei Versionen.

Häufig gestellte Fragen

Hier weiterlesen

Was wir dazu anbieten