Διασύνδεση Eshop με SAP Business One: ροές, προϋποθέσεις και έλεγχοι

Συνδέουμε το Eshop με SAP Business One με συγκεκριμένη ροή και τη διαθέσιμη διεπαφή της εγκατάστασης. Στο SAP Business One η παραγγελία πρέπει να συνδέεται με Business Partner, Item και τον συμφωνημένο κύκλο εμπορικών εγγράφων. Το Eshop δεν πρέπει να αντιμετωπίζει παράδοση, τιμολόγηση και ακύρωση ως απλές αλλαγές ενός γενικού status.

Στο SAP Business One η παραγγελία πρέπει να συνδέεται με Business Partner, Item και τον συμφωνημένο κύκλο εμπορικών εγγράφων. Το Eshop δεν πρέπει να αντιμετωπίζει παράδοση, τιμολόγηση και ακύρωση ως απλές αλλαγές ενός γενικού status. Ο σχεδιασμός χρησιμοποιεί τις διαθέσιμες επιχειρησιακές ενέργειες του Service Layer και κρατά τη σχέση ανάμεσα στο εξωτερικό γεγονός και στα SAP έγγραφα. Ο υπεύθυνος SAP καθορίζει σειρές, αποθήκες, απαιτούμενα πεδία και πότε μια διαδικασία θεωρείται επιχειρησιακά ολοκληρωμένη.

Το Service Layer παρέχει διεπαφή για δεδομένα και υπηρεσίες του Business One. Η επίσημη αναφορά συστήνει OData v4 ως κύριο πρωτόκολλο από FP2405 και χαρακτηρίζει το v3 παρωχημένο, παρότι παραμένει για συμβατότητα. Το Business One δεν είναι S/4HANA. Διαφέρουν τα endpoints, τα αντικείμενα, η παραμετροποίηση και η επιχειρησιακή ροή. Ούτε το Service Layer έχει απόλυτη λειτουργική ταύτιση με το DI API.

Ένας διανομέας ανταλλακτικών καταχωρίζει B2B αγορά ως sales order. Τα είδη αντιστοιχίζονται στο Item master και ο αγοραστής στο σωστό Business Partner. Αν παραδοθεί μόνο μέρος της ποσότητας, το Eshop ενημερώνεται σύμφωνα με τα επιβεβαιωμένα έγγραφα και όχι με μια αυθαίρετη συνολική ένδειξη αποστολής. Αίτημα ακύρωσης εξετάζεται στο στάδιο όπου βρίσκεται η παραγγελία και εκτελείται μόνο μέσω επιτρεπόμενου χειρισμού. Η συσχέτιση παραγγελίας και επόμενων εγγράφων διατηρείται για συμφωνία και υποστήριξη.

Ένα κρίσιμο σενάριο προκύπτει όταν μια ενέργεια ακύρωσης επιχειρείται ως απλή αλλαγή πεδίου αντί του κατάλληλου επιχειρησιακού χειρισμού. Κρατάμε εξωτερική αναφορά και επιβεβαιωμένο ID προορισμού πριν επαναλάβουμε την ενέργεια. Ξεχωρίζουμε αποτυχία πρόσβασης, επιχειρησιακή απόρριψη και αβέβαιο αποτέλεσμα. Ο χειριστής πρέπει να μπορεί να εξετάσει τη σχετική εγγραφή και να αποκαταστήσει την κατάσταση χωρίς να επαναλάβει ολοκληρωμένα βήματα. Συμφωνούμε ποια πεδία εμφανίζονται στις καταγραφές και ποιος αναλαμβάνει τις εκκρεμότητες.

Ελέγχουμε τη δημιουργία παραγγελίας, μια υποστηριζόμενη ακύρωση και τη σωστή συσχέτιση επόμενου εγγράφου. Για κάθε περίπτωση καταγράφουμε αναμενόμενα αρχικά δεδομένα, εγγραφή προορισμού και κατάσταση που βλέπει ο πελάτης. Προσθέτουμε μια αποτυχία δικαιωμάτων και μια διακοπή απόκρισης. Επαναλαμβάνουμε ήδη επιβεβαιωμένο γεγονός και ελέγχουμε ότι το επιχειρησιακό του αποτέλεσμα δεν αλλάζει. Το πρακτικό αποδοχής ορίζει την υπεύθυνη ομάδα και τα τεκμήρια που χρειάζονται για να κλείσει μια απόκλιση.

Η αρχική μελέτη επιβεβαιώνει: Ενεργό και προσβάσιμο Service Layer στην εγκατάσταση· Συμφωνία OData έκδοσης και εξουσιοδοτημένου χρήστη· Υπεύθυνος SAP για αντικείμενα και εμπορικούς κανόνες. Πριν την παραγωγή τεκμηριώνουμε την αντιστοίχιση για τη ροή SAP είδη/πελάτες → αντιστοίχιση Eshop → Checkout → SAP sales order → Επιβεβαίωση → παράδοση/κατάσταση κατά συμφωνία. Ορίζουμε ευθύνη για ανανέωση πρόσβασης, παρακολούθηση και διορθώσεις. Αλλαγή στην παραμετροποίηση του προϊόντος ή στον συμφωνημένο επιχειρησιακό κανόνα ενεργοποιεί στοχευμένο επανέλεγχο. Ξεκινάμε από αυτή τη συγκεκριμένη ροή και προσθέτουμε άλλο κανάλι αφού ξεκαθαρίσουν η ευθύνη και τα σενάρια αποδοχής του.