MyDATA

Είμαι σχετικά νέος στη χρήση του myDATA και έχω τις παρακάτω απορίες, για όποιον/α μπορεί να βοηθήσει.

1) Παρατηρώ ότι όταν στέλνω απανωτά ένα παραστατικό από την εφαρμογή που φτιάχνω, αυτό αποθηκεύεται στα myDATA με το ίδιο UID αλλά με άλλο ΜΑΡΚ κάθε φορά. Ποιο από τα δύο πεδία πρέπει να χρησιμοποιώ, ώστε να ελέγχω την ορθή αποστολή ενός παραστατικού;

2) Όταν ακυρώνεται ένα παραστατικό και λαμβάνει ΜΑΡΚ ακύρωσης, παύει να έχει τον αρχικό ΜΑΡΚ που είχε λάβει ή συνυπάρχουν και τα δύο;

3) Όταν θέλει ο επιχειρηματίας να ακυρώσει ένα παραστατικό από την εφαρμογή μου στο κατάστημα, ποια είναι η πιο σωστή σειρά κινήσεων; Να ακυρωθεί πρώτα στα myDATA και μετά τοπικά στο πρόγραμμα, ή ανάποδα;

4) Το classification ΜΑΡΚ, είναι πεδίο που παίρνει τιμή μόνο από τα λογιστικά προγράμματα; Η δική μου εφαρμογή για τον επιχειρηματία, έχει νόημα να το χρησιμοποιήσει κάπου;

5) Το XML που παράγεται από μια πώληση με 10 είδη, δύο διαφορετικών τύπων ΦΠΑ, πρέπει να περιλαμβάνει 10 γραμμές ή δύο μόνο με τα σύνολα αξιών συγκεντρωτικά; Στις προδιαγραφές, υπάρχει ο αριθμός γραμμής. Αφορά τη γραμμή κάθε είδους στο τιμολόγιο που δημιουργεί το εμπορικό πρόγραμμα, ή αφορά μόνο τις δύο γραμμές των διαφορετικών ΦΠΑ που είναι έτοιμες να σταλλούν στο myDATA;

6) Τα έξοδα ως αποδείξεις λιανικής (μη αντικριζόμενες), μπορεί να τις ανεβάζει το δικό μου πρόγραμμα που θα τρέχει στο κατάστημα, ή μόνο ο λογιστής του έχει δικαίωμα αυτής της αποστολής ως χρήστης;

7) Αν ισχύει το (6) για αποστολή λιανικών από την εφαρμογή μου, τα ποσά πώς πρέπει να αποστέλλονται;

Ευχαριστώ πολύ.

Καλημέρα,

1. Το πραγματικό αναγνωριστικό του κάθε παραστατικού στη βάση δεδομένων του MyDATA φαίνεται να είναι το UID. Το ΜΑΡΚ χρησιμοποιείται κατά τις κλήσεις μας όμως. Προσωπικά, αποθηκεύω και τα δύο. Εάν διαβάσετε το PDF της ΑΑΔΕ, θα δείτε ότι το UID ενδέχεται να αλλάξει για το ίδιο παραστατικό (το οποίο θα πάρει επίσης νέο ΜΑΡΚ) όταν αυτό επανα-διαβιβαστεί αλλάζοντας κάποια στοιχεία (π.χ. τον Α.Φ.Μ.). Όλα περιγράφονται στο pdf της ΑΑΔΕ.

2. Το παραστατικό που ακυρώνεται, ενδέχεται να κρατιέται στη βάση δεδομένων της ΑΑΔΕ παρά το γεγονός ότι ακυρώθηκε με ΜΑΡΚ ακύρωσης (αποδεικτικό για εσάς).

3. Σχετικό.. Εάν το παραστατικό ΔΕΝ έχει διαβιβαστεί, μπορεί να το ακυρώσει μέσα από την εφαρμογή του και μόνο, χωρίς να απαιτείται η διαβίβαση του αρχικού παραστατικού αλλά και του ακυρωτικού. Εάν όμως το αρχικό παραστατικό έχει ήδη διαβιβαστεί στο MyDATA, τότε θα πρέπει να σταλθεί σήμα ακύρωσης από την εφαρμογή στο MyDATA κατόπιν έκδοσης του ακυρωτικού σημειώματος από την εφαρμογή.

