Structure des données de Skyplanner #
Avant de nous plonger dans les timelogs, nous devons parler un peu de la structure des données dans Skyplanner et de la façon dont les choses fonctionnent sous le capot. Tout cela entrera en ligne de compte plus tard.
Si vous avez intégré vos données de commande, d’ordre de travail ou d’emploi dans Skyplanner, vous avez probablement utilisé au moins ces points API :
- commandes de phasers
- phaser-order-rows
- phaser-jobs
En effet, les données insérées dans ces points de terminaison sont représentées dans l’interface utilisateur de Skyplanner de la manière suivante :
Après avoir inséré vos commandes dans Skyplanner, vous voudrez les exporter (vous pouvez le faire via l’interface utilisateur ou le point de terminaison /phaser-orders/export) dans le module Production Scheduling :
Lors de l’exportation des commandes, Skyplanner copie effectivement les données de la commande d’une table de base de données à une autre. Par conséquent, si vous modifiez quelque chose, par exemple via le point de terminaison /phaser-orders, vous devez exporter à nouveau les données pour les mettre à jour dans la planification de la production. Cela signifie également que pour accéder aux commandes que vous voyez dans la fenêtre de planification de la production, vous devez utiliser différents points de terminaison API !
Les points de terminaison “modifiés” se présentent comme suit :
- /phaser-orders → /orders
- /phaser-order-rows → /order-rows
- /phaser-jobs → /jobs
Il est important de le savoir, car lorsque vous utilisez le point de terminaison /timelogs pour enregistrer vos événements de production, etc., vous devez utiliser les entités connexes trouvées dans les points de terminaison Production Scheduling !
Par exemple, vous avez besoin du production_planning_job_id (pour rappel : les production_planning_jobs sont les entités auxquelles on accède à partir du point de terminaison /jobs) pour POST un nouveau timelog :
Vous pouvez trouver le production_planning_job_id dont vous avez besoin à partir du point de terminaison /phaser-jobs :
Ou à partir du point de terminaison /job :
Création de timelogs à l’aide de l’API REST #
La création d’enregistrements temporels pour Skyplanner via l’API utilise les mêmes règles et systèmes que ceux de l’interface utilisateur. Il peut donc être utile de vous familiariser avec le fonctionnement du système dans l’interface utilisateur avant d’essayer de l’utiliser via l’API.
Principes de base du journal chronologique #
Skyplanner propose quatre types d’événements :
- début_mise_en_place
- en pause
- continue
- shift_end
L’événement Shift_begin est envoyé lorsque le travail est lancé pour la première fois. N’envoyez jamais plus d’un événement shift_begin pour chaque travail !
L’événement Paused met le travail en pause.
Continued-event reprend un travail en pause.
Shift_end termine le travail. N’envoyez jamais plus d’un événement shift_end pour chaque travail !
Données requises pour les calendriers :
- identifiant_personne
- Vous pouvez le trouver à partir du point de terminaison /people
- Pas la même chose que user_id !
- planned_workstation_id
- Le poste de travail où le travail est effectué
- Peut être trouvé à partir du point de terminaison /workstations-endpoint
- date_heure
- Le moment où l’événement est réalisé
- Format : 2024-01-01 10:30:11
Afin de spécifier quel timelog de Skyplanner est lié au timelog du système externe que vous utilisez, vous pouvez utiliser le champ external_id . Vous pouvez alors, par exemple, effectuer des requêtes GET en utilisant cet identifiant afin de trouver un historique spécifique de Skyplanner.
Démarrer un emploi #
Vous pouvez lancer des tâches en envoyant une demande POST comme celle-ci à l’API :
Lorsque vous définissez les données POST pour les timelogs, définissez workshift_id comme 0 et timelog_finalized comme true.
Mise en pause d’un travail #
Mettez les travaux en pause en envoyant une requête POST comme suit :
Dans les journaux temporels de type pause, vous pouvez définir le montant et faulty_amount. Notez également le type de journal et la date_heure.
Poursuivre un emploi #
Voici comment poursuivre un journal chronologique en pause :
Notez que si vous essayez de poursuivre un travail qui a été terminé par un événement shift_end, vous obtiendrez une erreur.
Fin d’un emploi #
Voici comment vous terminez un travail par un journal de bord shift_end :
Dans shift_end-events, vous pouvez indiquer les valeurs amount et faulty_amount comme dans paused-events. Notez que si vous essayez d’effectuer un shift_end-event sur un travail qui n’est pas en cours d’exécution, vous obtiendrez une erreur.
Mise à jour des calendriers #
Vous pouvez mettre à jour les données du timelog en envoyant des requêtes PUT au point de terminaison /timelogs, comme ceci :
Notez que vous devez disposer des données beginTimelog et endTimelog pour effectuer une mise à jour. Dans Skyplanner, les calendriers sont stockés de la manière suivante : chaque calendrier “complet” (qui comporte à la fois un début et une fin (par exemple, shift_begin/continued & paused/shift_end)) comporte une entité distincte pour le début et la fin.
Ils sont associés à la valeur begin_id trouvée dans endlog. Dans l’exemple ci-dessus, le beginTimelog a pour valeur id 1 et le endTimelog a donc pour valeur begin_id 1.
Vous devez également indiquer les valeurs person_id et endTimelog à chaque fois que vous effectuez une demande de mise à jour, même si vous ne les modifiez pas.
D’autres façons de réaliser des timelogs #
Voici d’autres façons de vous connecter à vos travaux à l’aide de l’API.
Logfull #
Si vous souhaitez envoyer les timelogs de début et de fin en une seule requête, vous pouvez utiliser le point de terminaison /timelogs/log-full, comme ceci :
Notez comment les montants sont envoyés ici : la première valeur “amount” indique le montant défectueux et la seconde le montant. Cette requête crée les entités beginlog et endlog en une seule requête.
Fiche d’information #
“L’enregistrement rapide d’une tâche permet de la terminer en une seule demande et de faire correspondre la quantité de produits achevés à la valeur définie dans l’élément de la commande. Le Quicklogging se fait en utilisant le point de terminaison /timelogs/quick-log:
Notez que vous ne devez indiquer ici que l’identifiant du travail de planification de la production, l’identifiant du poste de travail planifié et l’identifiant de la personne. Les valeurs de temps et de montant sont automatiquement remplies. Notez également que les travaux à enregistrement rapide sont toujours terminés avec l’événement shift_end, de sorte qu’aucun enregistrement supplémentaire n’est possible après l’enregistrement rapide !