DHL e GLS no Odoo: o módulo OCA, o que cobre e o que lhe vai faltar

No Odoo 19 há módulo OCA da DHL Parcel e não há módulo OCA da GLS. delivery_dhl_parcel está publicado na ramo 19.0 de OCA/l10n-spain, versão 19.0.1.0.2. delivery_gls_asm vai da 12.0 à 18.0 e não está migrado. Se o plano era passar para o Odoo 19 e continuar a emitir etiquetas GLS a partir da guia de remessa, este é o primeiro número a ver.

GLS ou DHL: porque não é a mesma decisão

A GLS Espanha é encomenda expresso: volumes pequenos e rede de agências. A integração ganha-se ou perde-se na etiqueta e no estado, e a sua razão de ser é o volume: cem etiquetas por dia que ninguém quer digitar.

A DHL no Odoo não é uma marca: são dois produtos com APIs diferentes. O módulo OCA avisa-o no seu readme/DESCRIPTION.md: «No es válido para otras integraciones de DHL como el Express, que usan otras APIs». E a documentação oficial do Odoo 19, na sua tabela de conectores, lista DHL Express e remata: «Other services from DHL are not supported».

A consequência: se o seu contrato é DHL Express, o módulo OCA não lhe serve e o conector nativo não vem na Community: em addons/ do repositório público de odoo/odoo, nas versões 17, 18 e 19, o único módulo de transportadora é delivery_mondialrelay. Se é DHL Parcel Espanha, o módulo OCA é o caminho. É uma pergunta para o seu comercial da DHL antes de ser para o seu integrador.

Que módulo OCA existe de facto, e em que repositório

A confusão começa no sítio errado: procura «OCA DHL Odoo» e aterra em OCA/delivery-carrier, o repositório de logística da OCA. Lá não está: não há módulo da DHL em nenhum ramo da 12.0 à 19.0, e da GLS só resta uma pasta fantasma na 16.0 com um ficheiro lá dentro, static/description/index.html. Nem manifesto nem código.

Os dois módulos vivos estão em OCA/l10n-spain, e convém ajustar a expectativa: no ramo 19.0 de OCA/delivery-carrier o único módulo que chama a API de uma transportadora é delivery_correos_express; o resto é infraestrutura. E na 19.0 de OCA/l10n-spain há três transportadoras: delivery_dhl_parcel, delivery_mrw e delivery_seur_atlas.

O que cobre cada módulo, lido no seu código

Na DHL Parcel tudo sai de um método, _prepare_dhl_parcel_shipping: um dicionário plano que se lê em dois minutos.

• Etiqueta em PDF, ZPL ou EPL anexa à guia de remessa, com o AWB e o seguimento.
• Cobrança à entrega a partir do total da encomenda, com a repartição de custos segundo o incoterm.
• Seguro opcional, devoluções, fecho de dia por assistente e entrega antes das 13:30.
• Três limites escritos no módulo: não cota (o seu ROADMAP diz que os envios «siempre se cotizan a 0»), nome e morada são cortados aos 40 caracteres, e o peso mínimo que viaja é 1 kg mesmo que o volume pese 200 g.

O equivalente na GLS é _prepare_gls_asm_shipping, mais longo porque a API exige remetente e destinatário completos em cada chamada:

• Serviço e faixa horária por método de envio, etiqueta PDF e etiqueta de devolução.
• Seguimento com histórico completo e prova de entrega anexa à guia de remessa.
• Recolhas como fluxo próprio: doze códigos de serviço marcados como recolha, com botão e estados à parte.
• Cancelamento com salvaguarda: atualiza o estado e só anula se o envio continuar em «registado na transportadora»; caso contrário, lança um erro e manda-o tratar do assunto por e-mail com a GLS.
• Os seus limites: a referência não pode passar de 15 caracteres (a GLS trunca e colidem), também não cota, e o país do remetente está fixado em Espanha no código, com o comentário always 34=Spain.

Alfândega e exportação: os campos que o OCA deixa vazios

A lacuna tem uma forma concreta: o Odoo traz os campos e os módulos OCA não os usam. Não falta a informação: o que acontece é que não viaja. O que o Odoo 19 tem, em stock_delivery:

• product.template.hs_code, com a etiqueta «HS Code» e a ajuda «Standardized code for international shipping and goods declaration». É a posição pautal.
• product.template.country_of_origin, com a etiqueta «Origin of Goods», relação com res.country.
• Uma classe DeliveryCommodity (docstring literal: «Commodities information are needed for Commercial invoices with each provider») com produto, quantidade, valor monetário e país de origem, mais dois métodos que a constroem. Se o produto não tem país de origem, usa-se o do armazém que expede.

O que os módulos OCA fazem com isso: nada. Procurar hs_code, customs, aduana, arancel, incoterm ou country_of_origin em todo o módulo da GLS devolve zero resultados. No da DHL Parcel aparecem, e aí está o interessante, porque aparecem vazios:

