Η ένδειξη «Σε επεξεργασία» φαίνεται απλή, αλλά συχνά κρύβει πολλές διαφορετικές πραγματικότητες. Η πληρωμή μπορεί να είναι σε αναμονή, τα μισά προϊόντα να έχουν αποσταλεί και ένα τρίτο να περιμένει επιστροφή. Αν το e-shop χρησιμοποιεί ένα μόνο πεδίο κατάστασης, αργά ή γρήγορα θα εμφανίσει λάθος πληροφορία στον πελάτη ή θα ενεργοποιήσει λάθος automation.
Η σωστή μοντελοποίηση μιας παραγγελίας διαχωρίζει τουλάχιστον την επιχειρηματική κατάσταση, την πληρωμή, την εκτέλεση και την επιστροφή. Αυτό ακολουθεί και η λογική ώριμων commerce πλατφορμών, όπου order, payment, fulfillment και return status είναι διαφορετικές διαστάσεις.
Γιατί ένα status δεν αρκεί
Ας υποθέσουμε ότι μια παραγγελία περιέχει δύο προϊόντα. Η κάρτα έχει εξουσιοδοτηθεί αλλά δεν έχει γίνει capture. Το πρώτο προϊόν αποστέλλεται σήμερα και το δεύτερο την επόμενη εβδομάδα. Αν υπάρχει μόνο ένα πεδίο status, ποια τιμή είναι σωστή; Paid, processing, partially shipped ή pending;
Η απάντηση είναι ότι όλες μπορεί να περιγράφουν διαφορετικό μέρος της κατάστασης. Η συγχώνευσή τους δημιουργεί ασαφείς μεταβάσεις και δύσκολα reports. Καλύτερη προσέγγιση είναι οι ανεξάρτητες state machines που συνδέονται με σαφείς κανόνες.
Payment status
Η πληρωμή χρειάζεται δικό της lifecycle. Ενδεικτικές καταστάσεις είναι:
pending: ο πάροχος δεν έχει ολοκληρώσει ακόμη την επιβεβαίωσηauthorized: το ποσό έχει δεσμευτεί αλλά δεν έχει εισπραχθείpaid: η πληρωμή έχει καταγραφεί επιτυχώςpartially_paid: έχει εισπραχθεί μέρος του ποσούfailed: η προσπάθεια απέτυχεvoided: η εξουσιοδότηση ακυρώθηκε πριν το capturepartially_refunded: επιστράφηκε μέρος του ποσούrefunded: επιστράφηκε ολόκληρο το εισπραχθέν ποσό
Το canceled δεν είναι payment status. Μια ακυρωμένη παραγγελία μπορεί να μην είχε πληρωθεί, να χρειάζεται refund ή να έχει μόνο μερική επιστροφή. Η επίσημη τεκμηρίωση του Shopify κάνει ακριβώς αυτόν τον διαχωρισμό: μια ακύρωση μπορεί να μετατρέψει μη captured πληρωμή σε voided ή captured πληρωμή σε refunded.
Fulfillment status ανά γραμμή
Η εκτέλεση αφορά τα προϊόντα και τις ποσότητες που έχουν δεσμευτεί, συλλεχθεί ή αποσταλεί. Μια παραγγελία μπορεί να είναι unfulfilled, partially fulfilled ή fulfilled. Για να υποστηριχθεί σωστά η μερική αποστολή, το fulfillment πρέπει να συνδέεται με order lines και ποσότητες.
Παράδειγμα:
Παραγγελία #1842
- Προϊόν Α, 2 τεμάχια: 2 shipped
- Προϊόν Β, 1 τεμάχιο: 0 shipped, on hold
Συνολικό fulfillment: partially fulfilled
Το tracking number ανήκει στο shipment ή fulfillment, όχι γενικά στην παραγγελία. Αν υπάρχουν δύο δέματα, μπορεί να υπάρχουν δύο carriers, δύο tracking links και διαφορετικές ημερομηνίες.
Ακύρωση δεν σημαίνει πάντα τέλος εργασίας
Η ακύρωση σταματά την εμπορική εκτέλεση, αλλά μπορεί να αφήνει εκκρεμότητες. Πρέπει να αποφασιστεί:
- αν και πόσο απόθεμα επιστρέφει στη διαθεσιμότητα
- αν ακυρώνεται μια authorization ή εκδίδεται refund
- αν ένα fulfillment πρέπει πρώτα να ακυρωθεί
- αν έχει ήδη παραχθεί παραστατικό
- αν χρειάζεται ενημέρωση ERP, αποθήκης ή courier
Η πράξη πρέπει να είναι idempotent. Αν το ίδιο webhook ακύρωσης φτάσει δύο φορές, δεν πρέπει να γίνουν δύο refunds ή διπλή επιστροφή stock. Αποθηκεύονται provider event IDs και ελέγχεται η προηγούμενη εκτέλεση.
Returns και refunds είναι διαφορετικά
Return είναι η φυσική ή λειτουργική επιστροφή προϊόντος. Refund είναι η οικονομική επιστροφή χρημάτων. Μπορεί να υπάρχει return request που δεν έχει εγκριθεί, εγκεκριμένη επιστροφή χωρίς παραλαβή, παραλαβή υπό έλεγχο και refund που εκδόθηκε αργότερα.
Για κάθε επιστρεφόμενη γραμμή χρειάζεται ποσότητα, λόγος, κατάσταση επιθεώρησης, restock απόφαση και ποσό refund. Η σύνδεση με την αρχική πληρωμή και τις εκπτώσεις είναι απαραίτητη ώστε να μην επιστραφεί μεγαλύτερο ποσό από αυτό που πραγματικά πληρώθηκε για τη γραμμή.
Ποιος επιτρέπεται να αλλάζει κατάσταση
Δεν πρέπει κάθε admin χρήστης ή integration να γράφει οποιαδήποτε τιμή. Οι επιτρεπτές μεταβάσεις ορίζονται ρητά. Για παράδειγμα, μια fulfilled παραγγελία δεν γυρίζει απλώς σε unfulfilled· χρειάζεται cancellation ή return workflow με audit trail.
Κάθε αλλαγή καταγράφει actor, χρόνο, προηγούμενη και νέα κατάσταση, reason code και εξωτερικό reference. Για αυτόματες αλλαγές καταγράφεται η πηγή, όπως payment webhook ή ERP sync. Το audit history βοηθά στην υποστήριξη και αποτρέπει ανεξήγητες διορθώσεις.
Τι βλέπει ο πελάτης
Οι εσωτερικές καταστάσεις δεν χρειάζεται να εμφανίζονται αυτούσιες. Ο πελάτης χρειάζεται απλή, ακριβή επικοινωνία: «Η πληρωμή επιβεβαιώθηκε», «Αποστάλθηκαν 2 από 3 προϊόντα» ή «Η επιστροφή χρημάτων ξεκίνησε».
Τα emails και οι ειδοποιήσεις ενεργοποιούνται από πραγματικές μεταβάσεις και όχι από περιοδικό έλεγχο ενός ασαφούς πεδίου. Πριν σταλεί μήνυμα, επιβεβαιώνεται ότι το event δεν έχει ήδη επεξεργαστεί. Έτσι αποφεύγονται διπλά emails αποστολής ή αντικρουόμενες ενημερώσεις.
Reports και ουρές εργασίας
Οι ανεξάρτητες καταστάσεις δημιουργούν χρήσιμες operational views:
- paid αλλά unfulfilled παραγγελίες
- authorized πληρωμές που πλησιάζουν σε λήξη
- partially fulfilled παραγγελίες με καθυστέρηση
- canceled παραγγελίες με εκκρεμές refund
- returns που περιμένουν παραλαβή ή επιθεώρηση
- failed payments που χρειάζονται επικοινωνία
Αυτές οι λίστες βοηθούν την ομάδα να εκτελεί εργασία. Ένα γενικό report «παραγγελίες σε επεξεργασία» δεν δείχνει ποια ακριβώς ενέργεια λείπει.
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry σχεδιάζουμε το order lifecycle πριν συνδέσουμε payment provider, ERP και courier. Διαχωρίζουμε payment, fulfillment, cancellation και return states, ορίζουμε επιτρεπτές μεταβάσεις και αποθηκεύουμε events με idempotency ώστε retries και webhooks να μην παράγουν διπλές ενέργειες.
Στα custom e-shop και portals δημιουργούμε timeline που εξηγεί κάθε αλλαγή, operational queues για την ομάδα και καθαρές ενημερώσεις για τον πελάτη. Ελέγχουμε end-to-end σενάρια όπως partial shipment, failed capture, ακύρωση μετά την πληρωμή και partial refund. Επειδή υλοποιούμε backend, checkout και integrations ως ενιαίο σύστημα, μπορούμε να κρατήσουμε την κατάσταση συνεπή από τον πάροχο πληρωμών μέχρι την αποθήκη και το email του πελάτη.
Συμπέρασμα
Μια παραγγελία δεν είναι μία γραμμική λίστα statuses. Είναι σύνολο συνδεδεμένων lifecycles με διαφορετική ευθύνη. Ο σωστός διαχωρισμός μειώνει τα λάθη, κάνει τις επιστροφές ελέγξιμες και δίνει σε πελάτη και ομάδα ακριβή εικόνα για το τι έχει γίνει και τι απομένει.