Μετάβαση στο κύριο περιεχόμενο
FromNine
Μενού

Ανάπτυξη και υποδομές

Διασυνδέσεις που κρατούν τα δεδομένα σε κίνηση και δείχνουν πότε σταματούν.

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

Για ελληνικές επιχειρήσεις που πρέπει να εκδίδουν ηλεκτρονικά τιμολόγια μέσω παρόχου από το 2026, και για δημόσιους φορείς που συνδέουν τα συστήματά τους με το gov.gr και μεταξύ τους.

Διασυνδέσεις και API: τα επίπεδα της λύσηςΤέσσερα επίπεδα, το ένα πίσω από το άλλο. Από πάνω προς τα κάτω: οι καταναλωτές, όπως πύλες, εφαρμογές και πράκτορες, η πύλη API με την ταυτότητα, η ραχοκοκαλιά των συμβάντων και, από κάτω, τα συστήματα αναφοράς.01Πύλες, εφαρμογές και πράκτορες02Πύλη API και ταυτότητα03Ραχοκοκαλιά συμβάντων04Συστήματα αναφοράς
  1. 01API που ξεκινούν από το συμβόλαιο, σε OpenAPI και AsyncAPI, με εκδόσεις και τεκμηρίωση
  2. 02Συμβάντα με σειρά, ασφαλή επανάληψη, χειρισμό αποτυχημένων μηνυμάτων και αναπαραγωγή
  3. 03Ροές που παρακολουθούνται σε όλη τη διαδρομή, με ουρές σφαλμάτων που ανήκουν σε συγκεκριμένες ομάδες

01 Προβλήματα

Προβλήματα διασύνδεσης για τα οποία μας καλούν

  1. 01

    Απευθείας συνδέσεις που κανείς δεν τολμά να αλλάξει

    Δεκάδες απευθείας συνδέσεις ανάμεσα σε CRM, ERP και εφαρμογές κατά παραγγελία. Η αλλαγή ενός πεδίου σημαίνει δοκιμές σε δέκα διεπαφές.

  2. 02

    Διπλότυπα και σιωπηλές αποτυχίες

    Μια επανάληψη δημιουργεί δεύτερη παραγγελία ή δεύτερο τιμολόγιο. Ένα μήνυμα που απέτυχε εξαφανίζεται. Οι χρήστες το μαθαίνουν από τους πελάτες.

  3. 03

    Κάθε νέο κανάλι σημαίνει νέα δουλειά διασύνδεσης

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

  4. 04

    Η σύνδεση με το δημόσιο είναι κάθε φορά ξεχωριστό έργο

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

02 Τι παραδίδουμε

