Estructura de datos del Skyplanner #
Antes de sumergirnos en los registros temporales, tenemos que hablar un poco de la estructura de datos de Skyplanner y de cómo funcionan las cosas bajo el capó. Todo esto entrará en juego más adelante.
Si has integrado tus datos de pedidos/órdenes de trabajo/trabajos en Skyplanner, lo más probable es que hayas utilizado al menos estos API-endpoints:
- phaser-pedidos
- phaser-orden-filas
- phaser-jobs
Efectivamente, los datos insertados en estos puntos finales se representan en la interfaz de usuario de Skyplanner de la siguiente manera:
Después de insertar tus pedidos en Skyplanner, querrás exportarlos (esto puede hacerse a través de la interfaz de usuario o del punto final /phaser-orders/export-endpoint) al módulo de Programación de la Producción:
Al exportar pedidos, Skyplanner copia efectivamente los datos del pedido de una tabla de la base de datos a otra. Así que si cambias algo, por ejemplo, a través del punto final /phaser-orders, tienes que exportar los datos de nuevo para actualizarlos en la Programación de la producción. Esto también significa que, para acceder a los pedidos que ves en la ventana de Programación de la producción, ¡tienes que utilizar diferentes puntos finales de la API!
Los puntos finales “modificados” son así:
- /pedidos-faser → /pedidos
- /faser-orden-filas → /orden-filas
- /faser-empleos → /empleos
Es importante que lo sepas, porque cuando utilices el punto final /timelogs para registrar tus eventos de producción, etc. , ¡tienes que utilizar las entidades relacionadas que se encuentran en los puntos finales de Programación de la Producción!
Por ejemplo, necesitas el production_planning_job_id (para reiterar: production_planning_jobs son las entidades a las que se accede desde el -endpoint /jobs) para POSTAR un nuevo registro de tiempo:
Puedes encontrar el production_planning_job_id que necesitas en el -endpoint /phaser-jobs:
O desde el punto final /job:
Crear registros cronológicos utilizando la REST-API #
Hacer registros de tiempo en Skyplanner a través de la API utiliza las mismas reglas y sistemas que en la IU. Así que puede ser beneficioso que te familiarices con el funcionamiento del sistema en la IU antes de intentar utilizarlo a través de la API.
Conceptos básicos del registro cronológico #
Skyplanner tiene cuatro tipos de eventos de registro de tiempo:
- inicio_de_turno
- en pausa
- continúa
- shift_end
El evento Shift_begin se envía cuando el trabajo se inicia por primera vez. ¡Nunca envíes más de un evento shift_begin por cada trabajo!
El evento Pausado pausa el trabajo.
El evento continuado reanuda un trabajo pausado.
Shift_end completa el trabajo. ¡Nunca envíes más de un evento shift_end por cada trabajo!
Datos necesarios para los registros cronológicos:
- persona_id
- Se puede encontrar desde el punto final /people
- ¡No es lo mismo que user_id!
- id_puesto_trabajo_planificado
- El puesto de trabajo en el que se realiza el trabajo
- Se puede encontrar desde el /workstations-endpoint
- fecha_hora
- El momento en que se realiza el evento
- Formato: 2024-01-01 10:30:11
Para especificar qué registro de tiempo de Skyplanner está vinculado al registro de tiempo de cualquier sistema externo que estés utilizando, puedes utilizar el campo external_id . Entonces puedes, por ejemplo, hacer peticiones GET utilizando este id para encontrar un registro de tiempo específico de Skyplanner.
Empezar a trabajar #
Puedes iniciar trabajos enviando una solicitud POST como ésta a la API:
Al configurar los datos POST para los registros de tiempo, establece workshift_id como 0 y timelog_finalized como true
Pausar un trabajo #
Pausa los trabajos enviando una petición POST como ésta:
En los registros de tiempo de tipo pausa puedes establecer la cantidad y la cantidad_defectuosa. Ten en cuenta también el tipo de registro de tiempo y la fecha/hora.
Continuar un trabajo #
Así es como se continúa un registro de tiempo en pausa:
Ten en cuenta que si intentas continuar un trabajo que ha finalizado por un evento shift_end, obtendrás un error.
Terminar un trabajo #
Así es como se termina un trabajo mediante un registro de tiempo shift_end:
En shift_end-events puedes dar los valores amount y faulty_amount igual que en paused-events. Ten en cuenta que si intentas hacer un evento shift_end a un trabajo que no se está ejecutando, obtendrás un error.
Actualizar registros cronológicos #
Puedes actualizar los datos del registro de tiempo enviando solicitudes PUT al punto final /timelogs, de esta forma:
Ten en cuenta que debes tener configurados los datos de beginTimelog y endTimelog para poder realizar una actualización. Los registros de tiempo en Skyplanner se almacenan así: cada registro de tiempo “completo” (que tiene un inicio y un final (por ejemplo, inicio_turno/continuado y pausado/final_turno) tiene una entidad separada para el inicio y el final.
Se emparejan por el valor begin_id que se encuentra en el endlog. En el ejemplo anterior, beginTimelog tiene el valor id 1 y, por tanto, endTimelog tiene el valor begin_id 1.
También debes dar los valores person_id y endTimelog cada vez que hagas una petición de actualización, aunque no los estés cambiando.
Formas alternativas de hacer registros cronológicos #
Aquí tienes algunas formas alternativas de acceder a tus trabajos utilizando la API.
Tronco lleno #
Si quieres enviar los registros de tiempo inicial y final en una sola petición, puedes utilizar el -punto /timelogs/log-full, así
Observa cómo se envían aquí las cantidades: el primer valor “cantidad” indica la cantidad defectuosa y el segundo la cantidad. Esta petición crea las entidades beginlog y endlog en una sola petición.
Registro rápido #
“Quicklogging” a un trabajo lo completa en una sola petición, establece la cantidad completada de productos para que coincida con el valor establecido en el elemento del pedido. El Quicklogging se realiza utilizando el -endpoint /timelogs/quick-log:
Ten en cuenta que aquí sólo necesitas dar el production_planning_job_id, planned_workstation_id y person_id. Los valores de tiempo e importe se rellenan automáticamente. Ten en cuenta también que los trabajos quicklogged siempre se completan con el evento shift_end-event, ¡así que no es posible ningún otro registro después del quicklog!