Τιμολόγιο σε e-shop: στοιχεία checkout, ΑΦΜ, VIES και σύνδεση με ERP/myDATA
Η επιλογή «Θέλω τιμολόγιο» φαίνεται σαν ένα checkbox στο checkout. Πίσω της όμως υπάρχουν διαφορετικά στοιχεία πελάτη, κανόνες φορολόγησης, αρίθμηση παραστατικών, ERP, διαβίβαση στην ΑΑΔΕ και διορθώσεις όταν ο αγοραστής έχει γράψει λάθος ΑΦΜ. Αν το e-shop συλλέγει απλώς μερικά πρόσθετα πεδία και αφήνει τα υπόλοιπα σε χειροκίνητη εργασία, τα λάθη εμφανίζονται μετά την πληρωμή.
Η σωστή υλοποίηση ξεχωρίζει την παραγγελία, την πληρωμή και το φορολογικό παραστατικό. Το άρθρο εστιάζει στον τεχνικό σχεδιασμό της ροής και δεν αντικαθιστά τις οδηγίες λογιστή ή φοροτεχνικού για τους κανόνες που ισχύουν σε κάθε επιχείρηση.
Τι χρειάζεται να συλλέξει το checkout
Όταν ο πελάτης επιλέξει τιμολόγιο, η φόρμα εμφανίζει μόνο τα πεδία που απαιτούνται για το συγκεκριμένο σενάριο: επωνυμία, ΑΦΜ ή VAT number, αρμόδια φορολογική αρχή όπου χρειάζεται, επαγγελματική δραστηριότητα, διεύθυνση τιμολόγησης, χώρα και στοιχεία επικοινωνίας.
Τα labels πρέπει να είναι σαφή και τα δεδομένα να διαχωρίζονται από τη διεύθυνση αποστολής. Μια εταιρεία μπορεί να παραλαμβάνει σε αποθήκη αλλά να τιμολογείται στην έδρα. Το «ίδια με αποστολή» είναι χρήσιμη επιλογή, όχι υπόθεση του συστήματος.
Τα πεδία αποθηκεύονται ως invoice snapshot πάνω στην παραγγελία. Δεν πρέπει το παραστατικό να διαβάζει αργότερα τα τρέχοντα στοιχεία του customer profile, επειδή ο πελάτης μπορεί να αλλάξει διεύθυνση ή επωνυμία μετά την αγορά.
Validation ΑΦΜ και VAT number
Το frontend μπορεί να ελέγχει μήκος και μορφή, αλλά η πραγματική επαλήθευση γίνεται server-side. Για ελληνικό ΑΦΜ εφαρμόζονται format και checksum checks, ενώ η επιχειρησιακή διαδικασία μπορεί να χρησιμοποιεί την κατάλληλη επίσημη υπηρεσία όπου διατίθεται και επιτρέπεται.
Για ενδοκοινοτικές συναλλαγές, το VIES της Ευρωπαϊκής Επιτροπής επιστρέφει αν υπάρχει έγκυρη πληροφορία για VAT number. Η επίσημη σελίδα διευκρινίζει ότι το VIES είναι μηχανή αναζήτησης και όχι δική του βάση δεδομένων, ενώ ένα invalid αποτέλεσμα μπορεί να σημαίνει και ότι ο αριθμός δεν έχει ενεργοποιηθεί για ενδοκοινοτικές συναλλαγές.
Η προσωρινή μη διαθεσιμότητα μιας validation υπηρεσίας δεν πρέπει να μετατρέπεται αυτόματα σε «άκυρο ΑΦΜ». Το e-shop μπορεί να κρατήσει την παραγγελία για review, να επιτρέψει retry ή να ακολουθήσει πολιτική που έχει συμφωνηθεί με τον φοροτεχνικό. Χρειάζεται αποθήκευση του αποτελέσματος, του χρόνου και ενός ασφαλούς validation reference, χωρίς υπερβολικά προσωπικά δεδομένα.
Το validation δεν αποφασίζει μόνο του τη φορολογική μεταχείριση
Ένα έγκυρο VAT number δεν αρκεί από μόνο του για να εφαρμοστεί συγκεκριμένος συντελεστής ή απαλλαγή. Παίζουν ρόλο χώρα πελάτη, τόπος παράδοσης, τύπος προϊόντος, εγκατάσταση της επιχείρησης και άλλες συνθήκες.
Οι φορολογικοί κανόνες πρέπει να έρχονται από παραμετροποιήσιμη tax engine ή ERP policy που έχει ελεγχθεί από ειδικό. Το checkout δεν πρέπει να περιέχει σκόρπιες hard-coded εξαιρέσεις. Κάθε tax decision αποθηκεύει rule version και input facts, ώστε να μπορεί να εξηγηθεί αργότερα.
Αν αλλάξει διεύθυνση ή VAT number πριν την έκδοση, γίνεται νέος υπολογισμός. Μετά την έκδοση, η αλλαγή ακολουθεί διαδικασία διόρθωσης και δεν αντικαθιστά σιωπηλά το αρχικό παραστατικό.
Πότε εκδίδεται το παραστατικό
Η παραγγελία μπορεί να δημιουργηθεί πριν επιβεβαιωθεί η πληρωμή, να ακυρωθεί ή να εκτελεστεί μερικώς. Η επιχείρηση πρέπει να ορίσει το γεγονός που ενεργοποιεί την έκδοση: επιτυχής πληρωμή, αποστολή, ολοκλήρωση υπηρεσίας ή άλλο σημείο σύμφωνα με τις οδηγίες του λογιστή.
Τεχνικά, το event μπαίνει σε queue και εκτελείται idempotently. Αν το payment webhook επαναληφθεί, δεν πρέπει να εκδοθούν δύο τιμολόγια. Το idempotency key μπορεί να βασίζεται σε order, document type και έκδοση της οικονομικής κατάστασης.
Η αρίθμηση παραστατικών ανήκει στο σύστημα έκδοσης ή ERP που είναι source of truth. Το e-shop δεν πρέπει να προβλέπει μόνο του τον επόμενο αριθμό όταν υπάρχουν πολλαπλά κανάλια πώλησης.
Σύνδεση ERP και myDATA
Η ΑΑΔΕ περιγράφει εργαλεία έκδοσης όπως ERP, πιστοποιημένο πάροχο και τις εφαρμογές της, με παραστατικά που διαβιβάζονται στο myDATA και λαμβάνουν ΜΑΡΚ. Η συγκεκριμένη αρχιτεκτονική κάθε επιχείρησης πρέπει να επιβεβαιώνεται με τον λογιστή και τον πάροχο.
Σε integration, το e-shop στέλνει καθαρό invoice payload στο ERP ή invoicing provider: issuer configuration, customer snapshot, γραμμές, καθαρές αξίες, ΦΠΑ, εκπτώσεις, μεταφορικά, currency και references στην παραγγελία. Το ERP επιστρέφει document ID, σειρά, αριθμό, status, PDF reference και όποια επίσημα identifiers διαθέτει.
Η απάντηση δεν θεωρείται επιτυχής μόνο επειδή το HTTP request επέστρεψε 200. Χρειάζεται domain status όπως issued, transmitted, pending ή rejected. Αν η διαβίβαση αποτύχει, η παραγγελία δεν ξαναχρεώνεται και δεν εκδίδεται νέο παραστατικό χωρίς reconciliation.
Ασύγχρονη έκδοση και εμπειρία πελάτη
Το checkout δεν χρειάζεται να περιμένει ολόκληρη τη διαδικασία έκδοσης. Μετά την πληρωμή εμφανίζει ότι η παραγγελία καταχωρήθηκε και το παραστατικό θα είναι διαθέσιμο όταν ολοκληρωθεί.
Ο πελάτης λαμβάνει ειδοποίηση ή βρίσκει το PDF στο account/portal. Το download endpoint κάνει authorization σε κάθε αίτημα και δεν εκθέτει προβλέψιμο public URL. Το PDF είναι output του επίσημου συστήματος έκδοσης και όχι πρόχειρο template που δημιουργήθηκε ανεξάρτητα από τα λογιστικά δεδομένα.
Αν η έκδοση βρίσκεται σε manual review, το support βλέπει σαφή αιτία: αποτυχία VAT validation, απόρριψη ERP ή ασυμφωνία ποσών. Δεν εμφανίζεται γενικό «κάτι πήγε λάθος».
Ακυρώσεις, επιστροφές και πιστωτικά
Η επιστροφή χρημάτων στον payment provider δεν διορθώνει από μόνη της το τιμολόγιο. Χρειάζεται η κατάλληλη λογιστική ροή και σχετικό πιστωτικό ή ακυρωτικό σύμφωνα με τις οδηγίες του φοροτεχνικού και τις δυνατότητες του συστήματος έκδοσης.
Το e-shop συνδέει refund lines με τις αρχικές invoice lines και στέλνει idempotent request για το σχετικό έγγραφο. Τα ποσά, οι φόροι και οι ποσότητες συμφωνούν με ό,τι πραγματικά επιστράφηκε.
Αν γίνει partial refund, δεν αλλάζει το αρχικό PDF. Δημιουργείται νέα, συνδεδεμένη κίνηση. Το customer portal δείχνει την αλυσίδα εγγράφων ώστε ο πελάτης και η ομάδα να καταλαβαίνουν το τελικό υπόλοιπο.
Reconciliation και παρακολούθηση
Μια καθημερινή εργασία συγκρίνει paid orders, issued documents, ERP totals, transmission statuses και refunds. Εντοπίζει παραγγελίες χωρίς παραστατικό, διπλό document reference, ασυμφωνία συνολικής αξίας και pending διαβίβαση.
Τα logs κρατούν correlation ID και status transitions, όχι πλήρη φορολογικά στοιχεία σε κάθε μήνυμα. Τα προσωπικά και εταιρικά δεδομένα έχουν retention και access policy. Μόνο οι κατάλληλοι ρόλοι μπορούν να επανεκδώσουν, να κατεβάσουν ή να ξεκινήσουν διορθωτική διαδικασία.
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry σχεδιάζουμε τη ροή τιμολογίου μαζί με το πραγματικό ERP, τον payment provider και τις οδηγίες του λογιστή της επιχείρησης. Διαχωρίζουμε customer profile, order snapshot και επίσημο παραστατικό, ώστε οι μεταγενέστερες αλλαγές να μην αλλοιώνουν το ιστορικό.
Υλοποιούμε server-side validation, idempotent queues, σαφή statuses και reconciliation μεταξύ e-shop, ERP και πληρωμών. Το customer portal δίνει ασφαλή πρόσβαση στα έγγραφα, ενώ το admin δείχνει ακριβώς ποια ενέργεια εκκρεμεί. Έτσι η αυτοματοποίηση μειώνει τη χειροκίνητη εργασία χωρίς να κρύβει φορολογικές αποφάσεις μέσα σε ανεξέλεγκτο κώδικα.
Checklist υλοποίησης
- Αποθηκεύονται τα στοιχεία τιμολόγησης ως snapshot της παραγγελίας;
- Γίνεται server-side validation με σωστή αντιμετώπιση προσωρινής αποτυχίας;
- Προέρχονται οι tax rules από ελεγμένη, versioned πολιτική;
- Είναι idempotent το trigger έκδοσης;
- Παραμένει το ERP ή ο provider source of truth για αρίθμηση;
- Διακρίνονται issued, transmitted, pending και rejected statuses;
- Προστατεύεται το PDF με authorization;
- Συνδέονται refunds με πιστωτικά και αρχικές γραμμές;
- Υπάρχει καθημερινό reconciliation;
Η καλή ροή τιμολογίου δεν προσθέτει απλώς πεδία στο checkout. Συνδέει με συνέπεια την εμπορική συναλλαγή, την πληρωμή και το επίσημο παραστατικό, με αρκετή διαφάνεια ώστε κάθε εξαίρεση να διορθώνεται.