Τι παραδίδουμε

  1. 01 Στρατηγική και διαχείριση API

    Σχεδιασμός που ξεκινά από το API, με συμβόλαια OpenAPI και AsyncAPI, πολιτική εκδόσεων, μια πύλη API που την επιβάλλει και μια πύλη για προγραμματιστές ώστε οι ομάδες να βρίσκουν και να επαναχρησιμοποιούν ό,τι υπάρχει.

    Τι κάνουμε

    • Χάρτης των API και των υπευθύνων τους
    • Οδηγίες σχεδιασμού και διαδικασία ελέγχου
    • Πολιτικές της πύλης για ασφάλεια, όρια χρήσης και εκδόσεις
    • Πύλη για προγραμματιστές και κατάλογος API

    Τι παραλαμβάνετε

    • Οδηγίες API που υιοθετούν οι ομάδες σας
    • Ρυθμίσεις της πύλης ως κώδικας
    • Κατάλογος τεκμηριωμένων API
  2. 02 Διασυνδέσεις με βάση τα συμβάντα

    Brokers, καταγραφή αλλαγών και το μοτίβο outbox, με τις λεπτομέρειες που κρίνουν αν όλα αυτά δουλεύουν: σειρά μηνυμάτων, καταναλωτές που αντέχουν την επανάληψη, χειρισμός αποτυχημένων μηνυμάτων και αναπαραγωγή.

    Τι κάνουμε

    • Μοντέλο συμβάντων και κανόνες ονοματοδοσίας
    • Outbox και CDC στα συστήματα προέλευσης
    • Ασφαλής επανάληψη στους καταναλωτές και εγγυήσεις σειράς
    • Ουρές αποτυχημένων μηνυμάτων με εργαλεία αναπαραγωγής

    Τι παραλαμβάνετε

    • Ραχοκοκαλιά συμβάντων σε λειτουργία
    • Μητρώο σχημάτων και κανόνες συμβατότητας
    • Εγχειρίδιο αναπαραγωγής και ανάκαμψης
  3. 03 Πλατφόρμες διασύνδεσης, επιλεγμένες ανά ροή

    Το SAP Integration Suite, το MuleSoft και οι υπηρεσίες διασύνδεσης των παρόχων cloud έχουν το καθένα τη θέση του. Σας λέμε πότε μια πλατφόρμα iPaaS είναι καλύτερη από κώδικα κατά παραγγελία, και πότε όχι.

    Τι κάνουμε

    • Αξιολόγηση του υπάρχοντος middleware
    • Επιλογή πλατφόρμας με βάση το συνολικό κόστος κτήσης και λειτουργίας
    • Επαναχρησιμοποιήσιμες αντιστοιχίσεις και σύνδεσμοι
    • Μετάβαση από παλαιό middleware

    Τι παραλαμβάνετε

    • Αρχείο απόφασης για την πλατφόρμα διασύνδεσης
    • Βιβλιοθήκη μοτίβων διασύνδεσης
    • Σχέδιο μετάβασης για τις υπάρχουσες διεπαφές
  4. 04 Ταυτότητα και εμπιστοσύνη ανάμεσα στα συστήματα

    OAuth 2.0 και OpenID Connect, αμοιβαίο TLS, ταυτότητα μεταξύ υπηρεσιών και διασύνδεση με σχήματα ηλεκτρονικής ταυτοποίησης πολιτών και επιχειρήσεων, όπως τα itsme, DigiD και eHerkenning, BundID, FranceConnect, Cl@ve, SPID και CIE σε άλλα κράτη μέλη.

    Τι κάνουμε

    • Αρχιτεκτονική ταυτότητας για χρήστες και υπηρεσίες
    • Σχεδιασμός tokens, πεδίων δικαιωμάτων και συγκατάθεσης
    • Υποστήριξη στην ένταξη και την πιστοποίηση σε σχήματα ηλεκτρονικής ταυτοποίησης
    • Προετοιμασία για τα ευρωπαϊκά πορτοφόλια ψηφιακής ταυτότητας

    Τι παραλαμβάνετε

    • Σχεδιασμός ταυτότητας και μοντέλο απειλών
    • Διασύνδεση ηλεκτρονικής ταυτοποίησης σε λειτουργία
    • Ταυτότητες υπηρεσιών και εναλλαγή μυστικών σε εφαρμογή
  5. 05 Διαλειτουρ­γικότητα με το δημόσιο

    Διασυνδέσεις με πλατφόρμες ανταλλαγής δεδομένων του δημοσίου κατά τους κανόνες διαλειτουργικότητας του ν. 4727/2020, ηλεκτρονικά τιμολόγια προς αναθέτουσες αρχές κατά το πρότυπο EN 16931 μέσω του δικτύου Peppol, μετά την επικύρωσή τους από το myDATA, και το ευρωπαϊκό τεχνικό σύστημα «μόνον άπαξ». Σε άλλες χώρες συνδέουμε πλατφόρμες όπως το Federal Service Bus και το MAGDA στο Βέλγιο, το Digikoppeling στις Κάτω Χώρες και το PDND στην Ιταλία.

    Τι κάνουμε

    • Ένταξη μαζί με τον φορέα λειτουργίας της πλατφόρμας
    • Αντιστοίχιση με τα εθνικά πρότυπα δεδομένων
    • Απαιτήσεις ασφάλειας και καταγραφής κάθε πλατφόρμας
    • Σχεδιασμός ανταλλαγής δικαιολογητικών με την αρχή «μόνον άπαξ»

    Τι παραλαμβάνετε

    • Πιστοποιημένη σύνδεση με την πλατφόρμα
    • Τεκμηρίωση των αντιστοιχίσεων
    • Διαδικασίες λειτουργίας συμφωνημένες με τον φορέα λειτουργίας
  6. 06 Λειτουργική εικόνα για τους επιχειρη­σιακούς χρήστες

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

    Τι κάνουμε

    • Παρακολούθηση ροών σε επιχειρησιακούς όρους
    • Αναφορές συμφωνίας ανάμεσα στα συστήματα
    • Κατάταξη και δρομολόγηση σφαλμάτων
    • Ειδοποιήσεις ανά υπεύθυνο ροής

    Τι παραλαμβάνετε

    • Πίνακας παρακολούθησης διασυνδέσεων ανά επιχειρησιακή διαδικασία
    • Έλεγχοι συμφωνίας σε λειτουργία
    • Χάρτης υπευθύνων για κάθε ουρά σφαλμάτων