delivery_dhl_parcel · models/delivery_carrier.py · _prepare_dhl_parcel_shipping

Três campos previstos pela API e os três enviados vazios: valor declarado, divisa e descrição da mercadoria. O incoterm viaja, mas repare de onde sai (de self, do método de envio, não da guia de remessa) e no código só há dois valores, CPT e EXW: um fixo para essa transportadora toda. Na GLS o equivalente é o campo declarado, que também sai vazio. E nenhuma das quatro transportadoras que restam na 19.0 desses dois repositórios (DHL Parcel, MRW, SEUR e Correos Express) menciona DeliveryCommodity, hs_code nem country_of_origin: a canalização que o Odoo deixou preparada está por ligar.

O que lhe falta no dia em que exporta:

• Posição pautal e país de origem, por linha. Existem no produto, não saem para a transportadora.
• Valor declarado e a sua divisa. Previsto na API da DHL Parcel. Envia-se vazio.
• Descrição da mercadoria. Campo previsto. Envia-se vazio.
• Documento comercial. Uma proforma gerada a partir da guia de remessa e anexa ao envio. Não existe em nenhum.
• Incoterm por envio. Existe por transportadora, e com dois valores.

Não é um descuido destes dois: é o padrão. delivery_schenker envia "customsClearance": False com o comentário «Customs Clearance not supported for now as it needs a full customs implementation», e o seu ROADMAP inclui o desembaraço aduaneiro entre o que não é suportado; esse módulo chega à 18.0 e também não está na 19.0. Quando um módulo OCA faz mesmo alfândega a sério, não a resolve com um campo: acrescenta um modelo próprio com posição pautal e país de origem por linha de mercadoria. Essa é a medida real do trabalho.

O que acontece quando falta um desses campos

Nada, e esse é o problema. Os campos são opcionais na API: a transportadora aceita a expedição, devolve seguimento e a etiqueta sai na impressora. No Odoo a guia de remessa fica validada e a verde. A falha acontece depois, no desembaraço aduaneiro no destino: o pacote pára e alguém da sua empresa digita à mão a posição pautal, a descrição e o valor que a transportadora pede. Silencioso no Odoo e ruidoso no apoio ao cliente.

Convém ser exato sobre quando se aplica. Não de Barcelona a Munique: a UE é mercado interno e aí não há fronteira aduaneira. Aplica-se ao sair do território (Reino Unido, Suíça, Noruega, Andorra, Turquia) e, sem sair de Espanha, nas Canárias, em Ceuta e em Melilla. A Ley 37/1992 do IVA di-lo no seu artigo 3: exclui Ceuta e Melilla «en cuanto territorios no comprendidos en la Unión Aduanera» e as Canárias «en cuanto territorios excluidos de la armonización de los impuestos sobre el volumen de negocios».

E também não espere um limiar abaixo do qual a formalidade desapareça. Do lado da importação, que é o que a norma espanhola detalha, o Real Decreto-ley 7/2021 (BOE-A-2021-6872) transpôs o pacote de IVA do comércio eletrónico com efeitos desde 1 de julho de 2021: suprimiu a isenção das importações de bens de pequeno valor «hasta los 22 euros de valor global de la mercancía», e explica que até 150 euros de valor intrínseco «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». Leia-o ao contrário: abaixo de 150 euros a declaração é mais curta, não é nula. E quem a tem de preencher continua a precisar de descrição, valor e posição pautal: precisamente os campos que o módulo envia vazios.

Quando o OCA basta e quando precisa de mais

O módulo OCA é a resposta certa se envia dentro da UE sem atravessar fronteira aduaneira, se o que quer é deixar de digitar moradas e não uma tarifa exata na encomenda, e se está no Odoo 18 ou anterior: ou no 19 com a DHL Parcel.

Precisa de mais se:

• Exporta com regularidade, ou envia para as Canárias, Ceuta ou Melilla. O trabalho não é «instalar o módulo»: é preencher hs_code e país de origem, estender o payload e gerar o documento comercial.
• Está no Odoo 19 com a GLS: hoje não há módulo, por isso ou se migra delivery_gls_asm ou se muda de via.
• O seu contrato é DHL Express, ou expede com a GLS a partir de fora de Espanha.

Uma nota de método para fechar: estender um módulo OCA é a via barata quando a lacuna é um campo, e deixa de o ser quando a lacuna é um documento. Meter a posição pautal e o país de origem no payload é herdar _prepare_dhl_parcel_shipping e acrescentar vinte linhas. Gerar uma proforma que bata certo com a contabilidade já é um módulo, com modelo, testes e manutenção em três versões.

Perguntas frequentes

Continuar por aqui

O que fazemos sobre isto