4. Δεν το γνωρίζω. Δεν το έχω χρησιμοποιήσει ποτέ.

5. 10 γραμμές με τους αντίστοιχους χαρακτηρισμούς για την κάθε μία από αυτές. Κάθε γραμμή πρέπει να υπάρχει στο xml προ της διαβίβασης. Δείτε παραδείγματα XML στην αντίστοιχη ενότητα του φόρουμ.

6. Με κάθε επιφύλαξη (υπάρχουν και πολλές "παράμετροι" που παίζουν ρόλο στο ερώτημα αυτό), θα προτιμούσα τη δεύτερη λύση (εκτός και εάν ισχύουν άλλες "παράμετροι"). Σχετικό αρκετά.

7. Δεν μπορώ να απαντήσω στο ερώτημα. Δεν υλοποιώ έξοδα προς το παρόν στη δική μου εφαρμογή. Εξ όσων όμως γνωρίζω, τα έξοδα χαρακτηρίζονται στη συντριπτική πλειοψηφία των περιπτώσεων αφού την υποχρέωση διαβίβασης την φέρει ο εκδότης. Πάλι, εξ όσων πάντα γνωρίζω (με πάσα επιφύλαξη), υπάρχουν και περιπτώσεις όπου ο λήπτης διαβιβάζει έξοδα στην περίπτωση που δεν έχει κάνει την αντίστοιχη ενέργεια ο εκδότης.

8) Οι κλήσεις α) SendIncomeClassification, β) SendExpensesClassification, γ) RequestMyIncome, δ)RequestMyExpenses, είναι λειτουργίες που αφορούν μόνο την εφαρμογή του λογιστή ή πρέπει να τις εισάγω κι εγώ στην εφαρμογή μου;

9) Επειδή στην εφαρμογή, ο χρήστης καταχωρεί αναλυτικά σε επίπεδο είδους κάθε τιμολογίου τις προμήθειες των εμπορευμάτων του (αποθήκη), πρέπει να εισάγω λειτουργία για λήψη παραστατικών που ανέβασε ο προμηθευτής του στα myDATA για αυτόν, με αξίες, ΦΠΑ, κλπ. ώστε να κάνει κάποια αντιστοίχιση ποσών με αυτά που έχει εισάγει ο ίδιος, ή αυτά πρέπει τα κάνει ΜΟΝΟ ο λογιστής του στο δικό του πρόγραμμα; Αν τα κάνει ο λογιστής του, είναι απλώς θέμα δικαιωμάτων χρήσης στα τιμολόγια αυτά και δε θα μπορεί να τα δει και ο ίδιος στο κατάστημα αν του βάλω τη λειτουργία, γιατί είναι άλλου τύπου χρήστης;

10) Μέχρι στιγμής έχω καταφέρει να κάνω αποστολή και ακύρωση τιμολογίων στο δοκιμαστικό σύστημα από την εφαρμογή μου, που είναι στην ουσία αυτή που χρησιμοποιεί στο κατάστημά του αυτός που υποστηρίζω μηχανογραφικά και τυπώνει τα τιμολόγιά του βάζοντας τα είδη που πουλάει. Μπορεί συνεπώς, να γυρίσει σε κανονική λειτουργία αν απλώς αλλάξω χρήστη και subscription key στα HTTP headers;

11) Στα HTTP headers του κανονικού συστήματος, πρέπει να εισάγεται το username, subscription key που έλαβε ο ίδιος με τους κωδικούς taxis ή πρέπει να είναι username/subkey του ΑΦΜ της εταιρείας;