03 Αρχιτεκτονική

Μια ενδεικτική αρχιτεκτονική αναφοράς

Δύο διαδρομές ξεκινούν από τα συστήματα αναφοράς. Τα σύγχρονα αιτήματα περνούν από API συστημάτων και από μια πύλη API που ελέγχει ταυτότητα, πεδία δικαιωμάτων και όρια χρήσης. Οι αλλαγές δημοσιεύονται ως συμβάντα μέσω outbox ή καταγραφής αλλαγών, και οι καταναλωτές τις επεξεργάζονται έτσι ώστε μια επανάληψη να μην αλλάζει το αποτέλεσμα.

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

Επίπεδα του σχεδίου

Συστήματα αναφοράς
Το ERP, το CRM και η διαχείριση υποθέσεων διατηρούν την ευθύνη για τα δεδομένα τους.
Σύγχρονα API
API συστημάτων με εκδόσεις, πίσω από μια πύλη με OAuth 2.0, mTLS και όρια χρήσης.
Συμβάντα
Outbox, broker, ουρά αποτυχημένων μηνυμάτων και αντιστοιχίσεις της πλατφόρμας διασύνδεσης.
Καταναλωτές
Πύλες, εφαρμογές, πράκτορες, συνεργάτες, πάροχοι ηλεκτρονικής τιμολόγησης και πλατφόρμες του δημοσίου, με ηλεκτρονική ταυτοποίηση όπου συμμετέχουν πολίτες.
Ενδεικτικό παράδειγμα
  1. Συστήματα αναφοράς

    • ERP, CRM και συστήματα υποθέσεων
  2. Σύγχρονα API

    • API συστημάτων
    • Πύλη API: OAuth 2.0, mTLS, όρια
  3. Συμβάντα

    • Outbox και CDC
    • Broker συμβάντων
    • Αποτυχημένα μηνύματα και αναπαραγωγή
    • Αντιστοιχίσεις πλατφόρμας διασύνδεσης
  4. Καταναλωτές

    • Πύλες, εφαρμογές και πράκτορες
    • Συνεργάτες, πάροχοι και δημόσιο
    • Ταυτότητα: OIDC, mTLS, eID
  5. Λειτουργία

    • Παρακολούθηση ροών, συμφωνία, ουρές σφαλμάτων με υπεύθυνο
API και ραχοκοκαλιά συμβάντων, δίπλα δίπλα

Ενδεικτική αρχιτεκτονική, όχι σύστημα πελάτη.

Διαβάστε το διάγραμμα ως κείμενο

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

