Δομή δεδομένων Skyplanner #
Πριν ασχοληθούμε με τα χρονολόγια, πρέπει να συζητήσουμε λίγο για τη δομή των δεδομένων στο Skyplanner και για το πώς λειτουργούν τα πράγματα κάτω από την κουκούλα. Όλα αυτά θα παίξουν ρόλο αργότερα.
Εάν ενσωματώσατε τα δεδομένα των παραγγελιών/εργασιών/εργασιών σας στο Skyplanner, πιθανότατα χρησιμοποιήσατε τουλάχιστον αυτά τα σημεία API:
- phaser-orders
- phaser-order-rows
- phaser-jobs
Πρακτικά, τα δεδομένα που εισάγονται σε αυτά τα τελικά σημεία αναπαρίστανται στο Skyplanner UI ως εξής:
Αφού εισαγάγετε τις παραγγελίες σας στο Skyplanner, θα πρέπει να τις εξάγετε (αυτό μπορεί να γίνει μέσω του UI ή του /phaser-orders/export-endpoint) στην ενότητα Production Scheduling:
Κατά την εξαγωγή παραγγελιών το Skyplanner αντιγράφει ουσιαστικά τα δεδομένα της παραγγελίας από έναν πίνακα της βάσης δεδομένων σε έναν άλλο. Έτσι, αν αλλάξετε κάτι, για παράδειγμα μέσω του /phaser-orders -endpoint, θα πρέπει να εξάγετε ξανά τα δεδομένα για να τα ενημερώσετε στο Production Scheduling. Αυτό σημαίνει επίσης ότι για να αποκτήσετε πρόσβαση στις παραγγελίες που βλέπετε στο παράθυρο Production Scheduling θα πρέπει να χρησιμοποιήσετε διαφορετικά API-endpoints!
Τα “αλλαγμένα” τελικά σημεία έχουν ως εξής:
- /phaser-orders → /orders
- /phaser-order-rows → /order-rows
- /phaser-jobs → /jobs
Αυτό είναι σημαντικό να το γνωρίζετε, επειδή όταν χρησιμοποιείτε το /timelogs -endpoint για να καταγράφετε τα συμβάντα της παραγωγής σας κ.λπ. πρέπει να χρησιμοποιείτε τις σχετικές οντότητες που βρίσκονται στα Production Scheduling -endpoints!
Για παράδειγμα, χρειάζεστε το production_planning_job_id (για να το επαναλάβω: production_planning_jobs είναι οι οντότητες στις οποίες έχετε πρόσβαση από το /jobs -endpoint) για να POST-άρετε ένα νέο timelog:
Μπορείτε να βρείτε το production_planning_job_id που χρειάζεστε είτε από το /phaser-jobs -endpoint:
Ή από το /job -endpoint:
Δημιουργία χρονολογίων με χρήση του REST-API #
Η δημιουργία χρονολογίων στο Skyplanner μέσω του API χρησιμοποιεί τους ίδιους κανόνες και συστήματα που υπάρχουν στο περιβάλλον εργασίας. Επομένως, μπορεί να είναι χρήσιμο να εξοικειωθείτε με τον τρόπο λειτουργίας του συστήματος στο UI πριν επιχειρήσετε να το χρησιμοποιήσετε μέσω του API.
Βασικά στοιχεία Timelog #
Το Skyplanner διαθέτει τέσσερις τύπους συμβάντων χρονολογίου:
- shift_begin
- παύση
- συνέχεια
- shift_end
Το συμβάν Shift_begin- αποστέλλεται όταν η εργασία ξεκινάει για πρώτη φορά. Μην στέλνετε ποτέ περισσότερα από ένα συμβάντα shift_begin για κάθε εργασία!
Paused-event διακόπτει την εργασία.
Το Continued-event συνεχίζει μια διακοπείσα εργασία.
Το Shift_end ολοκληρώνει την εργασία. Μην στέλνετε ποτέ περισσότερα από ένα συμβάντα shift_end για κάθε εργασία!
Απαιτούμενα δεδομένα για χρονολόγια:
- person_id
- Μπορεί να βρεθεί από το /people-endpoint
- Δεν είναι το ίδιο με το user_id!
- planned_workstation_id
- Η θέση εργασίας στην οποία εκτελείται η εργασία
- Μπορεί να βρεθεί από το /workstations-endpoint
- date_time
- Το χρονικό σημείο κατά το οποίο πραγματοποιείται το συμβάν
- Μορφή: 2024-01-01 10:30:11
Για να καθορίσετε ποιο χρονολόγιο του Skyplanner συνδέεται με το χρονολόγιο από οποιοδήποτε εξωτερικό σύστημα χρησιμοποιείτε, μπορείτε να χρησιμοποιήσετε το πεδίο external_id . Στη συνέχεια, μπορείτε, για παράδειγμα, να κάνετε αιτήσεις GET χρησιμοποιώντας αυτό το id για να βρείτε ένα συγκεκριμένο timelog από το Skyplanner.
Ξεκινώντας μια εργασία #
Μπορείτε να ξεκινήσετε εργασίες στέλνοντας POST-έρευνα όπως αυτή στο API:
Όταν ορίζετε τα δεδομένα POST για τα χρονολόγια, ορίστε το workshift_id ως 0 και το timelog_finalized ως true.
Παύση μιας εργασίας #
Παύση εργασιών στέλνοντας ένα αίτημα POST όπως αυτό:
Στα χρονολόγια τύπου παύσης μπορείτε να ορίσετε το ποσό και το faulty_amount. Σημειώστε επίσης τον τύπο του χρονολογίου και την ημερομηνία_ώρα.
Συνέχιση μιας εργασίας #
Ακολουθεί ο τρόπος συνέχισης ενός χρονολογίου σε παύση:
Σημειώστε ότι αν προσπαθήσετε να συνεχίσετε μια εργασία που έχει τερματιστεί από ένα συμβάν shift_end, θα λάβετε ένα σφάλμα.
Τερματισμός εργασίας #
Ακολουθεί ο τρόπος με τον οποίο τερματίζετε μια εργασία με ένα χρονολόγιο shift_end:
Στα shift_end-events μπορείτε να δώσετε τις τιμές amount και faulty_amount όπως ακριβώς και στα paused-events. Σημειώστε ότι αν προσπαθήσετε να εκτελέσετε ένα shift_end-event σε μια εργασία που δεν εκτελείται, θα λάβετε ένα σφάλμα.
Ενημέρωση χρονολογίων #
Μπορείτε να ενημερώνετε τα δεδομένα του χρονολογίου στέλνοντας PUT-ερωτήσεις στο τελικό σημείο /timelogs-, όπως εδώ:
Σημειώστε ότι πρέπει να έχετε ορίσει τα δεδομένα beginTimelog και endTimelog για να πραγματοποιήσετε μια ενημέρωση. Τα χρονολόγια στο Skyplanner αποθηκεύονται ως εξής: κάθε “πλήρες” (χρονολόγιο που έχει και αρχή και τέλος (π.χ. shift_begin/continued & paused/shift_end) χρονολόγιο έχει ξεχωριστή οντότητα για την αρχή και το τέλος.
Αυτά αντιστοιχίζονται με την τιμή begin_id που βρίσκεται στο endlog. Στο παραπάνω παράδειγμα το beginTimelog έχει την τιμή id 1 και επομένως το endTimelog έχει την τιμή begin_id 1.
Πρέπει επίσης να δίνετε τις τιμές person_id και endTimelog για κάθε φορά που κάνετε αίτηση ενημέρωσης, ακόμη και αν δεν τις αλλάζετε.
Εναλλακτικοί τρόποι για να κάνετε timelogs #
Ακολουθούν ορισμένοι εναλλακτικοί τρόποι με τους οποίους μπορείτε να συνδεθείτε στις εργασίες σας χρησιμοποιώντας το API.
Logfull #
Αν θέλετε να στείλετε τόσο την αρχή όσο και το τέλος των χρονολογίων σε μία μόνο αίτηση, μπορείτε να χρησιμοποιήσετε το σημείο /timelogs/log-full -endpoint, όπως παρακάτω:
Προσέξτε πώς αποστέλλονται τα ποσά εδώ: η πρώτη τιμή “ποσό” δηλώνει το ελαττωματικό ποσό και η δεύτερη το ποσό. Αυτή η αίτηση δημιουργεί τις οντότητες beginlog και endlog σε μία μόνο αίτηση.
Quicklog #
Η “ταχεία σύνδεση” σε μια εργασία την ολοκληρώνει με μία μόνο αίτηση, ορίζει την ολοκληρωμένη ποσότητα προϊόντων ώστε να αντιστοιχεί στην τιμή που έχει οριστεί στο στοιχείο παραγγελίας. Η ταχεία καταγραφή γίνεται με τη χρήση του σημείου /timelogs/quick-log -endpoint:
Σημειώστε ότι εδώ χρειάζεται να δώσετε μόνο τα στοιχεία production_planning_job_id, planned_workstation_id και person_id. Οι τιμές του χρόνου και του ποσού συμπληρώνονται αυτόματα. Σημειώστε επίσης ότι οι εργασίες με quicklog ολοκληρώνονται πάντα με το γεγονός shift_end-event, οπότε δεν είναι δυνατή περαιτέρω καταγραφή μετά το quicklog!