Ελπίζω να μην κουράζω. Γενικά, ευχαριστώ για την ανταπόκριση, καθώς είμαι νέος στα mydata, δυστυχώς χωρίς γνωσεις λογιστικής και έτσι, με πολλά κενά και ερωτήσεις. Χρειάζεται να εισάγω κάποια άλλη λειτουργία σε μια τέτοια εφαρμογή, πέρα από αποστολή και ακύρωση τιμολογίων; Βλέποντας τις προδιαγραφές, να πω την αλήθεια, πανικοβλήθηκα λίγο για το τι πρέπει να αποστέλλεται, γιατί δεν κατάλαβα ποιες λειτουργίες πρέπει να υποστηρίζει η εφαρμογή του καταστήματος (ERP) και ποιες η εφαρμογή του λογιστή και αν υπάρχουν κάποιες που μπορούν να γίνουν από τις εφαρμογές και των δύο.

Ευχαριστώ.

8. Αναλόγως το τι παρέχει η εφαρμογή σας. Αν διαβιβάζει μόνο έσοδα, όχι. Σε άλλη περίπτωση, ναι, θα τις χρησιμοποιούσα.

9. Αυτό αφορά εσάς. Εξαρτάται τι θέλετε να παρέχει η εφαρμογή σας. Για τα έξοδα, έχω την αίσθηση ότι θα χρειαστούν κωδικοί λογιστή.

10. Ορθώς, ναι.

11. Username & subscription key τα οποία δίνονται από το Rest Api του MyDATA κατά την εγγραφή του χρήστη.

Η τελευταία παράγραφος είναι όλη η ουσία. Εσείς τι θέλετε να υλοποιήσετε είναι το ερώτημα το πραγματικό. Στη δική μου εφαρμογή, προς το παρόν, έχω εισάγει μόνο διαδικασίες που αφορούν τη διαβίβαση ΕΣΟΔΩΝ. Τα υπόλοιπα (έξοδα/χαρακτηρισμούς εξόδων) τα έχω αφήσει για το λογιστή. Είναι κυκεώνας πραγματικός τα έξοδα. Το θέμα όμως ξεκινάει από το ΣΕ ΠΟΙΟΝ απευθύνεται η κάθε εφαρμογή. Άλλος θέλει υλοποίηση όπως εγώ μόνο εσόδων, άλλος να έχει και δυνατότητες χαρακτηρισμού εξόδων μέσω κωδικών λογιστή, κλπ. Το που θα πάει η βαλίτσα που λέμε, είναι καθαρά θέμα του πλάνου που έχει κανείς στο μυαλό του.

Η εφαρμογή θα χρησιμοποιείται από χρήστη στο κατάστημα για να κόβει τιμολόγια/αποδείξεις και να καταγράφει τα έξοδα λιανικής/χονδρικής του. Γι' αυτό ρωτάω ποιες λειτουργίες δεν χρειάζονται καθόλου εδώ.

Η επιχείρηση πουλά νερά, αναψυκτικά, χαρτικά και κάνει συντήρηση σε ψύκτες που έχει πουλήσει στους πελάτες. Μπορεί σε ένα τιμολόγιο που εκτυπώνει για τον πελάτη, να έχει και χονδρική πώληση εμπορευμάτων, ταυτόχρονα με παροχή υπηρεσίας συντήρησης ή πρέπει να κόψει νέο τιμολόγιο; Αν θυμάμαι καλά, τα myDATA το δέχονται, δεν ξέρω αν λογιστικά επιτρέπεται (όπως ανέφερα δεν το 'χω μ' αυτά)

Για την πρώτη παράγραφο, όπως μου το αναφέρετε, εφόσον δεν θα κάνει χαρακτηρισμούς εξόδων, θα μπορούσε με απλή καταχώρηση παραστατικών αγορών ή και δαπανών να υλοποιηθεί η διαδικασία. Θα χρειαστείτε την ενσωμάτωση της διαδικασίας διαβίβασης ΕΣΟΔΩΝ όμως στο MyDATA.

Για τη 2η παράγραφο σας, ΝΑΙ εξ όσων γνωρίζω, το τιμολόγιο (κωδικός 1.1) επιτρέπει την πώληση εμπορευμάτων αλλά και υπηρεσιών. Με τους ανάλογους χαρακτηρισμούς ανά γραμμή βεβαίως.

