Μιας και βρισκόμαστε σε περίοδο συμφωνιών με το myData και επειδή από 1/1/2024 οι περιοδικές ΦΠΑ θα πρέπει να συμφωνούν με τα στοιχεία του myData είπα να ασχοληθώ με τις δύο functions RequestMyIncome και RequestMyExpenses.
Φτιάχνω λοιπόν το πρόγραμμα και διαλέγω έναν πελάτη με μεγάλη κίνηση για να τεστάρω την ταχύτητα λήψης των δεδομένων και τυχόν λάθη χρόνου εκτέλεσης. Βάζω ένα μικρό διάστημα ημερομηνιών από – έως (2 ημέρες) μιας και ο πελάτης έχει μεγάλη κίνηση και καλώ την 1η συνάρτηση (RequestMyIncome). Εκτελείται κανονικά χωρίς να επιστρέψει κάποιο λάθος αλλά δεν επιστρέφονται δεδομένα. Το ξαναπροσπαθώ αυξάνοντας λίγο το διάστημα ημερομηνιών. Πάλι τίποτα. Αρχίζω να αμφιβάλλω για την ορθότητα του προγράμματος και του τρόπου διαβίβασης των παραμέτρων. Είδα ότι σε κάποιο σημείο των «προδιαγραφών» ότι το format των ημερομηνιών θα πρέπει να είναι dd/MM/yyyy και δεν μπορούσα να ερμηνεύσω αν τα κεφαλαία γράμματα στον μήνα έχουν κάποια ειδική σημασία που δεν τη γνώριζα. Τελικά μετά από ανεπάλληλες προσπάθειες και αφού αύξησα το διάστημα σε τρείς μήνες η συνάρτηση επέστρεψε δεδομένα.
Παρατηρήσεις πάνω στα δεδομένα που επιστράφηκαν:
1. Η Database από την οποία οι παραπάνω συναρτήσεις αντλούν τις πληροφορίες που επιστρέφουν δεν ενημερώνεται ταυτόχρονα με το myData (δεν είναι on-line). Κάθε πότε ενημερώνεται είναι άγνωστο.
2. Το πλήθος το γραμμών που επιστρέφονται ανά κλήση κυμαίνεται από 997 έως 1000. Για να συνεχίσεις την λήψη εφόσον οι γραμμές είναι περισσότερες από 1000 θα πρέπει να ξανακαλέσεις την συνάρτηση περνώντας δύο επιπλέον παραμέτρους: nextPartitionKey και nextRowKey. Οι τιμές για τις παραμέτρους αυτές επιστρέφονται στο xml δεδομένων μετά την πρώτη κλήση εφόσον το πλήθος των γραμμών που ζητήθηκε ξεπερνά το μέγιστο επιτρεπτό όριο ανά κλήση (τώρα είναι 1000). Οι κλήσεις των συναρτήσεων θα πρέπει να επαναλαμβάνεται μέχρι οι δύο παραπάνω παράμετροι επιστραφούν κενές. Το πρόβλημα που προκύπτει εδώ είναι ότι μετά από μερικές (όχι πολλές) απανωτές κλήσεις η συνάρτηση επιστρέφει λάθος 429 (To many requests) και τερματίζεται. Μπορείτε να μειώσετε το διάστημα για το οποίο ενδιαφέρεστε να κάνετε λήψη, όμως αν μια συγκεκριμένη ημερομηνία έχει πάρα πολλά παραστατικά (πχ 5000), πράγμα όχι απίθανο για μια μεγάλη επιχείρηση, δεν θα μπορείτε να κατεβάσετε τα έσοδα ή τα έξοδα για την ημερομηνία αυτή.
3. Στα δεδομένα που επιστρέφονται δεν περιλαμβάνεται ο αριθμός παραστατικού τον οποίο στέλνουμε κατά τη διαβίβαση των δεδομένων στο myData. Δεν μπορούμε λοιπόν να κάνουμε match τις εγγραφές μας με αυτές που έχει το myData για να κάνουμε συγκρίσεις. Θα μου πείτε γιατί δεν χρησιμοποιείς το MARK της εγγραφής. Ούτε αυτό μπορεί να λειτουργήσει γιατί στα επιστρεφόμενα στοιχεία οι εγγραφές ομαδοποιούνται ανά Ημερομηνία και ΑΦΜ, με αποτέλεσμα αν κάποιος πελάτης ή προμηθευτής έχει την ίδια μέρα 2 ή περισσότερα τιμολόγια θα εμφανιστεί σε μια γραμμή η οποία θα έχει στο πεδίο Count το πλήθος των τιμολογίων στα πεδία minMark και maxMark το μικρότερο και το μεγαλύτερο MARK που αφορούν τον συγκεκριμένο πελάτη ή προμηθευτή τη συγκεκριμένη ημερομηνία και στα πεδία των αξιών το σύνολο των αξιών των τιμολογίων. Προφανώς με τον τρόπο αυτό δεν μπορείς να βγάλεις άκρη.
Ελπίζω οι αρμόδιοι της ΑΑΔΕ να λάβουν υπόψη τους όλα τα παραπάνω και να διορθώσουν τις σχετικές συναρτήσεις ώστε να είναι εφικτός ο έλεγχος των αποκλίσεων. Σε διαφορετική περίπτωση οι παραπάνω συναρτήσεις είναι ουσιαστικά άχρηστες για τον έλεγχο αποκλίσεων μεγάλων εταιριών.