Παράλληλα, τα συστήματα αναφοράς δημοσιεύουν τις αλλαγές μέσω outbox και καταγραφής αλλαγών σε έναν broker συμβάντων, που τις παραδίδει στις ανταλλαγές με συνεργάτες και με το δημόσιο και σε μια πλατφόρμα διασύνδεσης για τις αντιστοιχίσεις. Τα μηνύματα που αποτυγχάνουν πηγαίνουν σε ουρά αποτυχημένων μηνυμάτων με αναπαραγωγή. Υπηρεσίες ταυτότητας με OAuth, mTLS και ηλεκτρονική ταυτοποίηση προστατεύουν τις ανταλλαγές με συνεργάτες.

Μια ζώνη παρακολούθησης από κάτω δείχνει την κατάσταση των ροών, τη συμφωνία και τις ουρές σφαλμάτων με τους υπευθύνους τους.

04 Παράμετροι και όρια

Τεχνικές παράμετροι και όρια

  • Το «ακριβώς μία φορά» είναι σχεδιασμός, όχι ρύθμιση

    Πώς το αντιμετωπίζουμε

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

    Όρια και εξαρτήσεις

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

  • Μια πλατφόρμα iPaaS δεν είναι πάντα η απάντηση

    Πώς το αντιμετωπίζουμε

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

    Όρια και εξαρτήσεις

    Τα μοντέλα αδειοδότησης αλλάζουν. Μια πλατφόρμα φθηνή σήμερα μπορεί να γίνει το μεγαλύτερο κονδύλι του προϋπολογισμού διασυνδέσεων, γι’ αυτό μοντελοποιούμε το κόστος για αρκετά έτη.

  • Οι πλατφόρμες του δημοσίου έχουν τον δικό τους ρυθμό

    Πώς το αντιμετωπίζουμε

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

    Όρια και εξαρτήσεις

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

  • Τα συστήματα τεχνητής νοημοσύνης χρειάζονται στενά API

    Πώς το αντιμετωπίζουμε

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

    Όρια και εξαρτήσεις

    Η έκθεση ενός API σε έναν πράκτορα προσθέτει κίνδυνο. Εξετάζουμε κάθε τέτοιο API με την ομάδα ασφάλειάς σας πριν τεθεί σε λειτουργία.

05 Πώς δουλεύουμε

Πώς δουλεύουμε

Ξεμπλέκουμε πριν χτίσουμε, και αφήνουμε κάθε ροή με υπεύθυνο.

  1. 01

    Χαρτογράφηση των ροών

    Κάθε διεπαφή, ο όγκος της, το ιστορικό αστοχιών της και ο επιχειρησιακός υπεύθυνός της.

    ΑποτέλεσμαΧάρτης διασυνδέσεων και κατάταξη κινδύνου

  2. 02

    Καθορισμός κανόνων

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

    ΑποτέλεσμαΟδηγίες διασύνδεσης και αρχεία αποφάσεων

  3. 03

    Ροή προς ροή

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

    ΑποτέλεσμαΡοές που μεταφέρθηκαν, με τεκμήρια συμφωνίας

  4. 04

    Ορατή λειτουργία

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

    ΑποτέλεσμαΧάρτης υπευθύνων ροών και πίνακες παρακολούθησης

06 Ανθρώπινος έλεγχος

Πού κρατούν τον έλεγχο οι άνθρωποι

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

  • Κάθε ουρά σφαλμάτων έχει υπεύθυνο

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

  • Οι αλλαγές στα συμβόλαια ελέγχονται

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

  • Οι αναπαραγωγές είναι συνειδητές

    Η αναπαραγωγή μηνυμάτων προς ένα σύστημα αναφοράς είναι εξουσιοδοτημένη ενέργεια και καταγράφεται με το ποιος την έκανε και γιατί. Ένα τιμολόγιο δεν ξαναστέλνεται χωρίς απόφαση του λογιστηρίου.

07 Τεχνολογίες

Τεχνολογίες με τις οποίες δουλεύουμε