Προσοχή όμως (η δική μου οπτική γωνία των πραγμάτων): Στην περίπτωση όπου για πώληση αγαθών το ΤΙΜΟΛΟΓΙΟ (1.1) το ορίσετε στην εφαρμογή να αφαιρεί απόθεμα από την αποθήκη, τότε στην περίπτωση όπου κάποιος εκδώσει Δελτίο Αποστολής αρχικά, θα πρέπει να αφαιρεθεί αρχικά το απόθεμα από την αποθήκη, κατόπιν έκδοσης του σχετικού ΤΙΜΟΛΟΓΙΟΥ (1.1) για αυτό το Δελτίο Αποστολής, θα αφαιρεθεί εκ νέου το απόθεμα.

Προσωπικά, επέλεξα το ΤΠΥ (2.1) για τις υπηρεσίες στη δική μου εφαρμογή. Με ΤΙΜΟΛΟΓΙΟ (1.1) έχω βάλει σειρές όπου ως σειρά Α έχω ορίσει να συμπεριφέρεται ως ΔΕΛΤΙΟ ΑΠΟΣΤΟΛΗΣ-ΤΙΜΟΛΟΓΙΟ π.χ., το οποίο και αφαιρεί απόθεμα στην αποθήκη. Με σειρά Β, πάλι για το 1.1 μιλάω, δεν αφαιρεί απόθεμα απόθεμα (το έχω μόνο για κάτι που λογίζεται ως εμπόρευμα/προϊόν αλλά είναι ΑΥΛΟ).

Ευχαριστώ για τα προηγούμενα.

12) Επειδή το έχω διαβάσει εδώ κι εκεί και το αναφέρεις συγκεκριμένα "Είναι κυκεώνας πραγματικός τα έξοδα", δεν μπορώ να καταλάβω τη διαφορά στην πράξη σε μια τέτοια εφαρμογή στην πλευρά του χρήση. Γιατί θεωρείται τόσο πιο δύσκολη περίπτωση η διαχείριση εξόδων (μιλάω για αυτά που δεν υποχρεούται ο εκδότης να ανεβάσει ο ίδιος, ή είναι λιανικές αγορές από το λήπτη)

13) Αν έχει αποσταλεί ένα παραστατικό στα myDATA λαμβάνοντας ΜΑΡΚ και δούμε στη συνέχεια ότι είχε λάθη, τι επιτρέπεται να αλλάξουμε σε αυτό; Το ξαναστέλνουμε βάζοντας ως συσχετιζόμενο τον ίδιο ΜΑΡΚ που έλαβε, ώστε όταν στείλουμε τα νέα στοιχεία, να μην ανέβει ως νέο; Αυτό δεν το έχω φτιάξει ακόμα, αν ισχύει.

14) Αν δεν επιτρέπεται να τοποθετήσουμε το τρέχον ΜΑΡΚ, θα λάβει νέο ΜΑΡΚ αλλά με ίδιο UID, οπότε στα myDATA λαμβάνουν υπόψη το πιο πρόσφατο; Περισσότερο ρωτάω για τη διαδικασία που ισχύει.

15) Στις εμπορικές εφαρμογές που τυπώνουν αναλυτικά τιμολόγια με τα είδη, συνηθίζεται να επιτρέπεται η επαναφορά ενός παραστατικού που ακυρώθηκε τοπικά (δεν έχει ανέβει ακόμα στα myDATA); Δεν θα αλλάζουν δηλ. τα Σειρά/Αριθμός, απλώς ένα status που θα τα θεωρεί ενεργά ή όχι, με αντίστοιχο πήγαινε-έλα των ειδών στα αποθέματα και στην πώληση.

Καλημέρα,

