Αρχική Διαβουλεύσεις Προδιαγραφών - ΓΓΠΣΤεχνική διαβούλευση σχετικά με την ηλεκτρονική υποβολή αποδείξεωνΣχόλιο του χρήστη Αλέξανδρος Κρητικός | 19 Μαΐου 2010, 15:18
  • Σχόλιο του χρήστη 'Αλέξανδρος Κρητικός' | 19 Μαΐου 2010, 15:18

    Λόγω της πολυετούς εμπειρίας μου σε συστήματα εγγυημένης μεταφοράς δεδομένων σε πραγματικό χρόνο, θα ήθελα με την σειρά μου να καταθέσω τις σκέψεις μου για την εν λόγω διαβούλευση. 1. Προτείνετε μια συγκεκριμένη γραμμογράφηση XML για την μερική η μαζική αποστολή αποδείξεων στη ΓΓΠΣ. Δεν δίνετε όμως σημασία στο γεγονός ότι παρά την ευρεία αποδοχή της XML στην δημιουργία και ανάγνωση (parsing) δεδομένων, το text encoding προσθέτει αρκετά μεγάλο όγκο στα δεδομένα προς την ΓΓΚΠΣ. Αν συγκρίνουμε το μέγεθος σε bytes μιας απόδειξης XML γραμμογράφησης και μιας fixed length οπως αυτή που οι εσείς προτείνετε στην ενότητα 3 βλέπουμε τα εξης: Μέγεθος: 461 bytes ενώ με την fixed length γραμμογράφηση: 0405200615102300000000100000021000XXXXXXXXXXXXXXXXXXXXXXXXXΧ Μέγεθος: 61 bytes Θα πρότεινα λοιπόν για να γίνει μεγάλη εξοικονόμηση bandwidth κατά την μεταφορά να χρησιμοποιηθεί fixed length format και να διαθέσετε σε 2-3 διαδεδομένες γλώσσες (π.χ. java, c#, perl) ένα ανοικτού κώδικα API που να δέχεται XML και να το μετατρέπει σε μια κατάλληλη για μεταφορά compact μορφή. Έτσι δημιουργείτε ένα abstraction layer που σας επιτρέπει να κάνετε αλλαγές στο transmission format εαν χρειαστεί χωρίς να ξαναγράφονται οι εφαρμογές διαχείρησης αποδειξεων. Σημειώστε επίσης πως η χρησιμοποίηση συμπίεσης GZIP των XML δεδομένων για αποστολές μεγαλύτερες των Χ kb, κάτι που άλλωστε υποστηρίζεται στο HTTP protocol έχει νόημα μόνο σε μαζικές αποστολές αποδείξεων αλλιώς ο όγκος των δεδομένων μεγαλώνει (π.χ. η παραπάνω απόδειξη συμπιεσμένη είναι 462 bytes). Τέλος μια εναλλακτική λύση θα ήταν να χρησιμοποιήσετε κάποιο binary XML encoding scheme οπως π.χ. το Millau (http://www9.org/w9cdrom/154/154.html) 2. Περιγράφετε πως ο πολίτης θα έχει υποχρέωση ηλεκτρονικής υποβολής των στοιχείων ετήσιως με δυνατότητα υποβολής σε προγενέστερο χρόνο. Έχετε σκεφτέι πως θα μπορέσετε να λάβετε τον τεράστιο όγκο δεδομένων που θα προσπαθήσουν οι πολίτες να αποστείλουν τον τελευταίο μήνα πριν την λήξη της προθεσμίας υποβολής των Ε1; Είναι γνωστό πως οι έλληνες πολίτες είναι πολίτες της ‘τελευταίας στιγμής’ και άρα κάτι τέτοιο είναι ιδιαίτερα πιθανό. Μηπως θα έπρεπε λοιπόν να δώσετε κάποιο κίνητρο (π.χ. bonus αφορολόγητου) σε πολίτες που θα αποστέλουν τα στοιχεία τους προγενέστερα; 3. Απο το παράρτημα Α, ‘Τρόπος αποστολής XML Payload’ είναι ξεκάθαρο πως προτείνετε ένα σύγχρονο τρόπο επεξεργασίας των στοιχείων όπου κατα την αποστολή (HTTP request) θα επεξεργάζεστε τα στοιχεία (validation) , θα ελέγχετε αν έχουν ήδη αποσταλεί στο παρελθόν κλπ και θα απαντάτε (HTTP response) στην εφαρμογή εαν έγιναν αποδεκτές οι αποδείξεις μαζί με ένα transaction id. Προσωπικά πιστεύω πως αυτή η αρχιτεκτονική δεν θα λειτουργήσει διότι η διαδικασία λήψης των δεδομένων είναι tightly coupled στην διαδικασία επαλήθευσης και την διαδικασία καταγραφής των δεδομένων. Έτσι, όσο περισσότερες αποδείξεις εμπεριέχονται σε μια αποστολή, τόσο περισσότερο χρόνο θα χρειάζεται το web service για να απαντήσει και τόσο μεγαλύτερο θα είναι το load της βάσης δεδομένων. Προτείνω να χρησιμοποιήσετε αρχιτεκτονική βασισμένη σε Message Oriented Middleware (ΜΟΜ) και να χωρίσετε την διαδικασία σε μικρότερες ενότητες που να επιτρέπουν την πλήρως ασύγχρονη παραλαβή, επαλήθευση και επεξεργασία τους: Α. Αποστολή στοιχείων (request), τοποθέτηση σε ουρά (queue), άμεση απάντηση παραλαβής στον χρήστη με transaction id. Β. Ασύχρονη επαλήθευση του μηνύματος της ουράς, αποστολή ενημερωσης στην μερίδα του αποτελέσματος, διαχωρισμός του επαληθευμένου και μη επαλυθευμένου περιεχόμενου σε διαφορετικές απαντητικές ουρές, αποστολή ενημερωτικού (status) μηνυματος στην μερίδα του χρήστη. (email, sms). Γ. Ασύγχρονη επεξεργασία και αποθήκευση του επαληθευμένου περιεχομένου στην βάση δεδομένων σας, αποστολή ενημερωτικού μηνύματος στην μερίδα του χρήστη περιοδικά πχ εβδομαδιαία με email/ sms. 4. Στην ενότητα 2 περιγράφετε πως εαν η ταμειακή μηχανή δέχεται τα στοιχεία του πελάτη θα πρέπει να στέλνει τις αποδείξεις και στην ΓΓΠΣ σύμφωνα με την ενότητα 4 και άρα δεν χρειάζεται να την στέλνει ο πελάτης. Πιστεύω πως υπάρχει μια σοβαρή παράλειψη εδώ καθότι ο πελάτης δεν έχει καμμία επβεβαίωση πως η απόδειξη του καταχωρήθηκε πραγματικά και πως δεν έλαβε μια απόδειξη απο μια αδήλωτη ταμειακή μηχανή (Η ένδειξη "ΔΕΝ ΥΠΟΒΑΛΛΕΤΑΙ" θα μπορεί εύκολα να παραχαραχθεί σε αυτές τις ταμειακές μηχανές). Προτείνω να υπάρχει κάποιας μορφής ειδοποίηση προς τον πολίτη (sms, email κλπ) και το μήνυμα στην απόδειξη να προτρέπει τον πελάτη να καταχωρήσει την απόδειξη εαν η επιβεβαίωση δεν έρθει μέσα σε 24 ώρες. 5. Στην ενότητα 4 περιγράφετε την δυνατότητα σύνδεσης κάθε ταμειακής μηχανής με τα συστήματα της ΓΓΠΣ ώστε να αποστέλλει στοιχεία συναλλαγών σε πραγματικό ή σχεδόν πραγματικό χρόνο. Σίγουρα μελλοντικά μοντέλα ταμειακών μηχανών θα μπορούσαν να προσφέρουν τέτοιες δυνατότητες αλλά την παρούσα στιγμή κάτι τέτοιο θα ήταν εφικτό χρησιμοποιώντας την σειριακή πόρτα της ταμειακής μηχανής και έναν νέο τύπο φορολογικού μηχανισμού (π.χ. τύπου Γ). Ο φορολογικός αυτός μηχανισμός, είτε πρόκειται για επιχείρηση έκδοσης μηχανογραφημένων αποδείξεων είτε επιχείρηση με απλή ταμειακή μηχανή, θα μπορούσε να στέλνει και την κίνηση Ζ και τα στοιχεία αποδείξεων πάνω απο την ίδια υποδομή. Η συνδεσιμότητα θα μπορούσε να διατίθεται είτε μέσω υπάρχουσας διαδυκτιακής υποδομής, είτε μεσω GPRS/3G είτε ακόμη και μέσω dial up σύνδεσης σε 0800 αριθμό. Ολα τα παραπάνω προσφέρονται ήδη απο διάφορους κατασκευαστές M2M (Machine 2 Machine) modules με αρκετά χαμηλό κόστος, ενώ προσφέρουν και υποστήριξη σε εξειδηκευμένα binary προτοκολλα επικοινωνίας σχεδιασμένα για ασύρματες εφαρμογές επικοινωνίας όπως το MQTT (Message Queue Telemetry Transport, http://mqtt.org/). Επίσης, θα μπορούσατε ακόμα και διαθέσετε ένα reference implementation του φορολογικού μηχανισμού στην open source hardware πλατφόρμα Arduino (http://www.arduino.cc/) , έτσι ώστε να προωθήσετε την καινοτομία και να μην απευθυνθείτε μόνο στους κατασκευαστές ταμειακών μηχανών. Τέλος, θα μπορούσε ιδανικά η M2M λύση να περιλαμβάνει tamper proof sensors ώστε να αποτρέπεται η κακόβουλη παρέμβαση στους μηχανισμού, οι απόπειρες των οποίων θα μπορούσαν να στέλνουν tamper alarms στην ΓΓΠΣ, με αποτέλεσμα να ελέγχεται η επιχείρηση. 6. Στo παράρτημα Α, περιγράφετε πως η ασφάλεια μεταφοράς των δεδομένων βασίζεται στα πρότυπα HTTP Basic authentication και SSL, ενώ αναφέρετε συγκεκριμένα πως η μέθοδος είναι ασφαλής αφού πρόκειται για https. Προσωπικά βλέπω τουλάχιστον 2 σημαντικούς κινδύνους με αυτή την μέθοδο: Α. Έλειψη ταυτοποίησης της πηγής δεδομένων: Σε περίπτωση που το όνομα και το συνθηματικό της επιχείρησης χρησιμοποιηθούν σε ταμειακή μηχανή / φορολογικό μηχανισμό άλλης επιχείρησης δεν έχετε κάποιο τρόπο να το καταλάβετε καθότι θα είναι αδύνατο να προσδιορισθεί μια σταθερή διεύθυνση IP για την επιχείρηση που στέλνει τα στοιχεία. Β. Ενας κακόβουλος υπάλληλος της επιχείρησης ή και του φορέα παροχής δικτυακής υποδομής θα μπορούσε σχετικά εύκολα να πραγματοποιήσει μια επίθεση man-in-the-middle αλλάζοντας π.χ. την συμπεριφορά της υποδομής DNS και να οδηγήσει τα δεδομένα στην ΓΓΠΣ μέσω όμως κάποιου διακομιστή που αντιγράφει όλα τα στοιχεία για δική του χρήση. Προτείνω λοιπόν την χρήση μιας υποδομής PKI όπου κάθε επιχείρηση να λαμβάνει ένα x509 πιστοποιητικό (και το αντίστοιχο συνθηματικό του) για χρήση στις μεταφορές δεδομένων. Παράλληλα το 'x509 trust hierarchy' και των 2 πλευρών να εμπιστεύεται μόνο την εν λόγω υποδομή PKI οπότε: Α. Ο διακομιστής σας δέχεται συνδέσεις ΜΟΝΟ από κατόχους πιστοποιητικών που έχει ψηφιακά υπογράψει η PKI υποδομή σας. Β. Η ταμειακές μηχανές / φορολογικοί μηχανισμοί εμπιστεύονται συνδέσεις ΜΟΝΟ σε διακομιστές με πιστοποιητικά που έχει ψηφιακά υπογράψει η PKI υποδομή σας. Τέλος, για επιπλέον επαλήθευση στην αποστολή δεδομένων από επιχειρήσεις, θα μπορούσατε να συμπεριλάβετε στοιχεία όπως ο σειριακός αριθμός της ταμειακής μηχανής / φορολογικού μηχανισμού. 7. Στις προτάσεις δεν αναφέρετε κάτι σχετικό με τις συναλλαγές με πιστωτικές κάρτες. Πιστεύω πως ο πιο εύκολος τρόπος θα ήταν να ζητήσετε από τις τράπεζες που συλλέγουν POS συναλλαγές (acquiring) να συμμετέχουν, καθότι και θα αντιμετωπίσουν τις λιγότερες τεχνικές δυσκολίες με δεδομένο πως όλα τα στοιχεία που αποστέλλουν τα POS είναι ήδη ηλεκτρονικής μορφής. Σε συνδυασμό μάλιστα με επιχειρήσεις που συμμετέχουν στην αποστολή των στοιχείων θα έχετε μία επιπλέον επαλήθευση των συναλλαγών και για τις επιχειρήσεις και για τους συμμετέχοντες πολίτες. Παράλληλα, ίσως σε συνδυασμό με κάποιο προνόμιο, κάτι τέτοιο θα μπορούσε να λειτουργήσει σαν κίνητρο για τους πολίτες να χρησιμοποιήσουν πιστωτικές και χρεωστικές κάρτες για τις συναλλαγές τους καθότι οι αποδείξεις τους θα αποστέλλονταν αυτόματα στην μερίδα τους. 8. Η διαβούλευση αναφέρεται σε διάφορους τρόπους ψηφιοποίησης των δεδομένων των συναλλαγών μας με σκοπό να καταλήξουν σε μια ηλεκτρονική μερίδα είτε μιλάμε για πολίτη είτε για επιχείρηση. Τα δεδομένα αυτά μπορεί να τα χρησιμοποιήσετε για την πάταξη της φοροδιαφυγής αλλά παράλληλα ανήκουν και στον εν λόγω πολίτη / επιχείρηση. Μια επιχείρηση με μηχανογραφημένο σύστημα αποδείξεων / ERP υποδομές τα έχει ήδη, μια όμως με απλή ταμειακή μηχανή δεν τα έχει σε ηλεκτρονική μορφή και το ίδιο ισχύει για τον πολίτη. Προτείνω λοιπόν να δώσετε την δυνατότητα εξαγωγής των δεδομένων αυτών για προσωπική χρήση, βοηθώντας έτσι τον πολίτη που συμμετέχει να αναλύσει που ξοδεύει τα χρήματα του και τον απλό έμπορο να μειώσει τα λογιστικά του κόστη. Παράλληλα θα δημιουργήσετε μια νέα αγορά από παράπλευρες υπηρεσίες οι οποίες θα αναλύουν τα δεδομένα αυτά για λογαριασμό πολιτών και μικρών επιχειρήσεων που δεν έχουν ERP υποδομές και θα συμμετέχετε στην ανάπτυξη της οικονομίας. 9. Μέσα σε όλες τις προτάσεις για ψηφιοποίηση της απόδειξης δεν φαίνεται να προτείνετε κάτι που θα μειώσει την χρήση χαρτιού. Είναι κατανοητό πως ο πολίτης που κάνει μια συναλλαγή με φυσική του παρουσία δύσκολα θα δεχτεί να αποχωρήσει χωρίς την απόδειξη / εγγύηση που να του πιστοποιεί την αγορά του αγαθού ή υπηρεσίας. Παρόλο που κάτι τέτοιο θα μπορούσε να εξομαλυνθεί σε περίπτωση ειδοποίησης της καταχώρησης στην μερίδα του (sms, email) θα ήταν σκόπιμο να γίνει μια προσπάθεια στα πρότυπα των υποδομών EBPP (Electronic Bill Presentment and Payment) για υπηρεσίες και συναλλαγές μέσω διαδικτύου ή μηνιαίας κλπ χρέωσης (εξαιρουμένων των ΔΕΚΟ που δεν εκπίπτουν). Η ΓΓΠΣ θα μπορούσε να προσφέρει τις απαραίτητες υποδομές / κίνητρα στις επιχειρήσεις για ηλεκτρονικές αποδείξεις και πληρωμές όταν δεν υπάρχει φυσική παρουσία του πολίτη. Τα πλεονεκτήματα θα ήταν αρκετά: Α. Όλες οι συναλλαγές μέσω EBPP θα κατέληγαν αυτομάτως στις μερίδες των επιχειρήσεων και πολιτών που συμμετέχουν. Β. Η προσπάθεια θα συμβάλλει στην προστασία του περιβάλλοντος λόγω της μείωσης στην χρήση χαρτιού / μελανιού Γ. Οι αποδείξεις αυτές δεν μπορούν να χαθούν. Δ. Μικρές / Πολύ μικρές επιχειρήσεις θα μπορέσουν να προσφέρουν ανώτατης ποιότητας υπηρεσίες. Ε. Τόνωση της οικονομίας από τις παράπλευρες υπηρεσίες που θα μπορούσαν να αναπτυχθούν πάνω σε μια τέτοια υποδομή (π.χ. πληρωμές μέσω κινητών συσκευών κλπ) ΣΤ. Συμβολή των πληρωμών σε ταχυδρομεία στην υποδομή. Με εκτίμηση, Αλέξανδρος Κρητικός Vice President Engineering www.my-channels.com