Guia de integração do Odoo com o SkyPlanner APS para programação da produção

Prepare-se desde já para a remoção. A Odoo prevê remover XML-RPC e JSON-RPC no Odoo 22 (outono de 2028) e no Odoo Online 21.1 (inverno de 2027). Desenvolva sobre JSON-2 para a versão 19.0 e isole o acesso por RPC num único adaptador para bases de dados mais antigas. Assim, uma atualização exige apenas uma alteração. Os controladores personalizados com @route(type='jsonrpc') não são afetados pela remoção.

Autenticação

Crie um utilizador dedicado à integração, com acesso de leitura a Manufacturing e Inventory e de escrita às ordens de fabrico. Gere a respetiva chave em Preferences > Account Security > New API Key. Na versão 19.0, as chaves têm uma validade máxima de três meses, pelo que o middleware tem de assegurar a rotação de chaves e emitir um alerta em caso de falha de autenticação. Sem estas medidas, uma chave expirada interrompe a sincronização sem que ninguém se aperceba. Do lado do SkyPlanner, a API REST usa JWT, pelo que o middleware guarda ambas as credenciais.

Cada chamada JSON-2 é executada na sua própria transação SQL. Por isso, uma escrita repartida por várias chamadas não é atómica. Faça a escrita por ordem de fabrico e registe cada resultado.

Eventos

O Odoo envia alterações através de regras de automatização. Uma regra em mrp.production ou mrp.workorder, com o acionador On create and edit e a ação “Send Webhook Notification” (enviar notificação por webhook), envia um POST com os campos selecionados para um URL. Crie a regra no Studio ou, em modo de programador, no formulário Automation Rules. Combine-a com uma consulta periódica search_read sobre write_date para detetar importações e tudo o que tenha escapado à regra. No sentido inverso, os webhooks do SkyPlanner enviam as alterações à programação e ao estado à medida que ocorrem.

Os nomes dos campos variam entre versões. Na versão 19.0, cada base de dados apresenta os seus modelos, campos e métodos em /doc; nas versões anteriores, utilize fields_get. Faça o mapeamento com base nessa informação, não de memória.

“ POST /json/2/mrp.workorder/write Authorization: bearer <api-key> {"ids": [4711], "vals": {"date_start": "2026-11-03 06:00:00", "date_finished": "2026-11-03 09:30:00", "workcenter_id": 7}} “

O JSON-2 recebe cada argumento do método pelo nome, além de ids e context, pelo que write(vals) passa a usar a chave vals. Nas versões 16.0 a 18.0, a mesma chamada é executada como execute_kw(db, uid, key, 'mrp.workorder', 'write', [[4711], vals]) por XML-RPC ou JSON-RPC e, na versão 16.0, as chaves são date_planned_start e date_planned_finished. As datas e horas são enviadas em UTC. Algumas regras garantem uma gravação correta:

• Envie ambas as datas na mesma chamada.
• Inclua workcenter_id apenas quando o motor tiver escolhido uma máquina alternativa.
• Escreva apenas nos campos de programação, nunca nas quantidades ou nas listas de materiais.

A escrita das datas desloca a reserva do centro de trabalho no próprio Odoo. Assim, as vistas de planeamento do Odoo apresentam o plano do SkyPlanner.

Do chão de fábrica de volta ao Odoo. Os operadores registam o trabalho no SkyPlanner Mobile Confirmations. Para cada confirmação, a integração chama create em mrp.workcenter.productivity (JSON-2: POST /json/2/mrp.workcenter.productivity/create com vals_list). Preenche workorder_id, workcenter_id, date_start, date_end e um loss_id do tipo Productive, e o tempo de mão de obra e os respetivos custos são registados no Odoo.

Quando uma operação fica concluída, a integração define a quantidade produzida e chama button_finish na ordem de fabrico. A última ordem de fabrico deixa a ordem de produção pronta para button_mark_done. Cada confirmação é registada uma única vez e o identificador do respetivo registo no Odoo fica guardado com o registo de tempos do SkyPlanner. Assim, a repetição de um webhook nunca cria um segundo Time Log.

Nas fábricas que utilizam a aplicação Enterprise Shop Floor, o fluxo é inverso: o SkyPlanner lê o estado da ordem de fabrico e qty_produced, e o Autopilot refaz automaticamente a programação quando a produção muda.

Responsabilidade pelos dados. Documente as regras antes da entrada em produção:

Os responsáveis pelo planeamento deixam de usar os botões Plan e Unplan do Odoo nas ordens de produção programadas pelo SkyPlanner. Caso contrário, o Odoo faz as suas próprias reservas, sobrepondo-as às datas do SkyPlanner.

• Campos de data com novos nomes. Até à versão 16.0, date_planned_start e date_planned_finished continham as datas previstas e date_start/date_finished as datas reais. A partir da versão 17.0, date_start e date_finished são as datas previstas. Um mapeamento copiado de um projeto na versão 16.0 lê silenciosamente as datas reais como previstas nas versões 17+.
• As datas das ordens de fabrico são reservas de capacidade. Na versão 19.0, date_start e date_finished em mrp.workorder são calculados a partir de um registo de resource.calendar.leaves (leave_id) no calendário do centro de trabalho. Gravar as datas na ordem de fabrico atualiza essa reserva. Nunca grave diretamente na tabela de ausências.
• As ordens de fabrico já iniciadas impedem a ação Unplan. O Odoo recusa anular o planeamento de uma ordem de produção quando “Some work orders have already started” (algumas ordens de fabrico já foram iniciadas). Ao gravar os dados no Odoo, ignore as ordens de fabrico em progress ou done e desloque apenas as que ainda não começaram.
• As durações variam. As operações em modo Computed obtêm a duração a partir das últimas ordens de fabrico (10 por predefinição), ajustada pelo parâmetro Time Efficiency. Para o período experimental, mude para Fixed ou aceite que os dados de entrada variem. As operações pertencem a cada lista de materiais, sem dados mestre partilhados de gamas operatórias. Por isso, cada lista de materiais precisa da sua própria revisão.
• Calendários com erros. Cada centro de trabalho precisa de um calendário de horários de trabalho. O sistema de planeamento do próprio Odoo procura disponibilidade até 700 dias no futuro e depois para com a mensagem “Impossible to plan the workorder” (impossível programar a ordem de fabrico). Corrija os calendários antes do primeiro carregamento.
• Unidades de medida. mrp.bom.line tem o seu próprio product_uom_id, que pode diferir da unidade de stock do produto. Faça a conversão antes de verificar a disponibilidade dos materiais.

É o envio dos dados atualizados para o Odoo que torna a integração útil no dia a dia. Quando esse envio está a funcionar:

• As ordens de fabrico do Odoo passam a ter datas realistas. O motor Arcturus AI sequencia todas as ordens de produção em aberto em segundos. As datas e os centros de trabalho que escolhe são gravados em mrp.workorder, onde ficam visíveis nas vistas de planeamento do Odoo.
• Deixa de ser preciso replanear à mão. O Autopilot reprograma automaticamente quando a produção muda, e o webhook envia as novas datas para o Odoo.
• O chão de fábrica fecha o ciclo. Os operadores registam o trabalho no telemóvel ou tablet com Mobile Confirmations, Production Timer e Quick Log Mode. Os Time Logs são enviados para o Odoo para atualizar as existências e calcular os custos. A programação e a execução funcionam numa única ferramenta, tanto em Community como em Enterprise.
• A programação respeita restrições que o Odoo não contempla. Uma matriz de tempos de preparação define as mudanças entre cada par de produtos em função da sequência. As ferramentas são recursos de capacidade finita partilhados entre máquinas, e uma tarefa pode ocupar vários operadores em simultâneo. O motor recorre a máquinas ou pessoas alternativas quando o recurso principal não está disponível. As datas gravadas em mrp.workorder respeitam todas estas restrições.
• O plano segue a chegada dos materiais. As existências disponíveis e as encomendas a fornecedores em aberto no Odoo alimentam a programação em função dos materiais. Os componentes encomendados são considerados disponíveis na data de entrega da encomenda, e as existências são atualizadas quando esta é marcada como Delivered. Para cada tarefa, verifica-se o que existe em armazém e o que está a caminho.

Pode avaliar a programação antes de qualquer trabalho de integração. Inicie o período experimental gratuito de 30 dias com exportações CSV e veja as suas próprias ordens de fabrico do Odoo no Gantt, com até 20 postos de trabalho e sem cartão de crédito. Os preços começam nos 199 € por mês, com 5 postos de trabalho incluídos, faturação mensal e cancelamento a qualquer momento. O orçamento da integração é apresentado antecipadamente, juntamente com o seu plano, de acordo com o seu processo e as suas necessidades. Assim, conhece o custo total antes de começar. Consulte as funcionalidades e os clientes ou agende uma demonstração.