12. Όλα ξεκινάνε από το εάν κανείς είναι πρόθυμος να αφοσιωθεί σε κάτι, εφόσον επιθυμεί να διαθέσει το χρόνο. Τα έξοδα έχουν αρκετά περισσότερη "δουλειά" σε σχέση με τα έσοδα. Επίσης, εξ όσων γνωρίζω απαιτούν κωδικούς λογιστή. Ως freelancer, δεν μπορώ να υποκαταστήσω το ρόλο μίας εταιρείας όπου ο καθένας διατηρεί το ρόλο του. Θεωρώ ότι με το MyDATA(έσοδα) ξέφυγα αρκετά από το δικό μου ρόλο και μπήκα ήδη σε χωράφια λογιστών, δεν πρόκειται να πάω πιο πέρα όσο βέβαια ισχύουν τα σημερινά δεδομένα. Οι περιπτώσεις εξόδων είναι πολύ περισσότερες από τις αντίστοιχες εσόδων. Τα ερωτήματα του στυλ "πώς διαβιβάζεται π.χ. το ΤΕΒΕ ή τι γίνεται με αποσβέσεις και αποκλίσεις" απαιτούν συνεχή επικοινωνία με λογιστή ενώ στα έσοδα είναι σαφώς πιο καθαρό το πλαίσιο.

13. Δύο τρόποι: α) Στέλνουμε ακυρωτικό σήμα για το ΜΑΡΚ αυτό στο MyDATA και εκδίδουμε εκ νέου το παραστατικό μας. β) Στο αρχείο της ΑΑΔΕ αναφέρονται ξεκάθαρα ποιά πεδία θα επιφέρουν νέο UID (το πραγματικό ID του παραστατικού) εφόσον αλλαχτούν. Εφόσον δεν πειραχτεί κάποιο από αυτά τα πεδία και το UID δεν αλλαχτεί, κάνουμε διαβίβαση εκ νέου. ΔΕΝ υπάρχει η λειτουργία που λέτε, τα συσχετιζόμενα ΜΑΡΚ αφορούν τις περιπτώσεις όπου ένα παραστατικό συσχετίζεται με κάποιο άλλο (ΜΑΡΚ), π.χ. Πιστωτικό Τιμολόγιο - Συσχετιζόμενο, Ακυρωτικό σημείωμα κλπ.

14. Ορθώς, έτσι το αντιλαμβάνομαι και ο ίδιος.

15. Είναι θέμα εφαρμογής. Άλλος μπορεί να την έχει υλοποιήσει όπως αναφέρετε και άλλος με λιγότερες ή περισσότερες δυνατότητες. Εφόσον όλα λειτουργούν ρολόι που λέμε, δεν σας περιορίζει κανείς. Απλά (όσο μπορεί να αποκαλείται απλό), θα πρέπει να λάβετε υπόψιν όλες τις παραμέτρους ώστε να εξασφαλίσετε το ότι δε θα δημιουργηθούν προβλήματα στον τελικό χρήστη, ο οποίος με τη σειρά του θα παίρνει εσάς τηλέφωνο κάθε φορά. Είναι ένα θέμα ο όγκος και τα μεγέθη που απαιτούνται για το κάθε στάδιο υλοποίησης αλλά και υποστήριξης από πίσω. Ότι και αν έχετε στο μυαλό σας πάντως να υλοποιήσετε σχετικά, ειλικρινά εύχομαι τα καλύτερα.

13 cont. Αυτός είναι ο λόγος που ακυρωτικό επιτρέπεται μόνο την ίδια ημέρα ενώ από την επόμενη μόνο πιστωτικό; Η ημ/νία είναι μέρος του UID.

16. Στην επιχείρηση που αναφέρω με τα νερα/αναψυκτικά/χαρτικά, σε ποια περίπτωση θα πρέπει να κόψει Πιστωτικό Συσχετιζόμενο και σε ποια Πιστωτικό Μη Συσχετιζόμενο; Πριν καιρό, βρίσκοντας τυχαία έναν λογιστή, τον ρωτησα και είπε το Πιστωτικό Συσχ. το κόβεις αν θες να επιστραφεί όλη η πώληση, ενώ το μη συσχετιζόμενο, όταν π.χ. θέλει ένας πελάτης να επιστρέψει μόνο τα ελαττωματικά από αυτήν. Είναι έτσι;

