Odoo 19 vs conectores com middleware: quando convém integrar dentro do Odoo

Um conector nativo no Odoo 19 convém quando o Odoo manda no stock, nas encomendas, nos envios e nas faturas: cada estado existe uma só vez, na ficha onde a equipa trabalha. Um middleware convém quando apenas é preciso transportar dados sem tomar decisões operacionais, ou quando ninguém vai manter código dentro do Odoo. Ligar uma API uma vez nunca foi o problema: o problema é manter encomendas, stock, erros e rastreabilidade quando a operação cresce.

A diferença real não está na API

A API da Amazon, da Mirakl ou de uma transportadora é a mesma, seja quem for que a chame. O que muda é quem guarda o resultado e onde o vê a pessoa que prepara a encomenda: é aí que está a diferença, não na API.

Se o Odoo deve reservar stock, preparar encomendas, gerar guias de remessa, criar etiquetas e devolver o tracking ao canal, a integração nativa deixa a rastreabilidade onde a equipa trabalha. Com uma camada intermédia, cada passo existe duas vezes e as duas cópias só coincidem se alguém o verificar.

Quando escolher um conector nativo no Odoo

Faz sentido quando o Odoo é o sistema mestre de produto, stock, encomendas, logística e faturação. Também quando precisa de regras próprias: multiarmazém, validações antes de enviar, novas tentativas, registo de chamadas por encomenda e erros que o utilizador vê no seu ecrã.

Nos nossos conectores de marketplace, o registo de cada chamada é um modelo do Odoo com método, endpoint, parâmetros, corpo enviado, código e corpo da resposta, tentativa e duração em milissegundos, com purga configurável. Filtra-se como qualquer lista do Odoo, sem depender de um painel externo.

Quando um middleware pode servir

Se apenas move dados simples entre dois sistemas, sem decisões operacionais complexas, um middleware pode acelerar o arranque. Também se vários ERP vendem nos mesmos canais e o stock publicado tem de ser a soma. E, sobretudo, se ninguém, nem interno nem partner de Odoo, vai manter código dentro do ERP.

O risco aparece quando a equipa consulta três painéis para saber se uma encomenda está vendida, reservada, enviada ou falhada: nesse dia o middleware deixou de transportar e passou a guardar estado.

O que custa um middleware no trabalho diário

A conta que importa não é a mensalidade: são as tarefas que surgem assim que há uma camada intermédia e que ninguém orça. São quatro.

1. O duplo mestre. O produto é criado no Odoo e, além disso, mapeado no middleware: SKU, categoria do canal, atributos obrigatórios. Cada criação, cada alteração de EAN e cada variante nova são duas edições. Com um conector nativo, o mapeamento para o canal é mais um campo do produto no Odoo.
2. A reconciliação de estados. Uma encomenda de marketplace tem três verdades: a do canal, a do middleware e a do Odoo. Quando não coincidem (uma encomenda cancelada no canal que no Odoo continua a reservar stock) alguém descobre-o à mão. Com o conector dentro do Odoo ficam duas, e o estado remoto é guardado tal como a API o devolve, junto da encomenda de venda, com a hora da última sincronização.
3. Quem vê o log. O erro de uma chamada vive no painel do fornecedor, com o seu utilizador e a sua retenção. Quem vê a encomenda encravada no Odoo normalmente não tem acesso a esse painel. Se o log é um modelo do Odoo, vê-o quem tem o problema, no mesmo ecrã.
4. A subida de versão. Quando o Odoo passa da 18 para a 19, o middleware promete que o seu lado não muda. O que muda é o do Odoo: o módulo ponte do fornecedor, os campos que lê e os webhooks que espera. Essa migração faz-se de qualquer forma, ao ritmo do fornecedor e não ao seu; publicamos para a 19, a 18 e a 17 em simultâneo, como contamos em manter um módulo em três versões.

Se já paga uma camada intermédia e suspeita que lhe sobra, o plano de corte por canal está em do middleware à ligação nativa no Odoo, contado a partir da nossa própria migração da Amazon em produção.

