Skyplanner Datenstruktur #
Bevor wir uns mit den Zeitprotokollen befassen, müssen wir ein wenig über die Datenstruktur in Skyplanner sprechen und darüber, wie die Dinge unter der Haube funktionieren. All dies wird später ins Spiel kommen.
Wenn Sie Ihre Auftrags-/Arbeitsauftrags-/Jobdaten in Skyplanner integriert haben, haben Sie höchstwahrscheinlich mindestens diese API-Endpunkte verwendet:
- phaser-orders
- phaser-Order-rows
- phaser-jobs
Die in diese Endpunkte eingegebenen Daten werden in der Skyplanner-Benutzeroberfläche wie folgt dargestellt:
Nachdem Sie Ihre Aufträge in Skyplanner eingefügt haben, müssen Sie sie in das Modul Produktionsplanung exportieren (dies kann über die Benutzeroberfläche oder den Endpunkt /phaser-orders/export erfolgen):
Beim Exportieren von Aufträgen kopiert Skyplanner die Auftragsdaten von einer Datenbanktabelle in eine andere. Wenn Sie also z.B. über den /phaser-orders -Endpunkt etwas ändern, müssen Sie die Daten erneut exportieren, um sie in Production Scheduling zu aktualisieren. Das bedeutet auch, dass Sie für den Zugriff auf die Aufträge, die Sie im Produktionsplanungsfenster sehen, verschiedene API-Endpunkte verwenden müssen!
Die “geänderten” Endpunkte sehen folgendermaßen aus:
Dies ist wichtig zu wissen, denn wenn Sie den /timelogs -Endpunkt verwenden, um Ihre Produktionsereignisse usw. zu protokollieren , müssen Sie die entsprechenden Entitäten verwenden, die Sie unter Produktionsplanungs -Endpunkten finden!
Sie benötigen zum Beispiel die production_planning_job_id (zur Erinnerung: production_planning_jobs sind die Entitäten, auf die über den /jobs -Endpunkt zugegriffen wird), um ein neues Zeitprotokoll zu POSTen:
Sie finden die production_planning_job_id, die Sie benötigen, entweder über den /phaser-jobs -Endpunkt:
Oder über den /job -Endpunkt:
Erstellen von Zeitprotokollen mit der REST-API #
Bei der Erstellung von Zeitprotokollen für Skyplanner über die API werden dieselben Regeln und Systeme verwendet, die auch in der Benutzeroberfläche enthalten sind. Es könnte also von Vorteil sein, sich mit der Funktionsweise des Systems in der Benutzeroberfläche vertraut zu machen, bevor Sie versuchen, es über die API zu verwenden.
Timelog Grundlagen #
Skyplanner verfügt über vier Timelog-Ereignistypen:
- verschieben_beginnen
- pausiert
- Fortsetzung
- shift_end
Das Shift_begin-Ereignis wird gesendet, wenn der Auftrag zum ersten Mal gestartet wird. Senden Sie niemals mehr als ein shift_begin-Ereignis für jeden Job!
Pausen-Ereignis pausiert den Auftrag.
Fortsetzungs-Ereignis setzt eine angehaltene Arbeit fort.
Shift_end schließt den Auftrag ab. Senden Sie niemals mehr als ein shift_end-Ereignis für jeden Auftrag!
Erforderliche Daten für Timelogs:
- person_id
- Kann über den /people-Endpunkt gefunden werden
- Nicht dasselbe wie user_id!
- geplante_arbeitsplatz_id
- Der Arbeitsplatz, an dem die Arbeit ausgeführt wird
- Kann über den Endpunkt /workstations gefunden werden
- Datum_Zeit
- Der Zeitpunkt, zu dem das Ereignis durchgeführt wird
- Format: 2024-01-01 10:30:11
Um anzugeben, welches Skyplanner-Timelog mit dem Timelog des von Ihnen verwendeten externen Systems verknüpft ist, können Sie das Feld external_id verwenden. Sie können dann zum Beispiel GET-Anfragen mit dieser ID stellen, um ein bestimmtes Timelog von Skyplanner zu finden.
Einen Job beginnen #
Sie können Aufträge starten, indem Sie eine POST-Anfrage wie diese an die API senden:
Setzen Sie beim Einstellen der POST-Daten für die Zeitprotokolle workshift_id auf 0 und timelog_finalized auf true
Auftrag pausieren #
Pausieren Sie Aufträge, indem Sie eine POST-Anfrage wie diese senden:
In Timelogs vom Typ paused können Sie den Betrag und faulty_amount festlegen. Beachten Sie auch den Timelog-Typ und date_time.
Einen Job fortsetzen #
So setzen Sie ein angehaltenes Timelog fort:
Beachten Sie, dass Sie eine Fehlermeldung erhalten, wenn Sie versuchen, einen Auftrag fortzusetzen, der durch ein shift_end Ereignis beendet wurde.
Beenden eines Jobs #
Hier sehen Sie, wie Sie einen Auftrag mit einem shift_end timelog beenden:
In shift_end-events können Sie die Werte amount und faulty_amount genau wie in paused-events angeben. Beachten Sie, dass Sie eine Fehlermeldung erhalten, wenn Sie versuchen, ein shift_end-Ereignis für einen Job zu erzeugen, der nicht läuft.
Timelogs aktualisieren #
Sie können die Zeitprotokolldaten aktualisieren, indem Sie PUT-Anfragen an den /timelogs-endpoint senden, etwa so:
Beachten Sie, dass Sie sowohl beginTimelog- als auch endTimelog-Daten eingestellt haben müssen, um eine Aktualisierung vornehmen zu können. Zeitprotokolle in Skyplanner werden wie folgt gespeichert: Jedes “vollständige” (Zeitprotokoll, das sowohl einen Anfang als auch ein Ende hat (z.B. shift_begin/continued & paused/shift_end) hat eine separate Entität für den Anfang und das Ende.
Diese werden durch den begin_id-Wert gepaart, der im endTimelog gefunden wurde. Im obigen Beispiel hat das beginTimelog den id-Wert 1 und somit hat sein endTimelog den begin_id-Wert 1.
Sie müssen auch bei jeder Aktualisierungsanfrage die Werte person_id und endTimelog angeben, auch wenn Sie sie nicht ändern.
Alternative Möglichkeiten zur Erstellung von Timelogs #
Hier finden Sie einige alternative Möglichkeiten, wie Sie sich über die API bei Ihren Aufträgen anmelden können.
Logfull #
Wenn Sie sowohl den Beginn als auch das Ende des Zeitprotokolls in einer einzigen Anfrage senden möchten, können Sie den /timelogs/log-full -Endpunkt verwenden, etwa so:
Beachten Sie, wie die Beträge hier gesendet werden: der erste Wert “amount” bezeichnet den fehlerhaften Betrag und der zweite den Betrag. Diese Anfrage erstellt die Entitäten beginlog und endlog in einer einzigen Anfrage.
Quicklog #
Das “Quicklogging” zu einem Auftrag schließt diesen in einer einzigen Anfrage ab und setzt die abgeschlossene Anzahl der Produkte auf den Wert, der in der Auftragsposition festgelegt wurde. Das Quicklogging erfolgt über den /timelogs/quick-log -Endpunkt:
Beachten Sie, dass Sie hier nur die production_planning_job_id, planned_workstation_id und person_id angeben müssen. Die Werte für Zeit und Betrag werden automatisch ausgefüllt. Beachten Sie auch, dass Quicklog-Aufträge immer mit dem shift_end-Ereignis abgeschlossen werden, so dass nach Quicklog keine weitere Protokollierung möglich ist!
