ERP και CS-Cart: όταν απόθεμα και παραγγελίες διαφέρουν

Ξεκινήστε από τον HTTP κωδικό

Ο connector πρέπει να καταγράφει την απόκριση, όχι μόνο ότι «έτρεξε» η εργασία. Οι παρακάτω σημασίες προέρχονται από την επίσημη σελίδα σφαλμάτων API. Η επόμενη ενέργεια είναι δική μας πρόταση διερεύνησης.

Μην εφαρμόσετε το ίδιο retry σε όλες τις περιπτώσεις. Ένα λάθος mapping ή ανεπαρκές permission δεν διορθώνεται με περισσότερα αιτήματα.

Κωδικός ERP, product_code και product_id δεν είναι το ίδιο

Η οντότητα Products περιλαμβάνει product_id, product_code, amount και company_id. Ο connector πρέπει να ορίζει πώς αντιστοιχίζει τον εξωτερικό κωδικό στο κατάλληλο αντικείμενο της εγκατάστασης.

Δεν υποθέτουμε ότι ίδιο κείμενο κωδικού σημαίνει σωστή αντιστοίχιση. Εξετάζουμε χωριστά παραλλαγές, μεταβολές κωδικών και τυχόν περισσότερα storefronts.

Ένα GET για την κατανόηση του pagination

Η τεκμηρίωση Orders περιγράφει page και items_per_page. Μια διασύνδεση που διαβάζει μόνο την πρώτη σελίδα δεν έχει ελέγξει όλες τις εγγραφές.

GET /api/2.0/orders/?page=2&items_per_page=10

Το παραπάνω είναι παράδειγμα διαδρομής ανάγνωσης, όχι εργαλείο συγχρονισμού ή αποθηκευμένο credential. Προϋποθέτει ενεργή πρόσβαση API, κατάλληλα δικαιώματα και HTTPS. Η απόκριση περιέχει επιχειρησιακά δεδομένα και δεν δημοσιεύεται. Για πραγματική δοκιμή χρησιμοποιήστε απομονωμένο δείγμα με τον τεχνικό υπεύθυνο.

Σε πρακτικό έλεγχο, συγκρίνετε τα συνολικά αναμενόμενα IDs με εκείνα που πράγματι επεξεργάστηκε ο connector. Ο αριθμός αιτημάτων δεν αποδεικνύει ολοκλήρωση της ροής.

Ορίστε ποιο σύστημα αποφασίζει

Πριν εξετάσετε κώδικα, καταγράψτε πού δημιουργείται και πού διορθώνεται κάθε δεδομένο: προϊόν, κωδικός, απόθεμα, τιμή, παραγγελία και κατάσταση. Αν δύο συστήματα ενημερώνουν το ίδιο πεδίο χωρίς κανόνα, είναι δύσκολο να εξηγήσετε μια απόκλιση.

Η επίσημη τεκμηρίωση επιβεβαιώνει ότι το CS-Cart διαθέτει REST API από την έκδοση 4, με JSON και δικαιώματα πρόσβασης ανά χρήστη. Δεν τεκμηριώνει αυτόματα τον τρόπο λειτουργίας ενός ERP connector. Οι παρακάτω έλεγχοι είναι συστάσεις σχεδιασμού, όχι ισχυρισμοί για έτοιμη λειτουργία της πλατφόρμας.

Ακολουθήστε ένα μικρό δείγμα

Διαλέξτε έναν κωδικό προϊόντος ή μια ανωνυμοποιημένη παραγγελία. Σημειώστε τιμή πηγής, αναμενόμενη τιμή προορισμού και χρόνους ενημέρωσης. Ζητήστε από τον τεχνικό υπεύθυνο να συσχετίσει τις καταγραφές των δύο συστημάτων και του connector.

1. Επιβεβαιώστε ότι το mapping αντιστοιχεί στο ίδιο προϊόν και παραλλαγή.
2. Ελέγξτε αν η εργασία ξεκίνησε και αν ο προορισμός απάντησε.
3. Ξεχωρίστε αποτυχία σύνδεσης από απόρριψη συγκεκριμένων δεδομένων.
4. Ελέγξτε αν μια επιτυχημένη μεταφορά αντικαταστάθηκε αργότερα από άλλη ροή.

Προϋπόθεση είναι η δυνατότητα πρόσβασης σε ασφαλείς καταγραφές και η συνεργασία των προμηθευτών. Μην στέλνετε raw payloads με προσωπικά δεδομένα ή tokens στην αρχική φόρμα.

Η επανάληψη δεν πρέπει να διπλασιάζει την εργασία

Συμφωνήστε πώς αναγνωρίζεται μια ήδη μεταφερμένη παραγγελία, τι γίνεται όταν λήξει ο χρόνος αναμονής και ποιος εγκρίνει επανάληψη. Χωρίς αυτά, ένα retry μπορεί να δημιουργήσει δεύτερη εγγραφή ή να μεταφέρει παλιότερο απόθεμα. Δεν προτείνουμε καθολικό αυτοματοποιημένο retry χωρίς έλεγχο συμπεριφοράς.

Διαχωρίστε τις παροδικές αποτυχίες από λανθασμένα δεδομένα. Η δεύτερη περίπτωση συνήθως απαιτεί διόρθωση ή ανθρώπινη απόφαση, όχι συνεχείς επαναλήψεις. Ορίστε ποιος ενημερώνεται για εκκρεμότητες και πώς γίνεται συμφιλίωση.

Ασφαλής πρόσβαση και δοκιμή

Ορίστε τα αναγκαία δικαιώματα, χρησιμοποιήστε HTTPS και κρατήστε τα API keys εκτός δημόσιων αρχείων και logs. Οι πραγματικές εγγραφές αποθέματος και παραγγελιών δεν είναι κατάλληλο πεδίο πειραματισμού. Δοκιμάστε mapping και αποτυχίες σε απομονωμένο περιβάλλον πριν συμφωνηθεί η μετάβαση.

Πότε να ζητήσετε βοήθεια

Αν εμφανίζονται διπλές παραγγελίες ή επαναλαμβανόμενες αποκλίσεις αποθέματος, ζητήστε διερεύνηση ERP / API. Αναφέρετε connector, συστήματα, ένα ανωνυμοποιημένο παράδειγμα και το αναμενόμενο αποτέλεσμα.