Πλατφόρμες διασύνδεσης
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • Υπηρεσίες διασύνδεσης AWS και Google Cloud
Συμβάντα και ροές
  • Apache Kafka
  • RabbitMQ
  • Brokers συμβάντων των παρόχων cloud
  • Debezium για καταγραφή αλλαγών
API
  • OpenAPI και AsyncAPI
  • Πύλες API και πύλες για προγραμματιστές
  • GraphQL όπου ταιριάζει
  • Δοκιμές συμβολαίων
Ταυτότητα
  • OAuth 2.0 και OpenID Connect
  • Αμοιβαίο TLS
  • Keycloak και πάροχοι ταυτότητας στο cloud
  • Εθνικά σχήματα ηλεκτρονικής ταυτοποίησης

Η αναφορά σε μια τεχνολογία περιγράφει την τεχνική μας εμπειρία. Δεν σημαίνει συνεργασία με τον κατασκευαστή της ούτε έγκριση από αυτόν.

08 Παράδειγμα

Ένα ενδεικτικό παράδειγμα

Ενδεικτικό παράδειγμα

Ένα ERP συνδεδεμένο με πάροχο ηλεκτρονικής τιμολόγησης, myDATA και Peppol

01Κατάσταση
Ένας μικρός παραγωγός χαρτικών και ειδών καθαριότητας με εσωτερικά ανεπτυγμένο ERP πρέπει από 1 Οκτωβρίου 2026 να εκδίδει τα τιμολόγιά του μέσω παρόχου ηλεκτρονικής τιμολόγησης. Πουλά επίσης σε δημόσια νοσοκομεία ως αναθέτουσες αρχές. Σήμερα το λογιστήριο εξάγει αρχεία με το χέρι, οι απορρίψεις φτάνουν με email και κανείς δεν βλέπει με μια ματιά ποιο τιμολόγιο έγινε δεκτό.
02Τι θα αναπτύσσαμε
Ένα επίπεδο διασύνδεσης που στέλνει κάθε τιμολόγιο από το ERP στο API του παρόχου με κλειδί μοναδικότητας, ώστε μια επανάληψη να μην εκδίδει δεύτερο τιμολόγιο, επιστρέφει στο ERP την κατάσταση κάθε παραστατικού και, για τις αναθέτουσες αρχές, παράγει τιμολόγια κατά EN 16931 για το δίκτυο Peppol.
03Πού αποφασίζουν άνθρωποι
Το λογιστήριο αποφασίζει για κάθε απορριφθέν τιμολόγιο και για κάθε πιστωτικό. Κανένα παραστατικό δεν ξαναστέλνεται χωρίς την έγκρισή του.
04Τι θα μετρούσαμε
Ποσοστό τιμολογίων που εκδίδονται χωρίς χειροκίνητη παρέμβαση, χρόνος επίλυσης μιας απόρριψης και αποκλίσεις ανάμεσα στο ERP και στο myDATA στο τέλος του μήνα.

09 Ανά κλάδο

Στον κλάδο σας

  • Ανταλλαγή δεδομένων με την αρχή «μόνον άπαξ», διαλειτουργικότητα κατά τον ν. 4727/2020, παραλαβή ηλεκτρονικών τιμολογίων κατά τον ν. 4601/2019 και η καταγραφή που απαιτούν οι πλατφόρμες του δημοσίου. Δείτε τη δουλειά μας για τον δημόσιο τομέα.

  • ERP, MES και πύλες προμηθευτών συνδεδεμένα μέσω συμβάντων, ώστε ο προγραμματισμός, η παραγωγή και το σέρβις να βλέπουν την ίδια εικόνα, και η τιμολόγηση να περνά από τον πάροχο ηλεκτρονικής τιμολόγησης στο myDATA χωρίς ξαναπληκτρολόγηση.

  • Κεντρικά συστήματα, CRM και API συνεργατών συνδεδεμένα με ισχυρή ταυτότητα, καταγραφή ελέγχου και συμφωνία που εμπιστεύεται το λογιστήριο.

Ελλάδα

