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

O ProShop oferece duas opções para um sistema externo de programação, descritas na documentação da API do ProShop para desenvolvedores:

1. ProShop GraphQL API. “ProShop provides a GraphQL API, available via HTTP(S).” (O ProShop oferece uma GraphQL API acessível via HTTP(S).) Há um único endpoint: toda chamada é um HTTP POST para <proshop root>/api/graphql, com query, variables e operationName no corpo JSON. Cada módulo tem uma consulta no singular para um registro e outra no plural para listas. As listas são paginadas com pageSize (padrão 20) e pageStart, retornam records e totalRecords e aceitam os argumentos filter e query, que correspondem à Advanced Search de cada módulo. O esquema permite introspecção. (Introdução à API do ProShop)
2. Recently Updated Records API. “A simple REST interface allows external integrations to request information between arbitrary points in time.” (Uma interface REST simples permite que integrações externas solicitem informações de qualquer intervalo de tempo.) Chame <proshop root>/recentlyupdatedrecords com start (ISO 8601) e os parâmetros opcionais end e filterby, por exemplo, workorders,workcells,purchaseorders,timetracking,deletions. A equipe do ProShop precisa habilitar o índice antes. (Recently Updated Records API)

As gravações são feitas por mutations do GraphQL. Time Tracking Login é o exemplo documentado, e o acesso de gravação é concedido por módulo, por meio de escopos.

A documentação do ProShop para desenvolvedores não descreve webhooks de saída nem assinaturas GraphQL. Os dados do ProShop são consultados periodicamente, e a Recently Updated Records API reduz o custo dessas consultas: solicite tudo o que foi criado, alterado ou excluído desde a última execução, filtrando pelos tipos de registro necessários para a programação. Em seguida, busque as ordens de produção alteradas pelo número via GraphQL. Segundo o ProShop, isso é mais rápido do que consultar por lastModifiedTime.

Uma opção comum é consultar ordens de produção e apontamentos de tempo a cada cinco minutos, e peças e pedidos de compra a cada hora. O SkyPlanner envia webhooks quando o estado ou a programação muda, de modo que a gravação de retorno é acionada por eventos.

1. Carga inicial de dados mestres. Percorra as páginas de Parts, Work Cells, Users, Tools e Fixtures com consultas no plural do GraphQL. Use um valor alto de pageSize na primeira carga e repita as consultas com base em totalRecords. Defina o mapeamento das células de trabalho: cadastre as que representam máquinas como centros de trabalho e as que representam pessoas como integrantes do pessoal. Assim, a mesma operação pode reservar uma máquina e seu operador ao mesmo tempo.

2. Sincronização das ordens de produção. Leia as ordens de produção ativas com suas operações, tempos previstos e registros de BOM, além dos pedidos de compra em aberto. O SkyPlanner considera o material encomendado disponível na data de entrega do pedido de compra e atualiza o estoque quando o pedido é marcado como Delivered. A detecção de alterações usa Recently Updated Records com filterby=workorders,purchaseorders,deletions.

3. Gravação da programação no ProShop. Quando o mecanismo aloca ou move uma operação, um webhook do SkyPlanner aciona uma mutation do GraphQL que define as datas planejadas da ordem de produção, usando uma Authorization com workorders:w. A previsão de cumprimento de prazos do ProShop e as datas de necessidade de compras passam, então, a usar as datas do SkyPlanner.

4. Confirmações no chão de fábrica. Os operadores registram o trabalho com SkyPlanner Mobile Confirmations ou Production Timer, e os apontamentos de tempo mantêm a programação atualizada. Você decide se os tempos reais serão enviados de volta ao ProShop Time Tracking, vinculados à operação da ordem de produção. Caso contrário, os operadores continuam apontando os tempos no ProShop como antes, e o SkyPlanner os lê por meio de timetracking.

5. Responsabilidade pelos dados e regras de conflito. Documente essas regras antes da entrada em produção:

Escolha um único sistema para gravar as datas das ordens de produção. Assim que o SkyPlanner passa a programar uma célula de trabalho, os planejadores deixam de reordenar a lista dessa célula no ProShop, para que as duas programações nunca entrem em conflito.

• Os tempos previstos definem tudo. O ProShop calcula a duração com base nos tempos estimados de preparação e ciclo. Obtenha os tempos previstos atuais, não a estimativa original, e separe o tempo de preparação do tempo de execução para que a matriz de tempos de preparação possa substituir o valor único de preparação.
• Células de trabalho que representam pessoas. Uma célula de trabalho pode ser uma pessoa. Mapeie essas células para o pessoal no SkyPlanner, não para máquinas. Caso contrário, cada operador será tratado como uma máquina em paralelo.
• Time Tracking exige um usuário. Desde abril de 2026, a mutation Time Tracking Login “requires user context” (exige contexto de usuário) e não é autorizada com Client Credentials. Envie os apontamentos de tempo dos operadores pelo OAuth 2.0 Authorization Flow ou mantenha os apontamentos no ProShop e faça a leitura deles.
• Ative o índice de alterações. Recently Updated Records só funciona depois que a equipe do ProShop o ativa. Solicite a ativação na primeira semana.
• Registros sujeitos ao ITAR. O ProShop filtra os registros sujeitos às restrições do ITAR por conexão, e uma opção em Developer System Config define se eles retornam como valores nulos ou são omitidos. Defina em conjunto quais ordens de produção a integração poderá acessar e trate os valores nulos em todas as leituras.
• Processamento externo. As operações realizadas por fornecedores representam tempo decorrido, não consumo da sua capacidade. Modele-as como etapas que consideram apenas o tempo.