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

    Θα ήθελα, χρησιμοποιώντας αρκετή συσσωρευμένη εμπειρία από συστήματα λογισμικού και σύνθετα πληροφοριακά συστήματα αλλά και από συστήματα Retail μεσαίων και μεγάλων επιχειρήσεων να καταθέσω μερικές, σκέψεις, προτάσεις και προβληματισμούς. Θεωρώ πως θα πρέπει να προσεχθεί το θέμα της αποστολής των αποδείξεων ανά 50 και γενικά στην εφικτότητα των near rel-time διαδικασιών που αναφέρονται. Λαμβάνοντας υπόψη στοιχεία όπως: 1. Η διαθεσιμότητα του internet ή του WAN Connection ενός POS / Ταμειακής μηχανής με το ΓΓΠΣ ή με τα κεντρικά της επιχείρησης (που αυτά με τη σειρά τους θα ανεβάζουν τις αποδείξεις στο ΓΓΠΣ). Αν και το size του προτεινόμενου RESTful service είναι μικρό θα μπορούσε να σκεφτεί κανείς το μέγεθος των πακέτων που θα μετακινούνται από κάθε POS είτε μέσω του WAN είτε μέσω του Internet από το κατάστημα (που έχει πολλά POS) προς την αρχή. Η επικοινωνία αυτή θα επιβαρύνει αρκετά την υφιστάμενη δικτυακή υποδομή των επιχειρήσεων οπότε θα δημιουργηθούν προβλήματα που φοβάμαι πως θα αποτελέσουν αφορμές ή αιτίες για τη μη εφαρμογή του μέτρου. 2. Η τήρηση των στοιχείων αποστολής μέσα στην ίδια την ταμειακή μηχανή ανά 50 ή 100 θα πρέπει να λαμβάνει υπόψη της: α) Μη διαθεσιμότητα internet ή WAN σύνδεσης β) Fail Over Scenaria (DSL down, Shop Connection Down, κ.ο.κ.) Τέτοια σενάρια θα είναι συχνά με αποτέλεσμα την μη ουσιαστική εφαρμογή του μέτρου τουλάχιστον από τις μικρομεσαίες επιχειρήσεις που δεν έχουν τη δυνατότητα βέλτιστου σχεδιασμού υποδομών. 3. Σε όποια περίπτωση θα πρότεινα το message body του REST service να είναι compressed (ούτως ή άλλως προτείνετε Base64 κωδικοποίηση) βάσει κοινώς αποδεκτού standard π.χ. ZIP format έτσι ώστε να ελαχιστοποιήσουμε το byte transfer σε όποια συνθήκη. 4. Ανεξάρτητα από την on-line ή near real-time σύζευξη των μηχανών με το ΓΓΠΣ θα πρότεινα την θέσπιση και batch διαδικασίας υποβολής των αποδείξεων από τις επιχειρήσεις που θα μπορεί να γίνει και να ανεβάσει μαζικά στοιχεία μέσα στην ίδια εργάσιμη ημέρα. Θα μπορούσε αυτό να συνδυαστεί με την έκδοση του Ζ (ή και του Χ - που σηματοδοτεί αλλαγή βάρδιας). Με αυτόν τον τρόπο αφενός δίνουμε στην επιχείρηση την ευελιξία να μην εμπλέξει την έκδοση της απόδειξης με την άμεση αποστολή της αφετέρου δίνουμε στο ΓΓΠΣ να συλλέξει όλα τα στοιχεία αποδείξεων εντός της ημέρας (π.χ. μέχρι 11.59.59μμ). 5. Η υλοποίηση του REST full service θα πρέπει να βασίζεται σε compensating transaction Λογική και να μπορεί ο όποιος client να μην αναμένει την επιτυχή καταχώρησή του προκειμένου να "αποδεσμευθεί" από την κλήση. 6. Οι περισσότερες ταμειακές μηχανές έχουν σειριακή έξοδο. Μία ιδέα - πρόταση θα ήταν, αντί να "απαιτήσουμε" νέες ταμειακές μηχανές που και κόστος θα βάλουν στις επιχειρήσεις και θα καθυστερήσουν την αποτελεσματική εκμετάλλευση του έργου, να δημιουργηθούν απλά καταγραφικά προγράμματα που θα τρέχουν σε ένα οποιοδήποτε απλό PC που θα είναι συνδεδεμένο με την ταμειακή μηχανή μέσω σειριακής θύρας και αυτό θα καταγράφει εν παραλλήλω τις αποδείξεις. Το πρόγραμμα αυτό, θα αναλαμβάνει είτε ανά 50 / 100 να στέλνει τις αποδείξεις στο ΓΓΠΣ είτε στο τέλος της ημέρας ο "χειριστής / υπεύθυνος" να στέλνει το μαζικό αρχείο στο ΓΓΠΣ μετά το κλείσιμο ημέρας. 7. Αντίστοιχα λειτουργούν τα POS έγκρισης συναλλαγών πιστωτικών καρτών όπου συλλέγουν σε πακέτα τις εκάστοτε "αποδείξεις / εγκρίσεις" συναλλαγών των πιστωτικών καρτών. Αυτές είτε σε επίπεδο πακέτου είτε το αργότερο σε επίπεδο ημέρας αποστέλλονται μαζικά στις Τράπεζες - Φορείς εκκαθάρισης και κλέίνει ο ημερήσιος κύκλος. 8. Επειδή ένα σημαντικό ποσοστό των συναλλαγών λιανικής διεκπεραιώνονται μέσω Retail Software και Smart POS θα πρέπει να αυτά να υποστηρίξουν τις εν λόγω διαδικασίες και να εμπεριέχουν τις δυνατότητες αποστολής & ενημέρωσης των δεδομένων. 9. Συγκρίνοντας τη λογική της κάρτας ταυτοποίησης προσώπου με την αντίστοιχη Loyalty card που πολλές επιχειρήσεις εκδίδουν, η πληκτρολόγηση του Γραμμωτού Κωδικού Φορολογούμενου δεν είναι σωστή διαδικασία. Υποθέτοντας ότι μέσα από αυτό το σύστημα το Υπουργείο Οικονομικών επιθυμεί να διασταυρώσει όχι μόνο τα στοιχεία αποδείξεων από την πλευρά των επιχειρήσεων αλλά και το σύνολο των αποδείξεων που συσσωρεύονται σε ένα ΑΦΜ ή Πρόσωπο τότε θα μπορεί εύκολα κάποιο πρόσωπο να δίνει ως κωδικό σε μία "ακριβή" απόδειξη λιανικής τον κωδικό ενός άλλου προσώπου τον οποίο γνωρίζει (π.χ. από μία πεταμένη απόδειξη ή από μία ξεχασμένη κάρτα). Αυτό είναι ιδιαίτερα κρίσιμο στοχείο που θα οδηγούσε περισσότερο στη λύση του 2 dimensional tag ή άλλων colour / images tags τα οποία συσχετίζουν μεγάλα tokens πληροφορίας που δεν απομνημονεύονται εύκολα ούτε πληκτρολογούνται. Στην περίπτωση αυτή θα είχαμε να αντιμετωπίσουμε το compatibility των υφιστάμενων scanners και τις απωλεσθέντες τυπωμένες κάρτες. Εάν επιθυμούσαμε να θωρακίσουμε ακόμα περισσότερο το απόρρητο της συναλλαγής και την αξιοπιστία των δεδομένων θα πρέπει να οδηγηθούμε σε λύσεις μέσω PIN over Mobile Phone ή Smart Cards με τις όποιες άλλες κοινωικές συνέπειες. 10. Δεν είναι σαφές το πλαίσιο για τις αποδείξεις λιανικής μέσω Business-To-Consumer (B2C) services δηλαδή τα ηλεκτρονικά καταστήματα. 11. Δεν υπάρχει αναφορά (έστω και αν αυτές εξαιρούνται) για συναλλαγές λιανικής πώλησης / αγοράς από χώρες της Ευρωπαϊκής Ένωσης. Το εν λόγω σχετίζεται και με το προηγούμενο θέμα. 12. Επειδή το καθεστώς των Κατηγοριών ΦΠΑ καθώς και των Ποσοστών ανά Κατηγορία ΦΠΑ αλλάζει και θα αλλάζει, θα πρότεινα την κωδικοποίηση των Συντελεστών ΦΠΑ από το Υπουργέιο Οικονομικών και την αποστολή των στοιχείων προς την ΓΓΠΣ βάσει αυτής της κωδικοποίησης. Ειδάλλως ενδέχεται να υπάρξουν πολλαπλές ερμηνέιες της Κατηγορίας ΦΠΑ με το Ποσό ανά Κατηγορία ΦΠΑ, ιδίως αν σκεφτούμε ότι στις ταμειακές μηχανές και εν γένει στα συστήματα λιανικής υπάρχει και η έννοια "ΤΜΗΜΑ ΦΠΑ" που σε κάθε μηχανή έχει διαφορετική αντιστοίχιση. 13. Κατά το ανέβασμα αποδείξεων θα πρέπει το σύστημα της ΓΓΠΣ να επιτρέπει την πολλαπλή εισαγωγή (χωρίς σφάλμα) ιδίου πακέτου αποδείξεων ή αρχείου αποδείξεων. Είναι στην ευχέρεια της ΓΓΠΣ σε περίπτωση διαφορών να αγνοήσει τα νέα records και να τηρήσει τα αρχικά (εντός λογικού πλαισίου) ή το ανάποδο. Σε όποια περίπτωση, η πιθανότητα λόγω retries, Λόγω not received response, κ.ο.κ. του να ξανασταλεί ένα σετ αποδείξεων δεν πρέπει να υποτιμηθεί. 14. Για τον καταναλωτή θα ήταν καλό να ορίσετε ένα 5ψηφιο νούμερο για μηνύματα SMS στα οποία θα μπορεί ο καταναλωτής να κάνει submit Μία απόδειξη μέσω SMS Text (λογικά 160 χαρακτήρες σε UTF-8) είναι αρκετοί για τα απαιτήτά στοιχεία μίας απόδειξης. Επιπλέον θα μπορείτε να υποστηρίξετε και μηνύματα τύπου MMS (όπου θα αποστέλλεται η εικόνα με το 2 dim tag). Εδώ θα πρέπει να υπάρχει ειδική τιμολογιακή μεταχείριση των μηνυμάτων αυτών από τις φορείς κινητής τηλεφωνίας. Φυσικά θα υπάρχουν και από τους κατασκευαστές λογισμικού εφαρμογές που θα ανεβάζουν με εύκολο τρόπο τις αποδείξεις στο ΓΓΠΣ από το κινητό του καταναλωτή, αλλά αυτές θα καλούν μέσω Internet το REST service για τις αποδείξεις των κατανωλωτών. Με εκτίμηση, Σταύρος Μένεγος, MSc, Τεχνικός Διευθυντής Entersoft SA