Ηλεκτρονική τιμολόγηση, myDATA και διαλειτουρ­γικότητα

Η υποχρεωτική ηλεκτρονική τιμολόγηση ισχύει από 2 Μαρτίου 2026 για τις οντότητες με ακαθάριστα έσοδα άνω του 1 εκατομμυρίου ευρώ το φορολογικό έτος 2023 και από 1 Οκτωβρίου 2026 για όλες τις υπόλοιπες, οι οποίες μπορούν να χρησιμοποιούν παράλληλα τους προηγούμενους τρόπους έως 31 Δεκεμβρίου 2026. Τα τιμολόγια εκδίδονται μέσω παρόχου ηλεκτρονικής τιμολόγησης ή της εφαρμογής timologio της ΑΑΔΕ, και ο λήπτης πρέπει να αποδεχθεί το ηλεκτρονικό τιμολόγιο. Το σημείο που κρίνει την επιτυχία είναι το ERP και οι ροές γύρω του: η σύνδεση με τον πάροχο, η εικόνα στο myDATA, η αντιστοίχιση και η έγκριση στο λογιστήριο.

Όποιος πουλά σε αναθέτουσες αρχές υποβάλλει επίσης, κατά κανόνα, ηλεκτρονικά τιμολόγια κατά το πρότυπο EN 16931, σύμφωνα με τον ν. 4601/2019 και την ΚΥΑ 52445 ΕΞ 2023, που ταξιδεύουν μέσω του δικτύου Peppol μετά την επικύρωσή τους από το myDATA. Για τους δημόσιους φορείς προστίθενται η διαλειτουργικότητα του ν. 4727/2020, ο Κανονισμός για τη διαλειτουργική Ευρώπη και τα ευρωπαϊκά πορτοφόλια ψηφιακής ταυτότητας του eIDAS 2. Σχεδιάζουμε επίπεδα διασύνδεσης όπου ο πάροχος, το Peppol και οι πλατφόρμες του δημοσίου είναι προσαρμογείς πίσω από σταθερά εσωτερικά συμβόλαια, ώστε μια αλλαγή κανόνα να μην απαιτεί να ξαναγραφτούν τα συστήματα από πίσω.

Ερωτήσεις για διασυνδέσεις και API

Να χρησιμοποιήσουμε πλατφόρμα διασύνδεσης ή να αναπτύξουμε διασυνδέσεις κατά παραγγελία;

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

Διασυνδέετε Salesforce, SAP και Odoo;

Ναι, τακτικά, μεταξύ τους, με λογισμικό κατά παραγγελία, με παρόχους ηλεκτρονικής τιμολόγησης και με συστήματα του δημοσίου. Η FromNine είναι συνεργάτης και των τριών εταιρειών (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), οπότε οι ομάδες διασυνδέσεων δουλεύουν δίπλα σε ειδικούς των πλατφορμών. Δείτε τη δουλειά μας με το SAP.

Χρειαζόμαστε διασυνδέσεις με βάση τα συμβάντα;

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

Μπορείτε να διασυνδέσετε σχήματα ηλεκτρονικής ταυτοποίησης;

Ναι. Διασυνδέουμε σχήματα ηλεκτρονικής ταυτοποίησης πολιτών και επιχειρήσεων και σχεδιάζουμε για τα ευρωπαϊκά πορτοφόλια ψηφιακής ταυτότητας που εισάγουν τα κράτη μέλη στο πλαίσιο του eIDAS 2. Οι απαιτήσεις ένταξης διαφέρουν ανά σχήμα, και τις σχεδιάζουμε από νωρίς.

Έχουμε παλαιό middleware. Πρέπει να το αντικαταστήσουμε;

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

Φέρτε τη διεπαφή που αποτυγχάνει πιο συχνά

Θα σας δείξουμε πώς θα την κάναμε ορατή, ανθεκτική στις επαναλήψεις και με υπεύθυνο, και τι θα χρειαζόταν για να γίνει το ίδιο με τις υπόλοιπες.