Πραγματικά Σενάρια

Πέντε καταστάσεις που συναντά κάθε ενσωμάτωση Κάρτας Εργασίας. Για κάθε μία: τι συμβαίνει, τι θα δείτε στην απάντηση του API, και τι να κάνετε.

Ο εργαζόμενος ξέχασε να κάνει αποχώρηση

Τι συμβαίνει: Ο εργαζόμενος φεύγει στις 17:00, αλλά δεν υποβάλλεται γεγονός αποχώρησης (ξεχασμένη κάρτα, η συσκευή έμεινε σε συρτάρι, κ.λπ.). Στις 19:30, κάποιος το παρατηρεί και θέλει να το υποβάλει.

Τι θα δείτε: Αν υποβάλετε τώρα με f_date: "...17:00:00+03:00" και f_aitiologia: null, το Εργάνη θα το απορρίψει — έχουν περάσει περισσότερα από 15 λεπτά από το f_date, οπότε το f_aitiologia είναι υποχρεωτικό.

Πώς να το διορθώσετε:

Να είστε ειλικρινείς για το τι καλύπτουν οι κωδικοί αιτιολόγησης

Οι κωδικοί 001–003 καλύπτουν διακοπές ρεύματος/τηλεπικοινωνιών, βλάβες στα συστήματα του εργοδότη, και προβλήματα σύνδεσης με τον Εργάνη. "Ο εργαζόμενος ξέχασε να κάνει κάρτα" δεν είναι καμία από αυτές. Η χρήση ενός κωδικού που δεν ταιριάζει με την πραγματική αιτία είναι ψευδής δήλωση σε επίσημο αρχείο — μην το κάνετε για να εξαφανίσετε ένα 400.

Δεν υπάρχει διόρθωση σε επίπεδο API που να κάνει αυτή την υποβολή ταυτόχρονα ακριβή και εμπρόθεσμη εκ των υστέρων. Οι επιλογές σας, με σειρά προτίμησης:

1. Πρόληψη: φτιάξτε μια ειδοποίηση/υπενθύμιση την ίδια ημέρα στο σύστημά σας, ώστε οι χαμένες αποχωρήσεις να εντοπίζονται εντός του παραθύρου 15 λεπτών.
2. Αν είναι ήδη εκπρόθεσμο: υποβάλετε το γεγονός παρ' όλα αυτά με το ακριβές f_date: "...17:00:00+03:00". Θα απορριφθεί χωρίς f_aitiologia. Σε αυτό το σημείο, αυτό γίνεται μια χειρωνακτική/νομική διαδικασία εκτός του API — συμβουλευτείτε τις υποχρεώσεις του εργοδότη βάσει του Ν. 4808/2021 για εκπρόθεσμες δηλώσεις. Μην το καλύψετε με έναν κωδικό ανωτέρας βίας που δεν εφαρμόζεται.

Διπλή υποβολή γεγονότος

Τι συμβαίνει: Το σύστημά σας υποβάλλει την ίδια προσέλευση δύο φορές — π.χ. μια επανάληψη ενεργοποιήθηκε αφού το πρώτο request είχε ήδη πετύχει.

Τι θα δείτε: Και τα δύο requests επιστρέφουν 200 OK, το καθένα με δικό του protocol. Το Εργάνη δεν εντοπίζει ούτε απορρίπτει το διπλό.

Πώς να το διορθώσετε: Δεν υπάρχει τίποτα να διορθωθεί — αυτό είναι ασφαλές εκ σχεδιασμού. Σύμφωνα με Επαναλαμβανόμενα γεγονότα για τον ίδιο εργαζόμενο και ημέρα, το Εργάνη χρησιμοποιεί το πιο πρόσφατα υποβληθέν γεγονός ενός δεδομένου f_type για ένα δεδομένο f_afm + f_reference_date ως έγκυρο. Αν και οι δύο υποβολές έχουν το ίδιο f_date (επειδή είναι το ίδιο επαναλαμβανόμενο γεγονός), το διπλό δεν έχει καμία επίδραση στο Ημερολόγιο Πραγματικής Απασχόλησης. Καταγράψτε και τις δύο τιμές protocol για το audit trail σας, αλλά μη φτιάξετε λογική για να "αποτρέψετε" αυτό — δείτε Αποφυγή διπλοεγγραφών.

Αποτυχία δικτύου κατά το request

Τι συμβαίνει: Στέλνετε το POST προσέλευσης, αλλά η σύνδεση διακόπτεται πριν λάβετε απάντηση. Δεν ξέρετε αν το Εργάνη το έλαβε και το επεξεργάστηκε.

Τι θα δείτε: Ένα timeout ή σφάλμα σύνδεσης στην πλευρά του πελάτη — χωρίς protocol, χωρίς message, τίποτα από τον Εργάνη.

Πώς να το διορθώσετε:

