Guía de integración de Fulcrum para la programación de la producción con SkyPlanner APS

Fulcrum es un único producto en la nube con arquitectura multiinquilino, por lo que todos los clientes utilizan la misma API. El portal para desarrolladores la describe como una API pública para «REST API calls directly into your Fulcrum site.» (llamadas REST API directamente a tu sitio de Fulcrum).

• Especificación. OpenAPI «Fulcrum PublicAPI» v1, disponible para descargar en https://api.fulcrumpro.com/swagger/v1/swagger.json. Fulcrum recomienda generar un cliente tipado a partir de ella. La página History recoge todos los cambios con sus fechas.
• Servidores. https://api.fulcrumpro.com para los sitios estándar. Los sitios ITAR utilizan api.fulcrumpro.us, y los tokens ITAR reciben una respuesta 401 en el servidor .com.
• Convenciones. Los listados se obtienen mediante POST .../list, con un cuerpo de filtros, paginación mediante Skip y Take y ordenación mediante Sort.Field / Sort.Dir. Muchos objetos admiten PUT, y las tareas también admiten JSON Patch.

Endpoints utilizados en una integración para la programación de la producción:

La propia página de integraciones de Fulcrum es clara sobre el trabajo necesario: «Every system is a little bit different and requires some configuration.» (Cada sistema tiene sus particularidades y requiere cierta configuración). El equipo de SkyPlanner se encarga precisamente de esa configuración durante la puesta en marcha.

Fulcrum admite webhooks que configura un administrador. Desde septiembre de 2026, los webhooks que fallan se pausan y se vuelven a probar a diario, en lugar de reintentarse indefinidamente. El historial de la API recoge eventos como PurchaseOrderUpdated e ItemUpdated.

La integración lee los datos de Fulcrum de la siguiente manera:

• Las tareas abiertas se consultan cada pocos minutos, filtradas por scheduled e inProgress, con hasIncompleteOperations: true. Este es el filtro que propone el propio Fulcrum para obtener los mismos resultados que en su página de programación.
• Los pedidos de compra y las existencias se consultan antes de cada ejecución de la programación o al recibir un webhook PurchaseOrderUpdated, si está configurado.
• Los artículos, las rutas de fabricación, los equipos y los turnos se consultan cuando hay cambios o cada noche.

En sentido contrario, los webhooks de SkyPlanner envían los cambios de programación en cuanto se producen, por lo que la escritura de datos en Fulcrum se activa por eventos.

1. Carga inicial de datos maestros. Importa los artículos, materiales, rutas de fabricación, centros de trabajo y equipos y, después, los turnos de los departamentos y los tiempos de parada. Cada centro de trabajo de Fulcrum se convierte en un grupo de estaciones de trabajo de SkyPlanner formado por sus equipos. Los equipos seleccionados para cada operación de la ruta de fabricación pasan a ser las estaciones de trabajo permitidas para esa operación. Los equipos con Unlimited Capacity, como hornos y cabinas de pintura, se representan mediante tareas por lotes.

2. Sincronización de órdenes. Lee las tareas abiertas con sus artículos a fabricar y operaciones, junto con los pedidos de compra abiertos y las existencias. 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. En cada reprogramación se comprueban las existencias y las compras pendientes de recibir.

3. Escritura de la programación en Fulcrum. Fulcrum calcula por sí mismo scheduledStartUtc, scheduledEndUtc y scheduledEquipmentId y los devuelve como valores de solo lectura. La actualización de operaciones admite customFields. SkyPlanner escribe el inicio previsto, el fin previsto y la estación de trabajo en campos personalizados de cada operación de la tarea, y el fin previsto en un campo personalizado de la tarea. Los equipos de ventas y compras pueden ver las fechas de SkyPlanner en la tarea de Fulcrum.

4. Confirmaciones en planta. Los operarios registran su trabajo en SkyPlanner con Mobile Confirmations, Production Timer o Quick Log Mode. SkyPlanner envía los tiempos a Fulcrum a través de /api/job-tracking-timers/start y /stop, o como un bloque ya completado mediante /api/timers. Las cantidades se envían mediante add-quantity-completed, y el recuento final, incluidos los rechazos, mediante complete. El cálculo de costes de las tareas en Fulcrum se mantiene actualizado.

5. Reglas de responsabilidad y resolución de conflictos. El programador de Fulcrum «dictates the order of operations in Job Tracking.» (determina el orden de las operaciones en Job Tracking). Por tanto, elige un único canal para asignar el trabajo de cada operación: la cola de trabajo de los operarios en SkyPlanner o Fulcrum Job Tracking. Deja las reglas por escrito antes de la puesta en marcha:

• La mano de obra se refleja en la capacidad por turno. En Fulcrum, Max Equipment por turno «is usually determined by how many people you have working in a certain area at that time.» (suele depender de cuántas personas trabajan en una zona en ese momento). Cada operario y sus turnos se configuran en SkyPlanner. Los nombres se obtienen de los usuarios de /api/users.
• El trabajo se programa por equipo. Los centros de trabajo de Fulcrum son grupos de equipos intercambiables. Mantén correctamente seleccionados los equipos de la ruta de fabricación, ya que serán las alternativas entre las que elegirá el motor.
• Las órdenes de fabricación agrupan tareas. Una orden de fabricación agrupa operaciones de varias tareas, por ejemplo, un anidado de piezas. Al iniciar un temporizador en una operación agrupada, se inicia en su lugar el temporizador de la orden de fabricación, que abarca todas las operaciones de las tareas del grupo.
• Límites de los temporizadores. Los intervalos de tiempo registrados a posteriori mediante /api/timers «may not be in the future, older than 30 days, or longer than 7 days.» (no pueden estar en el futuro ni superar los límites de antigüedad o duración indicados). Envía los tiempos a medida que los operarios los registren.
• Los formatos de hora varían. Los turnos usan la hora local en formato HHmm; las paradas y las fechas programadas están en UTC, y las estimaciones de las operaciones se reciben en segundos.
• Las actualizaciones de equipos sustituyen el registro completo. Una solicitud PUT de un equipo borra cualquier campo que se omita. SkyPlanner lee los datos de los equipos y nunca escribe en ellos.
• Instancias ITAR. Utiliza el host .us y un token ITAR.