Onde se perde a rastreabilidade

O ponto exato é a guia de remessa. No Odoo, a guia (stock.picking) herda de mail.thread e o seu estado tem seguimento, pelo que cada passagem a «feito» fica registada com data e utilizador. Com o módulo de entrega, o número de seguimento da transportadora é um campo da própria guia (carrier_tracking_ref). Tudo isto vem de origem.

O que o Odoo não sabe de origem é se esse tracking chegou ao marketplace. Com um middleware, a cadeia encomenda → guia → tracking → confirmação ao canal parte-se em duas: os dois primeiros elos no Odoo, os dois últimos no painel do fornecedor. O chatter da guia diz «feito», e a prova de que o comprador viu o seu número está noutro sistema.

Um conector nativo fecha a cadeia no mesmo sítio. No nosso conector da Mirakl, validar a guia dispara o envio do tracking se a instância o tiver ativado, e o resultado fica escrito no chatter: uma nota se foi enviado, outra com o erro se falhou, e outra diferente se a guia não tinha número de seguimento e nada foi enviado. As chamadas à Mirakl passam pela gateway da FlexigoTech Cloud, que não guarda nem regista o que elas transportam, pelo que o que aconteceu com cada envio fica no seu Odoo.

Nativo também não é magia: 32 falhas com os testes verdes

A parte incómoda é nossa: «nativo» significa que o código vive no Odoo, não que funcione. Auditámos um conector de marketplace próprio antes de o pôr à frente de um vendedor real. A suite dava 236 de 236 em verde, sobre builds reais do Odoo.sh na 19, na 18 e na 17. Por baixo havia 32 falhas reais: 20 de contrato com a API e 12 de versão do Odoo.

As de contrato eram parâmetros que a API exigia e não eram enviados, e campos de resposta lidos com o nome errado, que devolvem None sem lançar nada. Quatro só apareceram ao chamar: o cabeçalho de paginação chegava relativo e a partir da página um não se importava nenhuma encomenda; um 403 por quota não vinha no formato documentado e era lido como falta de permissões, parando a sincronização inteira. As de versão eram do próprio Odoo: um cron que na 17 corre uma vez e se desliga sozinho, um campo de grupos que se chama de outra forma a partir da 19, uma vista de lista que a 17 rejeita. Metade não dava erro: dava silêncio.

O caso completo (incluindo um segundo conector com 163 de 163 em verde que nunca tinha escrito uma linha de log) está em os testes estavam verdes e o conector não funcionava. A conclusão para quem compara: peça ao conector nativo o mesmo que ao middleware. Que esteja realmente instalado na sua versão, e não apenas que compile; que tenha sido confrontado com a especificação do fornecedor e não com os seus próprios mocks; e que tenha feito pelo menos uma chamada real por família de endpoint. Se o herdar de outra pessoa, a lista está em auditar um conector Odoo herdado.

Checklist de decisão

• Onde se reserva o stock, e quantos sistemas guardam uma cópia do disponível?
• Quem cria a guia de remessa e a etiqueta?
• Onde se vê o erro quando uma API falha, e vê-o a mesma pessoa que vê a encomenda?
• O tracking volta ao canal automaticamente, e fica registado na guia que voltou?
• Pode voltar a tentar sem duplicar encomendas ou envios?
• Quem migra o conector quando sair a versão seguinte do Odoo, e em que prazo?
• Foi realmente instalado na sua versão e testado contra a sandbox do fornecedor?

A ordem pela qual se ligam vários canais depende de qual publica o stock: tratamo-lo em vender em vários marketplaces a partir de um só Odoo. Os conectores que já comunicam com a Amazon, a Mirakl, a ManoMano, o AliExpress e as transportadoras estão no catálogo e em integrações e automação Odoo; se é para o seu próprio software, conector Odoo para o seu software.

Perguntas frequentes

Ligações úteis dentro da FlexigoTech

O que fazemos sobre isto