1. Υποβάλετε ξανά το ίδιο γεγονός (ίδιο f_afm, f_type, f_reference_date, f_date). Αυτό είναι ασφαλές — δείτε Διπλή υποβολή γεγονότος παραπάνω.
2. Αν και η επανυποβολή αποτύχει και πλησιάζετε στο παράθυρο εμπρόθεσμης υποβολής των 15 λεπτών, συνεχίστε να επαναλαμβάνετε — ένα request που δεν έφτασε ποτέ στον Εργάνη δεν "καταναλώνει" το παράθυρό σας, αλλά κάθε λεπτό που περνάει σας φέρνει πιο κοντά στην ανάγκη για κωδικό αιτιολόγησης για προβλήματα συνδεσιμότητας (f_aitiologia: "003") αν η διακοπή ήταν δική σας ή του Εργάνη — όχι αν απλά είστε αργοί στην επανάληψη.
3. Μόλις ένα request πετύχει, αποθηκεύστε το protocol του. Αν επανυποβάλατε πολλές φορές, μπορεί να καταλήξετε με πολλαπλές τιμές protocol για το ίδιο λογικό γεγονός — αυτό είναι εντάξει, η τελευταία κερδίζει.

Διακεκομμένα ωράρια (την ίδια ημέρα)

Τι συμβαίνει: Ένας εργαζόμενος κάνει προσέλευση στις 09:00, αποχώρηση για ένα διάλειμμα 2 ωρών στις 13:00, και επιστρέφει στις 15:00, τελειώνοντας στις 19:00 — τέσσερα γεγονότα για ένα f_reference_date.

Τι θα δείτε: Όλες οι τέσσερις υποβολές πετυχαίνουν ανεξάρτητα, η καθεμία με το δικό της protocol:

[{ "id": "201", "protocol": "ΕΥΣ201", "submitDate": "06/05/2024 09:00" }]
[{ "id": "202", "protocol": "ΕΥΣ202", "submitDate": "06/05/2024 13:00" }]
[{ "id": "203", "protocol": "ΕΥΣ203", "submitDate": "06/05/2024 15:00" }]
[{ "id": "204", "protocol": "ΕΥΣ204", "submitDate": "06/05/2024 19:00" }]

Πώς να το διορθώσετε: Δεν υπάρχει τίποτα να διορθωθεί — αυτό υποστηρίζεται εγγενώς. Υποβάλετε κάθε γεγονός όπως συμβαίνει, με το f_type να εναλλάσσεται 0/1/0/1 και το ίδιο f_reference_date ("2024-05-06") σε όλη τη διάρκεια. Δεν υπάρχει ούτε χρειάζεται κάποια ειδική σήμανση "διακεκομμένου ωραρίου".

Εκπρόθεσμη διόρθωση

Τι συμβαίνει: Υποβάλατε μια προσέλευση με λάθος ώρα (08:55 αντί για το πραγματικό 08:47), και τη διορθώνετε τώρα, 40 λεπτά αργότερα.

Τι θα δείτε: Η υποβολή του διορθωμένου γεγονότος (f_date: "...08:47:00+03:00", f_aitiologia: null) απορρίπτεται — η διαφορά ανάμεσα στο f_date (08:47) και την ώρα υποβολής (τώρα, ~09:35) είναι πάνω από 15 λεπτά.

Πώς να το διορθώσετε: Αυτή είναι η ίδια κατάσταση με Ο εργαζόμενος ξέχασε να κάνει αποχώρηση — μια διόρθωση δεδομένων, όχι ένα γεγονός ανωτέρας βίας. Οι κωδικοί αιτιολόγησης δεν εφαρμόζονται. Στην πράξη:

• Αν το σύστημά σας εντοπίσει το λάθος εντός 15 λεπτών από την αρχική υποβολή (όχι το αρχικό γεγονός), υποβάλετε αμέσως ξανά — θα είναι ακόμα εκπρόθεσμο σε σχέση με το πραγματικό f_date, αλλά αυτός είναι ένας γνωστός περιορισμός του κανόνα "15 λεπτά από την ώρα του γεγονότος", όχι κάτι που το API σας επιτρέπει να παρακάμψετε με f_aitiologia.
• Για διορθώσεις που εντοπίζονται πολύ μετά τα γεγονότα, χειριστείτε το όπως κάθε άλλη εκπρόθεσμη δήλωση στη διαδικασία συμμόρφωσής σας — δείτε Επισκόπηση Ψηφιακής Κάρτας Εργασίας για το νομικό πλαίσιο.

Τι ακολουθεί

Έχετε πλέον καλύψει ολόκληρη την επιφάνεια ενσωμάτωσης Κάρτας Εργασίας. Για ό,τι άλλο μπορεί να κάνει το API του Εργάνη (ωράρια, έντυπα προσλήψεων, άδειες), δείτε Άλλοι τύποι δηλώσεων.