Καταρχήν θα ήθελα να συγχαρώ με την σειρά μου για την προσπάθεια που γίνεται επιτέλους, αλλά και να παραπονεθώ επίσης για την καθυστέρηση, την πολυπλοκότητα και την αναβλητικότητα για κρίσιμα θέματα που αναφέρονται στο κείμενο της διαβούλευσης και αφήνονται για αργότερα. Νομίζω πως δεν έχει περιθώρια πλέον η χώρα μας για αποσπασματικά μέτρα και αβεβαιότητες. Πλήθος σωστών διαδικασιών που προτείνονται θα πρέπει να υλοποιηθούν επιτέλους και να μην μετατίθενται για διερεύνηση αργότερα. Αν και εργάζομαι σε εταιρεία πληροφορικής και οι συνεχείς αλλαγές σε πρότυπα και νόμους πάντα λειτουργούν προς όφελος μας, δεν θα πρέπει άλλο να ταλαιπωρούνται οι επιχειρήσεις και οι ελεύθεροι επαγγελματίες.
Θα ήθελα επίσης να επισημάνω τις πολύ καλές παρατηρήσεις κυρίως των Αικατερίνη Τραυλού, Βασίλη Μασσέλου και ιδίως όσον αφορά στην χρήση της UBL, ακόμα και αν υπάρχουν (σιγά μην δεν υπήρχαν) κάποιες ιδιαιτερότητες στην Ελληνική πραγματικότητα.
Δεδομένα header:
α/α 4-5, 6-7: η υποχρεωτικότητα θα έπρεπε να είναι ανάποδα. Εφόσον υπάρχει στο αρχείο πληροφορία η οποία κωδικοποιείται, θα πρέπει η περιγραφή της να μην υπάρχει καθόλου ή έστω να είναι προαιρετική. Βλέπε UBL, standards γενικότερα αλλά και τις περισσότερες μηχανογραφικές εφαρμογές.
α/α 9-10: η πληροφορία αυτή μπορεί να εξαχθεί από πληροφορίες που περιέχονται ήδη στον «μορφότυπο». Δεν θα πρέπει να μπορεί να καταχωρηθεί πληροφορία στο αρχείο, η οποία να επιδέχεται διαφορετικής αντιμετώπισης. Για παράδειγμα αν εσφαλμένα μια εφαρμογή παράγει ένα αρχείο όπου στο πεδίο 9 περιέχει την ένδειξη 3, αλλά στα πεδία 24 έως 59 δεν υπάρχουν αυτά του πελάτη, μπορούν δύο εφαρμογές να χρησιμοποιήσουν διαφορετικά στοιχεία για την εισαγωγή του εκδότη.
α/α 31: δεν χρειάζονται οι λοιπές δραστηριότητες
πεδία διεύθυνσης-δήμου-νομού-κλπ: προτείνεται η οργάνωση, συντήρησης και δημόσιας διάθεσης από ΓΓΠΣ πίνακα της παρακάτω μορφής:
Country (ISO-3166-1)
Country Subdivision (ISO-3166-2) όπου περιέχονται τόσο οι περιφέρειες, όσο και οι νομοί. Μπορεί να ενσωματώσει ιεραρχικά οποιοδήποτε επίπεδο ανάλυσης υποστηρίζει κάθε χώρα και είναι ISO standard.
Δήμος (κωδικοποίηση Καλλικράτη για την Ελλάδα)
Τ.Κ.
Εφόσον καταχωρηθεί ο Τ.Κ. δεν θα είναι υποχρεωτικά τα παραπάνω.
α/α 187,192,197 και 198,199,200: 41 να μην υπάρχει πληροφορία που μπορεί να προκύψει από πράξεις μεταξύ άλλων δεδομένων που μεταφέρονται.
α/α 208-241: να μην υπάρχει πληροφορία που μπορεί να προκύψει από πράξεις μεταξύ άλλων δεδομένων που μεταφέρονται.
α/α 246-247: αν και είναι σχετικά δύσκολο να μοντελοποιηθούν περίπλοκοι τρόποι πληρωμής (πχ Αξία ΦΠΑ μετρητά μέχρι τις 15 του επόμενου μήνα, 30% προκαταβολή, 70% με επιταγή λήξης 90 ημερών), μπορούν τουλάχιστον να χρησιμοποιηθούν τα PAYTERMS του UENECE Rec 17.
Τέλος όσον αφορά στον προσδιορισμό των εμπλεκόμενων μερών (Parties), χρήσιμο θα ήτανε να μπορεί γίνει καταχώρηση του GLN για όποιον έχει και στην περίπτωση αυτή να μην είναι αναγκαία η συμπλήρωση των υπολοίπων στοιχείων διεύθυνσης και επικοινωνίας, αφού μπορούν να εξαχθούν από το http://gepir.gs1.org/v32/xx/gln.aspx.
Κάτι παρόμοιο θα μπορούσε να εφαρμοστεί βέβαια και για τα φορολογικά στοιχεία (ΔΟΥ και ΚΑΔ) από τον ΑΦΜ.
Δεδομένα detail:
α/α 6: Τι θα μπορούσε να καταχωρηθεί εδώ ώστε να είναι χρήσιμο; Αν θα θέλαμε να περιγράψουμε το είδος ώστε να εισαχθεί σωστά αυτοματοποιημένα στην εφαρμογή, θα έπρεπε να υπάρχει πρόβλεψη και για άλλα περιγραφικά δεδομένα, όπως σαιζόν, ετικέτα, μοντέλο κλπ.
α/α 15: θα πρέπει να υπάρχει πρόβλεψη και για τουλάχιστον ακόμα ένα χαρακτηριστικό, ιδιαίτερα απαραίτητο στα προϊόντα ένδυσης (Cup, μήκος παντελονιού κλπ)
α/α 25,36,37,41 να μην υπάρχει πληροφορία που μπορεί να προκύψει από πράξεις μεταξύ άλλων δεδομένων που μεταφέρονται.
α/α 30,32,34: θα ήτανε χρήσιμο να προταθεί κωδικοποίηση από ΓΓΠΣ, ώστε να εξασφαλιστεί συνάφεια
α/α 46-62: αντιμετώπιση όπως στο header
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
Antoine de Saint-Exupery
Καταρχήν θα ήθελα να συγχαρώ με την σειρά μου για την προσπάθεια που γίνεται επιτέλους, αλλά και να παραπονεθώ επίσης για την καθυστέρηση, την πολυπλοκότητα και την αναβλητικότητα για κρίσιμα θέματα που αναφέρονται στο κείμενο της διαβούλευσης και αφήνονται για αργότερα. Νομίζω πως δεν έχει περιθώρια πλέον η χώρα μας για αποσπασματικά μέτρα και αβεβαιότητες. Πλήθος σωστών διαδικασιών που προτείνονται θα πρέπει να υλοποιηθούν επιτέλους και να μην μετατίθενται για διερεύνηση αργότερα. Αν και εργάζομαι σε εταιρεία πληροφορικής και οι συνεχείς αλλαγές σε πρότυπα και νόμους πάντα λειτουργούν προς όφελος μας, δεν θα πρέπει άλλο να ταλαιπωρούνται οι επιχειρήσεις και οι ελεύθεροι επαγγελματίες. Θα ήθελα επίσης να επισημάνω τις πολύ καλές παρατηρήσεις κυρίως των Αικατερίνη Τραυλού, Βασίλη Μασσέλου και ιδίως όσον αφορά στην χρήση της UBL, ακόμα και αν υπάρχουν (σιγά μην δεν υπήρχαν) κάποιες ιδιαιτερότητες στην Ελληνική πραγματικότητα. Δεδομένα header: α/α 4-5, 6-7: η υποχρεωτικότητα θα έπρεπε να είναι ανάποδα. Εφόσον υπάρχει στο αρχείο πληροφορία η οποία κωδικοποιείται, θα πρέπει η περιγραφή της να μην υπάρχει καθόλου ή έστω να είναι προαιρετική. Βλέπε UBL, standards γενικότερα αλλά και τις περισσότερες μηχανογραφικές εφαρμογές. α/α 9-10: η πληροφορία αυτή μπορεί να εξαχθεί από πληροφορίες που περιέχονται ήδη στον «μορφότυπο». Δεν θα πρέπει να μπορεί να καταχωρηθεί πληροφορία στο αρχείο, η οποία να επιδέχεται διαφορετικής αντιμετώπισης. Για παράδειγμα αν εσφαλμένα μια εφαρμογή παράγει ένα αρχείο όπου στο πεδίο 9 περιέχει την ένδειξη 3, αλλά στα πεδία 24 έως 59 δεν υπάρχουν αυτά του πελάτη, μπορούν δύο εφαρμογές να χρησιμοποιήσουν διαφορετικά στοιχεία για την εισαγωγή του εκδότη. α/α 31: δεν χρειάζονται οι λοιπές δραστηριότητες πεδία διεύθυνσης-δήμου-νομού-κλπ: προτείνεται η οργάνωση, συντήρησης και δημόσιας διάθεσης από ΓΓΠΣ πίνακα της παρακάτω μορφής: Country (ISO-3166-1) Country Subdivision (ISO-3166-2) όπου περιέχονται τόσο οι περιφέρειες, όσο και οι νομοί. Μπορεί να ενσωματώσει ιεραρχικά οποιοδήποτε επίπεδο ανάλυσης υποστηρίζει κάθε χώρα και είναι ISO standard. Δήμος (κωδικοποίηση Καλλικράτη για την Ελλάδα) Τ.Κ. Εφόσον καταχωρηθεί ο Τ.Κ. δεν θα είναι υποχρεωτικά τα παραπάνω. α/α 187,192,197 και 198,199,200: 41 να μην υπάρχει πληροφορία που μπορεί να προκύψει από πράξεις μεταξύ άλλων δεδομένων που μεταφέρονται. α/α 208-241: να μην υπάρχει πληροφορία που μπορεί να προκύψει από πράξεις μεταξύ άλλων δεδομένων που μεταφέρονται. α/α 246-247: αν και είναι σχετικά δύσκολο να μοντελοποιηθούν περίπλοκοι τρόποι πληρωμής (πχ Αξία ΦΠΑ μετρητά μέχρι τις 15 του επόμενου μήνα, 30% προκαταβολή, 70% με επιταγή λήξης 90 ημερών), μπορούν τουλάχιστον να χρησιμοποιηθούν τα PAYTERMS του UENECE Rec 17. Τέλος όσον αφορά στον προσδιορισμό των εμπλεκόμενων μερών (Parties), χρήσιμο θα ήτανε να μπορεί γίνει καταχώρηση του GLN για όποιον έχει και στην περίπτωση αυτή να μην είναι αναγκαία η συμπλήρωση των υπολοίπων στοιχείων διεύθυνσης και επικοινωνίας, αφού μπορούν να εξαχθούν από το http://gepir.gs1.org/v32/xx/gln.aspx. Κάτι παρόμοιο θα μπορούσε να εφαρμοστεί βέβαια και για τα φορολογικά στοιχεία (ΔΟΥ και ΚΑΔ) από τον ΑΦΜ. Δεδομένα detail: α/α 6: Τι θα μπορούσε να καταχωρηθεί εδώ ώστε να είναι χρήσιμο; Αν θα θέλαμε να περιγράψουμε το είδος ώστε να εισαχθεί σωστά αυτοματοποιημένα στην εφαρμογή, θα έπρεπε να υπάρχει πρόβλεψη και για άλλα περιγραφικά δεδομένα, όπως σαιζόν, ετικέτα, μοντέλο κλπ. α/α 15: θα πρέπει να υπάρχει πρόβλεψη και για τουλάχιστον ακόμα ένα χαρακτηριστικό, ιδιαίτερα απαραίτητο στα προϊόντα ένδυσης (Cup, μήκος παντελονιού κλπ) α/α 25,36,37,41 να μην υπάρχει πληροφορία που μπορεί να προκύψει από πράξεις μεταξύ άλλων δεδομένων που μεταφέρονται. α/α 30,32,34: θα ήτανε χρήσιμο να προταθεί κωδικοποίηση από ΓΓΠΣ, ώστε να εξασφαλιστεί συνάφεια α/α 46-62: αντιμετώπιση όπως στο header Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery