How ERP Systems Work: Modules, Data Flow, and the Ledger Underneath
One transaction followed through every module of an ERP, with the actual journal entries, and why the general ledger is the record everything else reads.
Ένα σύστημα ERP λειτουργεί αποθηκεύοντας κάθε επιχειρηματικό γεγονός μία φορά, σε μία κοινή βάση δεδομένων, και επιτρέποντας σε κάθε ενότητα (module) να διαβάζει και να γράφει σε αυτήν την κοινή εγγραφή. Μια αποσταλμένη παραγγελία είναι ακριβώς η ίδια εγγραφή, είτε την κοιτάζει η αποθήκη, είτε η ομάδα πωλήσεων, είτε ο λογιστής. Η ενότητα που διατηρεί την ακεραιότητα ολόκληρου του συστήματος είναι το γενικό καθολικό (general ledger): κάθε γεγονός με χρηματική αξία καταλήγει εκεί ως μια ισοσκελισμένη λογιστική εγγραφή (journal entry), και κάθε αναφορά (report) προκύπτει από αυτές τις εγγραφές.
Αυτό το άρθρο παρακολουθεί μία πώληση μέσα από τις ενότητες, δείχνει τις λογιστικές εγγραφές που παράγει και εξηγεί γιατί η ενσωμάτωση με ένα ERP αφορά γεγονότα και το καθολικό και όχι οθόνες.
Η κοινή βάση δεδομένων
Πριν από τα ERP, κάθε τμήμα έτρεχε το δικό του πρόγραμμα. Τα αποθέματα βρίσκονταν σε ένα σύστημα αποθήκης, τα τιμολόγια σε ένα σύστημα τιμολόγησης και τα βιβλία σε ένα λογιστικό πακέτο. Το τέλος του μήνα αφιερώνονταν στη συμφωνία (reconciliation) των τριών. Το άρθρο What ERP software is εξηγεί την κατηγορία. Ο μηχανισμός που το κάνει να λειτουργεί είναι ένα ενιαίο μοντέλο δεδομένων στο οποίο:
- μια εγγραφή συνεργάτη (partner) χρησιμοποιείται εξίσου από τις πωλήσεις, τις αγορές και το καθολικό,
- μια εγγραφή είδους (item) περιέχει την ποσότητα αποθέματος, τα στρώματα κόστους FIFO (FIFO cost layers), την τιμή πώλησης και τον λογαριασμό εσόδων,
- ένα παραστατικό (document - παραγγελία, τιμολόγιο, πιστωτικό, αγορά, εντολή παραγωγής) παραπέμπει σε συνεργάτες και είδη και παράγει ακριβώς ένα σύνολο λογιστικών εγγραφών,
- μια λογιστική εγγραφή παραπέμπει στο παραστατικό που την παρήγαγε, ώστε κάθε μέγεθος σε μια αναφορά να μπορεί να ανιχνευθεί στην πηγή του.
Όταν τα δεδομένα είναι κοινά, δεν υπάρχει τίποτα προς συμφωνία μεταξύ των ενοτήτων. Αυτό που απομένει για συμφωνία είναι ο έξω κόσμος: οι τραπεζικές κινήσεις και οι φορολογικές δηλώσεις.
Ο χάρτης ενοτήτων
| Ενότητα (Module) | Εγγραφές προς (Writes) | Ανάγνωση από (Reads) |
|---|---|---|
| Πωλήσεις (Sales) | Παραγγελίες, τιμολόγια, πιστωτικά | Συνεργάτες, είδη, τιμές, κανόνες ΦΠΑ |
| Αγορές (Purchasing) | Παραγγελίες αγοράς, τιμολόγια προμηθευτών | Συνεργάτες, είδη, λογαριασμοί εξόδων |
| Αποθήκη (Inventory) | Κινήσεις αποθέματος, στρώματα κόστους FIFO, απογραφές | Eίδη, αποθήκες |
| Παραγωγή (Production) | Εντολές παραγωγής, ανάλωση υλικών, έτοιμο προϊόν | Λίστες υλικών (BOM), απόθεμα |
| Τράπεζα (Bank) | Εισαγόμενες κινήσεις, αντιστοιχίσεις πληρωμών | Ανοιχτά τιμολόγια, τραπεζικοί λογαριασμοί |
| Μισθοδοσία (Payroll) | Εκτελέσεις μισθοδοσίας, εισφορές, υποβολές | Εργαζόμενοι, συμβάσεις, φορολογικοί πίνακες |
| Πάγια (Assets) | Μητρώο παγίων, εκτελέσεις αποσβέσεων | Ομάδες παγίων, ωφέλιμες ζωές |
| Φόροι (Tax) | Δηλώσεις ΦΠΑ, κοινοτικές λίστες, Intrastat, ηλεκτρονικά τιμολόγια | Εκδοθέντα και καταχωρισμένα παραστατικά |
| Γενικό καθολικό (General ledger) | Λογιστικές εγγραφές, κλεισίματα περιόδων | Τα πάντα παραπάνω |
| Αναφορές (Reporting) | Τίποτα | Το γενικό καθολικό και τα αναλυτικά καθολικά |
Κάθε γραμμή εκτός από τις δύο τελευταίες καταλήγει σε μια εγγραφή (write) στο γενικό καθολικό. Αυτός είναι ο σχεδιαστικός κανόνας που ξεχωρίζει ένα ERP από μια ομάδα συνδεδεμένων εργαλείων.
Μια υποθετική ροή δεδομένων στην πράξη
Το παρακάτω παράδειγμα χρησιμοποιεί τα endpoints του Nordlet και τους προεπιλεγμένους λογαριασμούς του λιθουανικού σχεδίου λογαριασμών που διαθέτει. Οποιοδήποτε ERP εκτελεί τα ίδια βήματα, απλώς οι κωδικοί λογαριασμών και τα ονόματα των endpoints διαφέρουν.
1. Παραγγελία
Ένα ηλεκτρονικό κατάστημα υποβάλλει μια παραγγελία μέσω του POST /v1/ecommerce/orders/create: ένας συνεργάτης, γραμμές με είδη και ποσότητες, και μια χώρα αποστολής. Τίποτα δεν καταχωρίζεται ακόμη στο καθολικό. Μια παραγγελία είναι μια δέσμευση, όχι μια συναλλαγή.
2. Δέσμευση αποθέματος
Το orders/reserve δεσμεύει τις ποσότητες ώστε μια δεύτερη παραγγελία να μην μπορεί να πουλήσει τις ίδιες μονάδες. Ακόμη καμία λογιστική εγγραφή: το δεσμευμένο απόθεμα εξακολουθεί να ανήκει στην εταιρεία.
3. Εκπλήρωση παραγγελίας (Fulfilment)
Το orders/fulfill καταγράφει τα αγαθά που φεύγουν από την αποθήκη. Δύο πράγματα συμβαίνουν σε μία συναλλαγή βάσης δεδομένων:
- Το απόθεμα αναλίσκεται με βάση το κόστος FIFO: χρησιμοποιούνται πρώτα τα παλαιότερα στρώματα κόστους για κάθε είδους, σύμφωνα με τη μέθοδο που περιγράφεται στο γλωσσάρι FIFO inventory valuation.
- Το κόστος αυτών των μονάδων καταχωρίζεται ως λογιστική εγγραφή, χρέωση στο κόστος πωληθέντων και πίστωση στο απόθεμα.
| Λογαριασμός | Χρέωση | Πίστωση |
|---|---|---|
| 6000 Κόστος πωληθέντων | 600.00 | |
| 2040 Απόθεμα | 600.00 |
Η εκπλήρωση δημιουργεί επίσης ένα πρόχειρο τιμολόγιο (draft invoice) για την παραγγελία και προσδιορίζει τη φορολογική μεταχείριση ΦΠΑ από τη χώρα αποστολής χρησιμοποιώντας τον EU VAT engine.
4. Έκδοση τιμολογίου
Η έκδοση του τιμολογίου είναι η στιγμή που αναγνωρίζεται το έσοδο για μια πώληση σε δεδομένο χρόνο (point-in-time sale). Το παραστατικό λαμβάνει τον συνεχή αριθμό του και καταχωρίζεται μία ισοσκελισμένη εγγραφή: το μεικτό ποσό στους πελάτες (απαιτήσεις), ο ΦΠΑ στον λογαριασμό ΦΠΑ εκροών και το καθαρό ποσό στα έσοδα.
Για μια καθαρή πώληση 1.000 € με λιθουανικό ΦΠΑ 21%:
| Λογαριασμός | Χρέωση | Πίστωση |
|---|---|---|
| 2410 Απαιτήσεις από πελάτες | 1.210.00 | |
| 5000 Έσοδα από πωλήσεις αγαθών | 1.000.00 | |
| 4492 ΦΠΑ εκροών προς απόδοση | 210.00 |
Εάν μια γραμμή φέρει μέθοδο αναγνώρισης διαφορετική από τη στιγμιαία, το καθαρό ποσό πηγαίνει αντίθετα στα έσοδα επόμενων χρήσεων (deferred income), και ο revenue recognition engine το αποδεσμεύει βάσει χρονοδιαγράμματος. Η καταχώριση των απαιτήσεων και του ΦΠΑ δεν αλλάζει.
Το τιμολόγιο μπορεί πλέον να εξαχθεί ως PDF, ως ηλεκτρονικό τιμολόγιο Peppol BIS 3.0 ή στη μορφή ηλεκτρονικής τιμολόγησης που απαιτεί η χώρα της εταιρείας.
5. Αντιστοίχιση τραπεζικής κίνησης (Bank match)
Δύο εβδομάδες αργότερα φτάνουν 1.210 €. Η κίνηση εισέρχεται μέσω τραπεζικού feed PSD2 ή εισαγωγής αρχείου κίνησης camt.053. Η ενότητα της τράπεζας αξιολογεί τα υποψήφια τιμολόγια βάσει ποσού, αιτιολογίας πληρωμής, ονόματος αντισυμβαλλομένου και IBAN, και το bank/transactions/match καταχωρίζει την εξόφληση:
| Λογαριασμός | Χρέωση | Πίστωση |
|---|---|---|
| 2710 Ταμείο / Τράπεζα | 1.210.00 | |
| 2410 Απαιτήσεις από πελάτες | 1.210.00 |
Η κατάσταση του τιμολογίου αλλάζει σε εξοφλημένο και ενεργοποιείται ένα webhook sale_invoice.paid. Η καταχώριση για την payment reconciliation εξηγεί τη λογική αντιστοίχισης με περισσότερες λεπτομέρειες. Μια πληρωμή σε άλλο νόμισμα καταχωρίζει τη συναλλαγματική διαφορά στον λογαριασμό κερδών ή ζημιών στο ίδιο βήμα.
6. Δήλωση ΦΠΑ
Στο τέλος του μήνα δεν απαιτείται καμία επαναπληκτρολόγηση. Η δήλωση ΦΠΑ υπολογίζεται από τα εκδοθέντα και καταχωρισμένα παραστατικά: declarations/eu/vat-return/compute για την εθνική δήλωση (FR0600 στη Λιθουανία), declarations/eu/oss/compute για διασυνοριακές πωλήσεις σε ιδιώτες στο πλαίσιο του καθεστώτος OSS (Union scheme). Η παραπάνω πώληση καταλήγει στο πεδίο του κανονικού συντελεστή της εγχώριας δήλωσης επειδή το καθεστώς ΦΠΑ της είναι domestic.
7. Κλείσιμο περιόδου
Μόλις υποβληθεί η δήλωση, το ledger/periods/lock κλείνει τον μήνα. Από εκεί και πέρα, οποιαδήποτε καταχώριση με ημερομηνία εντός αυτής της περιόδου, συμπεριλαμβανομένης μιας καθυστερημένης τραπεζικής αντιστοίχισης ή μιας επαναλαμβανόμενης κλήσης API, απορρίπτεται με σφάλμα HTTP 409. Το κλείσιμο ενεργοποιεί επίσης την αναγνώριση τυχόν δεδουλευμένων εσόδων που λήγουν μέχρι το τέλος της περιόδου, ώστε να μην κλείσει ο μήνας αφήνοντας κερdισμένα έσοδα σε λογαριασμό υποχρεώσεων.
Γιατί το καθολικό είναι το σύστημα καταγραφής (system of record)
Κάθε παραπάνω ενότητα διατηρεί ένα αναλυτικό καθολικό (subledger): απαιτήσεις ανά πελάτη, υποχρεώσεις ανά προμηθευτή, απόθεμα ανά είδη, πάγια ανά πάγιο. Το general ledger διατηρεί τα σύνολα με τα οποία αυτά τα αναλυτικά καθολικά πρέπει να συμφωνούν. Το άρθρο Subledger vs general ledger καλύπτει τη σχέση τους. Το πρακτικό σημείο είναι ότι μια αναφορά που κατασκευάζεται από το γενικό καθολικό και μια αναφορά από ένα αναλυτικό καθολικό πρέπει να δίνουν το ίδιο νούμερο, και ένα ERP το εγγυάται αυτό παράγοντας αμφότερα από τις ίδιες λογιστικές εγγραφές.
Τρεις ιδιότητες καθιστούν το καθολικό αξιόπιστο ως αρχείο:
- Επιβάλλεται η ισορροπία. Στο Nordlet η βάση δεδομένων απορρίπτει μια εγγραφή της οποίας οι χρεώσεις δεν ισούνται με τις πιστώσεις. Ένα σφάλμα σε μια ενότητα δεν μπορεί να δημιουργήσει μια ανισόρροπη καταχώριση.
- Το ιστορικό είναι μόνο για προσθήκη (append-only). Μια καταχωρισμένη εγγραφή δεν διορθώνεται ποτέ απευθείας. Ένα λάθος διορθώνεται με αντιλογισμό (reversal) και μια νέα εγγραφή, και οι δύο συνδεδεμένες με την αρχική. Το άρθρο για το immutable ledger εξηγεί γιατί οι ορκωτοί ελεγκτές επιμένουν σε αυτό.
- Οι περίοδοι κλείνουν. Ένας κλειstός μήνας δεν μπορεί να αλλάξει, οπότε τα μεγέθη που υποβάλλατε είναι αυτά που παραμένουν στο σύστημα.
Ενσωμάτωση: γεγονότα και ταυτότητα κλήσεων (idempotency) αντί για νυχτερινές παρτίδες
Οι παλαιότερες ενσωματώσεις ERP βασίζονταν σε αρχεία που ανταλλάσσονταν τη νύχτα: εξαγωγή παραγγελιών, εισαγωγή τους, έλεγχος του αρχείου σφαλμάτων το πρωί. Τα σύγχρονα ERP εκθέτουν ένα API, και η ενσωμάτωση γίνεται ζήτημα δύο κανόνων.
Γεγονότα εξερχόμενα (Events out). Όταν κάτι αλλάζει, το ERP σας ειδοποιεί. Το Nordlet εγγραφεί κάθε γεγονός webhook σε ένα outbox στην ίδια συναλλαγή βάσης δεδομένων με την αλλαγή, οπότε ένα παραστατικό που ακυρώθηκε δεν εκπέμπει ποτέ γεγονός και κανένα γεγονός δεν χάνεται. Οι παραδόσεις υπογράφονται με HMAC-SHA256 και επαναλαμβάνονται με εκθετική καθυστέρηση (exponential backoff). Το σύστημά σας αντιδρά στο sale_invoice.paid αντί να ρωτάει κάθε πέντε λεπτά εάν κάτι έχει πληρωθεί.
Ασφαλείς επαναλήψεις εισερχόμενων (Safe retries in). Τα δίκτυα αποτυγχάνουν, και μια επανειλημμένη αίτηση δεν πρέπει να δημιουργήσει δεύτερο τιμολόγιο. Το Nordlet αποδέχεται μια κεφαλίδα Idempotency-Key σε κάθε κλήση τροποποίησης δεδομένων: το ίδιο κλειδί με το ίδιο payload επιστρέφει την αποθηκευμένη απάντηση, το ίδιο κλειδί με διαφορετικό payload απορρίπτεται, και τα κλειδιά λήγουν μετά από 24 ώρες. Το γλωσσάρι για την idempotency και οι API conventions περιγράφουν την ακριβή συμπεριφορά.
Επειδή κάθε λειτουργία είναι μια κλήση POST /v1/{module}/{resource}/{action} και η εφαρμογή χρησιμοποιεί τα ίδια endpoints, μια ενσωμάτωση μπορεί να εκτελέσει ολόκληρη την παραπάνω ροή χωρίς κανείς να ανοίξει οθόνη. Το άρθρο How to integrate a cloud accounting API into a SaaS platform καθοδηγεί στη δημιουργία μιας τέτοιας υλοποίησης.
Τι διαβάζουν οι αναφορές
Οι αναφορές δεν αποθηκεύουν μεγέθη. Είναι ερωτήματα (queries) πάνω στο καθολικό και τα αναλυτικά καθολικά σε μια δεδομένη χρονική στιγμή:
- Ισοζύγιο, ισολογισμός, κατάσταση αποτελεσμάτων χρήσης, ταμειακές ροές διαβάζουν λογιστικές εγγραφές ανά λογαριασμό και περίοδο.
- Ηλικίωση υπολοίπων (Aging) διαβάζει ανοιχτές απαιτήσεις και υποχρεώσεις ανά ημερομηνία λήξης.
- Υπόλοιπο και κίνηση αποθέματος διαβάζουν το αναλυτικό καθολικό αποθέματος και τα στρώματα FIFO.
- Σύνοψη ΦΠΑ διαβάζει τις γραμμές ΦΠΑ των εκδοθέντων και καταχωρισμένων παραστατικών.
- Αναφορές κέντρων κόστους διαβάζουν τη διάσταση κέντρου κόστους σε κάθε γραμμή εγγραφής.
Στο Nordlet μια αναφορά παράγεται στο παρασκήνιο ως XLSX, PDF ή JSON, και ενεργοποιείται ένα webhook όταν το αρχείο είναι έτοιμο. Τα ομαδικά μεγέθη προέρχονται από την consolidation, η οποία συνδυάζει τα καθολικά πολλών εταιρειών με στάθμιση συμμετοχής και μετατροπή νομισμάτων.
Πού αποτυγχάνει αυτό στην πράξη
Τα περισσότερα προβλήματα των ERP είναι αποτυχίες της αρχής της κοινής εγγραφής και όχι του λογισμικού. Συνήθεις περιπτώσεις:
- Ένα παράλληλο υπολογιστικό φύλλο (spreadsheet) για κάτι που το ERP "δεν μπορεί να κάνει", το οποίο στη συνέχεια διαφωνεί με τα βιβλία.
- Χειροκίνητες λογιστικές εγγραφές που χρησιμοποιούνται για τη διόρθωση της εξόδου μιας ενότητας αντί της διόρθωσης του παραστατικού, γεγονός που σπάει την ιχνηλασιμότητα από την αναφορά στην πηγή.
- Ενσωματώσεις που γράφουν υπόλοιπα αντί για παραστατικά, με αποτέλεσμα το καθολικό να διατηρεί σύνολα που κανείς δεν μπορεί να εξηγήσει.
- Ανοιχτές περίοδοι που παραμένουν ακλείστες για μήνες, με αποτέλεσμα τα μεγέθη του προηγούμενου τριμήνου να αποκλίνουν.
Το άρθρο Why ERP implementations fail καλύπτει πώς διαμορφώνονται αυτές οι συνήθειες κατά την υλοποίηση, και το realistic ERP implementation timelines δείχνει σε ποιο σημείο του έργου εμφανίζονται συνήθως.
FAQ
Ποιος είναι ο πυρήνας ενός συστήματος ERP;
Το γενικό καθολικό και το κοινό μοντέλο δεδομένων γύρω από αυτό. Κάθε ενότητα γράφει παραστατικά που παράγουν ισοσκελισμένες λογιστικές εγγραφές, και κάθε αναφορά προέρχεται από αυτές τις εγγραφές.
Πώς ρέουν τα δεδομένα μέσα σε ένα ERP;
Ένα γεγονός καταγράφεται μία φορά ως παραστατικό (παραγγελία, τιμολόγιο, κίνηση, εκτέλεση μισθοδοσίας). Το παραστατικό παράγει λογιστικές εγγραφές στο καθολικό και κινήσεις στο αντίστοιχο αναλυτικό καθολικό. Οι αναφορές και οι φορολογικές δηλώσεις υπολογίζονται από αυτά τα αρχεία. Τίποτα δεν αντιγράφεται μεταξύ των ενοτήτων.
ποια είναι η διαφορά μεταξύ μιας ενότητας (module) και μιας ενσωμάτωσης (integration);
Μια ενότητα γράφει στην ίδια βάση δεδομένων και στο ίδιο καθολικό με το υπόλοιπο σύστημα. Μια ενσωμάτωση είναι ένα εξωτερικό πρόγραμμα που καλεί το API του ERP. Με ένα API-first ERP η διάκριση είναι μικρή, επειδή η ενσωμάτωση χρησιμοποιεί τα ίδια endpoints που χρησιμοποιούν και οι ενότητες.
Καταχωρίζει ένα ERP λογιστικές εγγραφές αυτόματα;
Ναι. Η έκδοση ενός τιμολογίου, η εκπλήρωση μιας παραγγελίας, η αντισίχιση μιας πληρωμής, η εκτέλεση μισθοδοσίας ή η απόσβεση ενός παγίου παράγουν το καθένα τη λογιστική του εγγραφή χωρίς να χρειάζεται κάποιος να συνθέτει χρεώσεις και πιστώσεις. Οι λογαριασμοί που χρησιμοποιούνται προέρχονται από κανόνες καταχώρισης που μπορούν να αλλάξουν ανά εταιρεία.
Γιατί τα ERP κλείνουν τις λογιστικές περιόδους;
Για να μην μπορούν να αλλάξουν εκ των υστέρων τα μεγέθη που αναφέρθηκαν ή δηλώθηκαν για μια περίοδο. Μια κλειστή περίοδος απορρίπτει νέες καταχωρίσεις, γεγονός που προστατεύει το διαδρομή ελέγχου (audit trail) και αναγκάζει τις διορθώσεις να γίνονται στην τρέχουσα περίοδο όπου είναι ορατές.