Guía de integración de ProShop ERP para programar la producción con SkyPlanner APS

ProShop ofrece dos vías para conectar una herramienta externa de programación de la producción, descritas en ProShop API Developer Documents:

1. ProShop GraphQL API. «ProShop provides a GraphQL API, available via HTTP(S).» (ProShop ofrece una API GraphQL accesible mediante HTTP(S)). Hay un único endpoint: cada llamada es una petición HTTP POST a <proshop root>/api/graphql con query, variables y operationName en un cuerpo JSON. Cada módulo tiene una consulta en singular para obtener un registro y otra en plural para obtener listas. Las listas se paginan con pageSize (20 por defecto) y pageStart, devuelven records y totalRecords, y admiten los argumentos filter y query, que reproducen las opciones de Advanced Search de cada módulo. El esquema admite introspección. (Introducción a la API de ProShop)
2. Recently Updated Records API. «A simple REST interface allows external integrations to request information between arbitrary points in time.» (Una interfaz REST sencilla permite a las integraciones externas solicitar información entre dos momentos cualesquiera). Llama a <proshop root>/recentlyupdatedrecords con start (ISO 8601) y, opcionalmente, end y filterby; por ejemplo, workorders,workcells,purchaseorders,timetracking,deletions. El equipo de ProShop debe habilitar primero el índice. (Recently Updated Records API)

Las escrituras se realizan mediante mutaciones de GraphQL. El ejemplo documentado es Time Tracking Login, y el acceso de escritura se concede por módulo mediante ámbitos de autorización.

La documentación para desarrolladores de ProShop no describe webhooks de salida ni suscripciones GraphQL. Los cambios en ProShop se consultan periódicamente, y Recently Updated Records API permite hacerlo con un coste reducido: se solicitan todos los registros creados, modificados o eliminados desde la última ejecución, filtrados por los tipos que necesita la programación. Después se obtienen por número las órdenes de fabricación modificadas mediante GraphQL, un método que, según ProShop, es más rápido que consultar por lastModifiedTime.

Lo habitual es consultar cada cinco minutos las órdenes de fabricación y los registros de tiempo, y cada hora las piezas y los pedidos de compra. SkyPlanner envía webhooks cuando cambia el estado o la programación, de modo que la escritura de retorno se activa por eventos.

1. Carga inicial de datos maestros. Recorre por páginas Parts, Work Cells, Users, Tools y Fixtures mediante consultas en plural de GraphQL. Establece un valor alto de pageSize para la primera carga e itera según totalRecords. Decide cómo se asignan las células de trabajo: las de máquinas se convierten en estaciones de trabajo y las de personas, en personal. Así, una misma operación puede reservar a la vez una máquina y su operario.

2. Sincronización de órdenes de fabricación. Lee las órdenes de fabricación activas con sus operaciones, tiempos objetivo y registros de BOM, además de los pedidos de compra abiertos. SkyPlanner considera que el material pedido estará disponible en la fecha de entrega del pedido de compra y actualiza las existencias cuando este se marca como Delivered. Los cambios se detectan mediante Recently Updated Records con filterby=workorders,purchaseorders,deletions.

3. Escritura de la programación en ProShop. Cuando el motor sitúa o mueve una tarea, un webhook de SkyPlanner activa una mutación GraphQL que establece las fechas planificadas de la orden de fabricación mediante una Authorization con workorders:w. A partir de ese momento, la previsión de cumplimiento de plazos de ProShop y las fechas de necesidad de compras se basan en las fechas de SkyPlanner.

4. Confirmaciones en planta. Los operarios registran su trabajo con SkyPlanner Mobile Confirmations o Production Timer, y los registros de tiempo mantienen actualizada la programación. Tú decides si los tiempos reales se envían a ProShop Time Tracking asociados a la operación de la orden de fabricación. Si no, los operarios siguen registrando sus tiempos en ProShop como hasta ahora, y SkyPlanner los lee mediante timetracking.

5. Responsabilidad sobre los datos y reglas para resolver conflictos. Déjalas por escrito antes de la entrada en producción:

Elige un único sistema que escriba las fechas de las órdenes de fabricación. Una vez que SkyPlanner programa una célula de trabajo, los planificadores dejan de reordenar su lista en ProShop. Así, las dos programaciones nunca entran en conflicto.

• Los tiempos objetivo lo determinan todo. ProShop calcula la duración a partir de los tiempos estimados de preparación y de ciclo. Obtén los tiempos objetivo actuales, no la estimación original, y separa el tiempo de preparación del de ejecución para que la matriz de tiempos de preparación pueda sustituir el valor único de preparación.
• Células de trabajo que representan a personas. Una célula de trabajo puede ser una persona. Asígnalas al personal de SkyPlanner, no a las máquinas; de lo contrario, cada operario se tratará como una máquina en paralelo.
• Time Tracking necesita un usuario. Desde abril de 2026, la mutación Time Tracking Login «requires user context» (requiere un contexto de usuario) y no está autorizada con Client Credentials. Envía los tiempos de los operarios mediante OAuth 2.0 Authorization Flow, o sigue registrándolos en ProShop y léelos desde allí.
• Active el índice de cambios. Recently Updated Records solo funciona una vez que el equipo de ProShop lo habilita. Solicítelo en la primera semana.
• Registros sujetos a ITAR. ProShop filtra los registros sujetos a restricciones ITAR para cada conexión, y una opción de Developer System Config determina si se devuelven como valores nulos o se excluyen. Acuerde a qué órdenes de fabricación tendrá acceso la integración y contemple los valores nulos en cada lectura.
• Operaciones subcontratadas. Las operaciones realizadas por proveedores representan tiempo transcurrido, no capacidad propia. Modélelas como etapas que solo consumen tiempo.