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

O Fulcrum é um único produto em nuvem com arquitetura multitenant, por isso todos os clientes usam a mesma API. O portal de desenvolvedores a descreve como uma API pública para “REST API calls directly into your Fulcrum site.” (chamadas à REST API diretamente no seu ambiente Fulcrum).

• Especificação. OpenAPI “Fulcrum PublicAPI” v1, disponível para download em https://api.fulcrumpro.com/swagger/v1/swagger.json. O Fulcrum sugere gerar um cliente tipado a partir dela. A página History lista todas as alterações com suas datas.
• Hosts. https://api.fulcrumpro.com para ambientes padrão. Ambientes ITAR usam api.fulcrumpro.us, e tokens ITAR recebem uma resposta 401 no host .com.
• Padrão de chamadas. As consultas de listas usam POST .../list, com filtros no corpo da requisição, paginação por Skip e Take e ordenação por Sort.Field / Sort.Dir. Muitos objetos aceitam PUT, e as ordens também aceitam JSON Patch.

Endpoints usados em uma integração para programação da produção:

A própria página de integrações do Fulcrum é direta sobre o trabalho necessário: “Every system is a little bit different and requires some configuration.” (Cada sistema tem suas particularidades e exige alguns ajustes de configuração.) É exatamente dessa configuração que a equipe SkyPlanner cuida durante a implantação.

O Fulcrum oferece suporte a webhooks, configurados por um administrador. Desde setembro de 2026, os webhooks com falha são pausados e testados novamente todos os dias, em vez de repetir as tentativas indefinidamente. A página History da API lista eventos como PurchaseOrderUpdated e ItemUpdated.

A integração consulta os dados do Fulcrum da seguinte forma:

• As ordens em aberto são consultadas a cada poucos minutos, com os filtros scheduled e inProgress e hasIncompleteOperations: true. Esse é o filtro indicado pelo próprio Fulcrum para obter os mesmos resultados da sua página de programação.
• Os pedidos de compra e o estoque são consultados antes de cada execução da programação ou ao receber um webhook PurchaseOrderUpdated, quando configurado.
• Os itens, roteiros de produção, equipamentos e turnos são consultados quando há alterações ou todas as noites.

No sentido inverso, os próprios webhooks do SkyPlanner enviam as alterações da programação assim que elas ocorrem. Portanto, a gravação de dados de volta no Fulcrum é orientada a eventos.

1. Carga inicial de dados mestres. Importe itens, materiais, roteiros de produção, centros de trabalho e equipamentos; depois, os turnos dos departamentos e as paradas. Cada centro de trabalho do Fulcrum se torna um grupo de centros de trabalho no SkyPlanner, composto pelos seus equipamentos. Os equipamentos selecionados em cada operação do roteiro passam a ser os centros de trabalho permitidos para ela. Equipamentos com Unlimited Capacity, como fornos e cabines de pintura, são mapeados como operações em lote.

2. Sincronização de ordens. Consulte as ordens em aberto com seus itens a fabricar e operações, além dos pedidos de compra em aberto e do estoque. O SkyPlanner considera o material comprado como disponível na data de entrega do pedido de compra e atualiza o estoque quando o pedido é marcado como Delivered. A cada reprogramação, o sistema verifica o estoque e as compras a receber.

3. Gravação da programação no Fulcrum. O próprio Fulcrum calcula scheduledStartUtc, scheduledEndUtc e scheduledEquipmentId e os retorna como campos somente leitura. A atualização da operação aceita customFields. O SkyPlanner grava o início planejado, o término planejado e o centro de trabalho em campos personalizados de cada operação da ordem, além de gravar o término planejado em um campo personalizado da ordem. As equipes de vendas e compras veem as datas do SkyPlanner na ordem dentro do Fulcrum.

4. Apontamentos no chão de fábrica. Os operadores registram o trabalho no SkyPlanner com Mobile Confirmations, Production Timer ou Quick Log Mode. O SkyPlanner envia os tempos ao Fulcrum por /api/job-tracking-timers/start e /stop, ou como um bloco concluído por /api/timers. As quantidades são enviadas por add-quantity-completed, e a contagem final, incluindo o refugo, por complete. O custeio das ordens no Fulcrum permanece atualizado.

5. Regras de responsabilidade e resolução de conflitos. O sistema de programação do Fulcrum “dictates the order of operations in Job Tracking.” (determina a sequência das operações no Job Tracking). Por isso, escolha um único canal de liberação por operação: a fila do operador no SkyPlanner ou o Fulcrum Job Tracking. Documente as regras antes da entrada em produção:

• A mão de obra é representada pelas quantidades por turno. No Fulcrum, o Max Equipment por turno “is usually determined by how many people you have working in a certain area at that time.” (geralmente é determinado pelo número de pessoas trabalhando em uma área naquele horário). Os operadores identificados por nome e seus turnos são cadastrados no SkyPlanner. Os registros de usuários em /api/users fornecem os nomes.
• A programação é feita por equipamento. Os centros de trabalho do Fulcrum são grupos de equipamentos intercambiáveis. Mantenha correta a seleção de equipamentos no roteiro de produção, pois ela define as alternativas entre as quais o mecanismo de programação escolherá.
• Work orders agrupam jobs. Uma work order agrupa operações de vários jobs, como em um plano de corte. Ao iniciar um temporizador em uma operação agrupada, o temporizador da work order é iniciado em seu lugar e abrange todas as operações dos jobs do grupo.
• Limites dos temporizadores. Os intervalos registrados retroativamente em /api/timers “may not be in the future, older than 30 days, or longer than 7 days.” (não podem estar no futuro nem ultrapassar os limites indicados de retroatividade e duração). Envie os tempos à medida que os operadores os registrarem.
• Os formatos de horário variam. Os turnos usam valores locais no formato HHmm, as paradas e as datas programadas usam UTC, e as estimativas das operações são fornecidas em segundos.
• As atualizações de equipamentos substituem o registro inteiro. Uma requisição PUT de equipamento limpa todos os campos omitidos. O SkyPlanner apenas lê os dados dos equipamentos e nunca grava neles.
• Instâncias ITAR. Use o host .us e um token ITAR.