Αν και οι πληροφορίες που έχουν αναρτηθεί είναι ελλιπείς θα ήθελα να παρατηρήσω τα εξής.
1) Το ηλεκτρονικό τιμολόγιο δεν είναι εργαλείο της φορολογικής διοίκησης αλλά, ως μέρος του ευρύτερου ηλεκτρονικού επιχειρείν, πολύτιμο εργαλείο ανταγωνιστικότητας για της επιχειρήσεις. Ο σχεδιασμός του μορφοτύπου (που είναι αδόκιμος νεολογισμός) έχει γίνει με κριτήριο τις ανάγκες του φοροεισπρακτικού μηχανισμού τις οργανωτικές/δομικές παθογένειες του οποίου αναπαράγει. Χαρακτηριστικό παράδειγμα το γεγονός ότι συμπεριλαμβάνεται η Δ.Ο.Υ. (κωδικός ΚΑΙ όνομα!) παρά το γεγονός ότι η σχετική πληροφορία μπορεί να αντληθεί ευχερώς με βάση το ΑΦΜ. Για το λόγο αυτό πρέπει να γίνει επανασχεδιασμός αφού αλλάξει/καταργηθεί και ο ΚΒΣ ώστε να αποφευχθούν τέτοιου είδους redundancies.
2) Για τον ίδιο λόγο η υλοποίηση του τιμολογίου πρέπει να γίνει πάνω στο αντίστοιχο τιμολόγιο της UBL (Universal Business Language) η οποία παρέχει πολύτιμες δυνατότητες στις επιχειρήσεις και η οποία είναι απόλυτα συμβατή με το semantic data model. (βλ. http://ubl.xml.org/forum/einvoicing-%E2%80%93-the-european-saga). Ο προτεινόμενος σχεδιασμός περιλαμβάνει πολλές άχρηστες αποκλίσεις. Οι πλέον επιτυχημένες εφαρμογές e-invoicing διεθνώς έχουν γίνει με βάση την UBL την οποία χρησιμοποιεί για e-invoicing και η ίδια η Ευρωπαϊκή Επιτροπή.
3) Οι πληροφορίες που έχουν αναρτηθεί δεν ορίζουν την πλατφόρμα messaging που θα χρησιμοποιηθεί. Στον βαθμό που προκριθεί η UBL η οποία στηρίζεται στο XML η καλύτερη σήμερα λύση είναι το ebMS (ebXML Messaging) που είναι ένα ασφαλές και ισχυρό πρωτόκολλο επικοινωνίας για ηλεκτρονικό επιχειρείν. Κυρίως είναι ανοικτό πρωτόκολλο η χρήση του οποίου θα εξασφαλίσει ότι α) η υποδομή σε κάθε επιχείρηση θα είναι αξιοποιήσιμη και για συναλλαγές μεταξύ επιχειρήσεων και όχι μόνο μεταξύ δημοσίου και επιχειρήσεων και β) ότι δεν θα επικρατήσουν αδιαφανείς πρακτικές και ολιγοπωλειακές συνθήκες (όπως π.χ. συμβαίνει στην αγορά των φορολογικών μηχανισμών όπου μια μνήμη ολίγων Κbytes κοστίζει στις επιχειρήσεις όσο ένα solid state drive 300 Gigabytes).
4) To ηλεκτρονικό τιμολόγιο δεν είναι ελληνικό ή εθνικό. Παρά τον μάλλον κακό σχεδιασμό του ευρωπαϊκού προτύπου (semantic data model του UN/CEFACT Cross-Industry Invoice (CII) το οποίο η Ευρωπαϊκή Επιτροπή προσπάθησε να συμμαζέψει με το CEN Message User Guideline project -MUG), το «ελληνικό» ηλεκτρονικό τιμολόγιο θα πρέπει να σχεδιαστεί ώστε να είναι πλήρως συμβατό με το ευρωπαϊκό για να χρησιμοποιείται από τις εταιρίες και στις ενδοκοινοτικές τους συναλλαγές (αλλά και στην συνέχεια και με τρίτες χώρες). Έτσι η όποια πρόταση θα πρέπει κατά τη γνώμη μου να αναρτηθεί και στα Αγγλικά ώστε να μπορούν να παρέμβουν και stakeholders από την Ε.Ε.
5) Ομοίως η διαδικασία της δημόσιας διαβούλευσης αν και θετική δεν επαρκεί ούτε χρονικά ούτε τεχνικά για ένα τόσο εξειδικευμένο θέμα. Εν προκειμένω χρειάζεται πολύ εξειδικευμένη εκπροσώπηση την οποία δεν είναι εκ των πραγμάτων ικανοί να παράσχουν οι εταίροι (ΕΒΕΑ, ΓΣΕΒΒΕ κλπ) που συμμετείχαν στις υποτυπώδεις συσκέψεις που έγιναν. Χρειάζεται ουσιαστική συμμετοχή από διευθυντές IT Ελληνικών επιχειρήσεων και software houses και μια πολύ αυστηρότερη διαδικασία ελέγχου όπως αυτή που ακολουθείται συνήθως στα πρότυπα
Αν και οι πληροφορίες που έχουν αναρτηθεί είναι ελλιπείς θα ήθελα να παρατηρήσω τα εξής. 1) Το ηλεκτρονικό τιμολόγιο δεν είναι εργαλείο της φορολογικής διοίκησης αλλά, ως μέρος του ευρύτερου ηλεκτρονικού επιχειρείν, πολύτιμο εργαλείο ανταγωνιστικότητας για της επιχειρήσεις. Ο σχεδιασμός του μορφοτύπου (που είναι αδόκιμος νεολογισμός) έχει γίνει με κριτήριο τις ανάγκες του φοροεισπρακτικού μηχανισμού τις οργανωτικές/δομικές παθογένειες του οποίου αναπαράγει. Χαρακτηριστικό παράδειγμα το γεγονός ότι συμπεριλαμβάνεται η Δ.Ο.Υ. (κωδικός ΚΑΙ όνομα!) παρά το γεγονός ότι η σχετική πληροφορία μπορεί να αντληθεί ευχερώς με βάση το ΑΦΜ. Για το λόγο αυτό πρέπει να γίνει επανασχεδιασμός αφού αλλάξει/καταργηθεί και ο ΚΒΣ ώστε να αποφευχθούν τέτοιου είδους redundancies. 2) Για τον ίδιο λόγο η υλοποίηση του τιμολογίου πρέπει να γίνει πάνω στο αντίστοιχο τιμολόγιο της UBL (Universal Business Language) η οποία παρέχει πολύτιμες δυνατότητες στις επιχειρήσεις και η οποία είναι απόλυτα συμβατή με το semantic data model. (βλ. http://ubl.xml.org/forum/einvoicing-%E2%80%93-the-european-saga). Ο προτεινόμενος σχεδιασμός περιλαμβάνει πολλές άχρηστες αποκλίσεις. Οι πλέον επιτυχημένες εφαρμογές e-invoicing διεθνώς έχουν γίνει με βάση την UBL την οποία χρησιμοποιεί για e-invoicing και η ίδια η Ευρωπαϊκή Επιτροπή. 3) Οι πληροφορίες που έχουν αναρτηθεί δεν ορίζουν την πλατφόρμα messaging που θα χρησιμοποιηθεί. Στον βαθμό που προκριθεί η UBL η οποία στηρίζεται στο XML η καλύτερη σήμερα λύση είναι το ebMS (ebXML Messaging) που είναι ένα ασφαλές και ισχυρό πρωτόκολλο επικοινωνίας για ηλεκτρονικό επιχειρείν. Κυρίως είναι ανοικτό πρωτόκολλο η χρήση του οποίου θα εξασφαλίσει ότι α) η υποδομή σε κάθε επιχείρηση θα είναι αξιοποιήσιμη και για συναλλαγές μεταξύ επιχειρήσεων και όχι μόνο μεταξύ δημοσίου και επιχειρήσεων και β) ότι δεν θα επικρατήσουν αδιαφανείς πρακτικές και ολιγοπωλειακές συνθήκες (όπως π.χ. συμβαίνει στην αγορά των φορολογικών μηχανισμών όπου μια μνήμη ολίγων Κbytes κοστίζει στις επιχειρήσεις όσο ένα solid state drive 300 Gigabytes). 4) To ηλεκτρονικό τιμολόγιο δεν είναι ελληνικό ή εθνικό. Παρά τον μάλλον κακό σχεδιασμό του ευρωπαϊκού προτύπου (semantic data model του UN/CEFACT Cross-Industry Invoice (CII) το οποίο η Ευρωπαϊκή Επιτροπή προσπάθησε να συμμαζέψει με το CEN Message User Guideline project -MUG), το «ελληνικό» ηλεκτρονικό τιμολόγιο θα πρέπει να σχεδιαστεί ώστε να είναι πλήρως συμβατό με το ευρωπαϊκό για να χρησιμοποιείται από τις εταιρίες και στις ενδοκοινοτικές τους συναλλαγές (αλλά και στην συνέχεια και με τρίτες χώρες). Έτσι η όποια πρόταση θα πρέπει κατά τη γνώμη μου να αναρτηθεί και στα Αγγλικά ώστε να μπορούν να παρέμβουν και stakeholders από την Ε.Ε. 5) Ομοίως η διαδικασία της δημόσιας διαβούλευσης αν και θετική δεν επαρκεί ούτε χρονικά ούτε τεχνικά για ένα τόσο εξειδικευμένο θέμα. Εν προκειμένω χρειάζεται πολύ εξειδικευμένη εκπροσώπηση την οποία δεν είναι εκ των πραγμάτων ικανοί να παράσχουν οι εταίροι (ΕΒΕΑ, ΓΣΕΒΒΕ κλπ) που συμμετείχαν στις υποτυπώδεις συσκέψεις που έγιναν. Χρειάζεται ουσιαστική συμμετοχή από διευθυντές IT Ελληνικών επιχειρήσεων και software houses και μια πολύ αυστηρότερη διαδικασία ελέγχου όπως αυτή που ακολουθείται συνήθως στα πρότυπα