17. Αν είναι έτσι, η κατηγορία 5.2 (ή ακόμη και η 5.1) κάνει το παραστατικό να συμπεριφέρεται σαν να έχει αρνητικά ποσά, παρόλο που εισάγεις θετικά;

18. Στις εμπορικές εφαρμογές, για να φτιάξεις πιστωτικά τιμολόγια (συσχετιζόμενα):
α) Πρέπει να δημιουργήσεις ένα πιστό αντίγραφο του αρχικού (INSERT SELECT FROM) για να φαίνεται ως ξεχωριστή κίνηση με άλλη Σειρά/Αριθμό,
με τα ίδια είδη (και με τον ίδιο ακριβώς αρ. γραμμής;) στο οποίο θα είναι διαφορετικός ο τύπος (αντί 1.1, ο 5.1) και να προσθέσεις το ΜΑΡΚ του αρχικού ή,
β) μπορείς να το κάνεις επάνω στην ίδια την παλιά εγγραφή (master/detail), αλλάζοντας το είδος παραστατικού και επιστρέφοντας
τα είδη στην αποθήκη; (δηλ. κάτι σαν αυτό που γράφω στο 15.)

19. Αντίστοιχα, πώς σχηματίζονται τα ακυρωτικά στο εμπορικό και στα myDATA; Δεν είδα να έχει κάποιο στα έτοιμα δείγματα στο myDATA

13. Νομιζω οτι αυτο ειναι ασχετο, θεωρω οτι ειναι καθαρα αποφαση του υπουργειου.

16. Με καθε επιφυλαξη -δεν ειμαι λογιστης-, το πιστωτικο χρησιμοποιειται για τους λογους που μπορει να αναφερονται στο πεδιο σκοπος διακινησης του παραστατικου. Ακυρωτικο χρησιμοποιειται εξ οσων γνωριζω για την περιπτωση συνολικης ακυρωσης του αρχικου παραστατικου την ιδια ομως ημερομηνια, για μεταγενεστερες ημερομηνιες χρησιμοποιουμε πιστωτικο. Ως σκοπο διακινησης μπορειτε να χρησιμοποιησετε την επιστροφη, εκπτωση κλπ. Συσχετιζομενο ή μη, η μόνη διαφορα περαν του 5.1 και του 5.2 που βλεπω εφοσον δε μου εχει διαφυγει κατι, ειναι οτι το συσχετιζομενο εμπεριεχει το ΜΑΡΚ του αρχικου παραστατικου.

17. Στο MyDATA εσοδα, δεν εχω χρησιμοποιησει ποτε αρνητικες τιμες. Λογιζονται ομως ετσι.

18α. Οχι, καμια σχεση.. Το χτιζετε ως κανονικο παραστατικο, οπως πχ και το ΤΙΜΟΛΟΓΙΟ. Το sql statement αυτο θα μπορουσε καλλιστα να χρησιμοποιηθει για αντιγραφη ενος λαραστατικου αλλαζοντας στο καινουριο παραστατικο αριθμηση, ημερομηνια κλπ.

18β. Δεν ειμαι βεβαιος οτι αντιλαμβανομαι ακριβως τι θελετε να πειτε.

19. Δεν υπαρχει XML ακυρωτικου για το MyDATA. Στελνουμε ενα μονο σημα ακυρωσης οπως σας εγραψα και πιο πανω, π.χ. CANCELINVOICE XXXXXXXXX. Οπου XXXXXXXXX ειναι το ΜΑΡΚ του αρχικου παραστατικου που θελουμε να ακυρωσουμε. Αυτο ομως δεν αναιρει την υποχρεωση της υπαρξης Ακυρωτικου σημειωματος ως record/εντυπο απο μεριας σας στην επιχειρηση ή και στη βάση δεδομένων της.

Στάλθηκε από το WP6 μου χρησιμοποιώντας Tapatalk