1) Χαρακτηρισμός εξόδων πρέπει να ακολουθεί τις εγγραφές του Προμηθευτή - 2) Τι γίνεται όταν ο ΦΠΑ δεν εκπίπτει.

1) Απότι διαπίστωσα στον χαρακτηρισμό του εξόδου από Προμηθευτή πρέπει ΑΠΑΡΑΙΤΗΤΑ να δημιουργήσεις ίσες details όσες και το λογισμικό του προμηθευτή ανεξάρτητα από τις λογιστικές σου εγγραφές. Ανά συντελεστή ΦΠΑ το καταλαβαίνω (αν και πολλοί λογιστές ένα τιμολόγιο SuperMarket με 2 συντελεστές ΦΠΑ το πέρναγαν σε ένα λογ/σμό δαπανών). Ανά κατηγορία αγαθού ή υπηρεσίας όμως ποιός ο λόγος, θα έπρεπε ο έλεγχος να γίνεται το πολύ ανά ΦΠΑ. Π.χ. ο προμηθευτής πουλάει και δικά του προιόντα (στο 13 & 24%) και εμπορεύματα (24%) άρα δημιουργεί 3 details. Από την πλευρά μου τα περνάω όλα ως εμπορεύματα (ανά συντελεστή ΦΠΑ), άρα 2 details. Αυτό χτυπάει και σαφώς η αιτιολογία είναι "All invoice rows should have expensesclassifications". Αρα δημιουργείται εδώ θέμα με την λογιστική καταχώρηση του παραστατικού! 2) Στην περίπτωση τιμολογίου (π.χ. βενζίνης) όπου δεν εκπίπτουμε τον ΦΠΑ, στην αξία βάζουμε την καθαρή (όπως και στην παλιά ΜΥΦ) ή το σύνολο με το ΦΠΑ? Αν βάλουμε την καθαρή για να συμφωνεί ως προς την διασταύρωση, τότε στο Ε3 θα καταχωρηθεί μόνο η καθαρή αξία!

Attachments

Comments

  •  
    Ως προς το 2ο σκέλος στην αξία βάζουμε την καθαρή. ΦΠΑ δεν ενημερώνουμε γιατι δεν εκπίπτει (εννοώ δεν στέλνουμε αξία με VAT_361). Για το Ε3 (E3_585_ΧΧΧ) στέλνουμε την Καθαρή + το ΦΠΑ (Το ΦΠΑ είναι εξοδο για εμας που δεν το εκπίπτουμε). Οσο για το 1ο σκέλος έχεις απόλυτο δίκαιο. Δεν έχω κάνει δοκιμές με αποστολή χαρακτηρισμών εξόδων ακόμα αλλά έχει αναφερθεί αν θυμάμαι και σε αλλα post οτι τι σημασία έχει το τι χαρακτηρισμούς στέλνει ο Εκδότης γιατι οταν λαμβάνουμε τις συνόψεις αγορών - εξόδων λαμβάνουμε ακριβώς οτι έχει στείλει ο Εκδότης. Θα έπρεπε να λαμβάνουμε τα σύνολα ανα ΦΠΑ.
    Posted by Hidden Thu, 30 Jul 2020 21:18:46 GMT
  •  
    Συνάδελφε σε ευχαριστώ για την γρήγορη απάντηση. Εχεις απόλυτο δίκιο όσον αφορά το έξοδο που δεν εκπίπτει. Είχα μία αμφιβολία μήπως χτύπαγε ασυμφωνία μεταξύ του ληφθέντος παραστατικού που ο προμηθευτής εκπίπτει τον ΦΠΑ (χωριστά καθαρή αξία & ΦΠΑ), ενώ εμείς το περνάμε ολόκληρο το ποσό. Το δοκίμασα όπως είπες και χωρίς 2η εγγραφή στο VAT_361 και success! Αναμένουμε λοιπόν τι θα γίνει με το 1ο θέμα!
    Posted by Hidden Thu, 30 Jul 2020 23:18:25 GMT
  •  
    Συναδελφοι πολυ ευστοχη η παρατηρηση σας.Ειδικα το 1ο σκελος με το πληθος των details ειναι critical. Προκειται για καραμπινατη κακη σχεδιαση.Καλο θα ειναι να εχουμε μια ενημερωση απο την ΑΑΔΕ.
    Posted by Hidden Fri, 31 Jul 2020 07:03:19 GMT
  •  
    Πολύ σωστό αυτό που λές συνάδελφε, πολλοι λογιστες περνάνε ολο το τιμολογιο σε ένα λογαριασμο δαπανων. Προσεξτε τωρα τι γινεται: Ενω στην περιοδικη ΦΠΑ τα ποσα του εκπιπτωμενου ΦΠΑ δεν πανε ανα % ΦΠΑ (381-387) , ερχετε τωρα το MyDATA με αυτη την αστοχη θα λέγαμε διασταυρωση ανα linenumber και σου λεει οτι θελει χαρακτηρισμο ανα ΦΠΑ. Η διασταυρωση ανα linenumber πρέπει να αντικαταστατθει σε διασταυρωση σε επιπεδο summaries. οι κανονες ειναι απλοι (1) [ΚΑΘ.ΑΞΙΑ ΛΗΤΗ] + [ΑΞΙΑ ΦΠΑ ΛΗΠΤΗ αν υπαρχει] + [ΠΡΟΣΘΕΤΙΚΟΙ φόροι ΛΗΠΤΗ] ΜΙΚΡΟΤΕΡΟ Η ΙΣΟ ΜΕ [ΚΑΘ.ΑΞΙΑ ΕΚΔ] + [ΑΞΙΑ ΦΠΑ ΕΚΔ] + [ΠΡΟΣΘΕΤΙΚΟΙ φόροι ΕΚΔ] και (2) [ΣΥΝ ΑΞΙΑ ΛΗΠΤΗ] = [ΣΥΝ ΑΞΙΑ ΕΚΔ] . (3) Τυχον αφαιρετικοι φοροι δεν συμμετεχουν. Και γεμιζουμε και τα προγραμματα με ένα καρο αχρηστο κώδικα
    Posted by Hidden Fri, 31 Jul 2020 08:47:42 GMT
  •  
    Μαλλον δεν υπάρχει θεμα αν to grouping ειναι ανα vatcategory , classificationType , classificationCategory. Παντα θα εχoυν και ο προμηθευτης και ο πελατης τοσα line numbers οσα ειναι και τα vatcategory. Δεν εχω δοκιμασεις αποστολη με επαναληψη καποιου vatcategory ξεχωριστα πχ για τα εμπορευματα και ξεχωριστα για τα προιοντα. Κανονικα θα πρεπει να αποριπτεται.Οσο για τους λογιστες θα περνανε τα εξοδα με το ΦΠΑ τους.Δεν ειναι και τοσο τρομερο
    Posted by Hidden Fri, 31 Jul 2020 11:37:44 GMT
  •  
    Μας αναγκάζει να γράψουμε ατέλειωτες γραμμές κώδικα ...τζάμπα , στην κυριλεξία... Γιατι επιμένουν σε κάτι που είναι λάθος??
    Posted by Hidden Fri, 31 Jul 2020 12:21:26 GMT
  •  
    Μα γιατι πιστευεις οτι ειναι λαθος και γιατι πιστευεις οτι γραφεις τζαμπα κωδικα.Οτιδηποτε τους στελνεις το χρειαζονται. Μια πλατφορμα που θα ενημερωνεται απο ολα τα μαγαζια της χωρας και μελλοντικο της ΕΕ απο εμπορικες εφαρμογες , απο λογιστικες εφαρμογες μια πλατφορμα με δυνατοτηες να φορτωνει απο αποδειξεις λιανικής μεχρι προβλεψεις και αποσβεσεις παγιων μια πλατφορμα που ενημερωνει ε3 και φ2 δεν θα ειναι αρκετα απαιτητικη.Προφανως το εχουν μελετησει το θεμα και το εχουν μελετησει καλα. Τα XML τους ειναι απλα και εξυπνα.Ειχα δουλεψει παλιοτερα τα CDA της ηλεκτρονικης συνταγογραφησης της ΗΔΙΚΑ και ειχα καραφλιασει. Πιστεψε με αυτοι εδω ειναι χρονια μπροστα απλα θελουν το χρονο τους το πακετο ειναι δυσκολο και απαιτητικο.
    Posted by Hidden Fri, 31 Jul 2020 13:03:55 GMT
  •  
    Φιλε μου δεν έχει νόημα να χαρακτηρίζεις ανα linenumber. Τζάμπα δουλεια, ανούσιες πληροφοριες, τη στιγμη που ο έλεγχος μπορει να γινεται με ασφάλεια οπως περιγραφεται στο 08:47:42 GMT. χωριες loopες , και με ελάχιστες γραμμες κώδικα.. Τωρα, αν το βρισκεις λογικο να το πηγαίνουμε Πετραλωνα-Παγκρατι μέσω Λαμιας... εεεε τι να σου πω..
    Posted by Hidden Fri, 31 Jul 2020 13:17:08 GMT
  •  
    Συνάδελφοι σας ευχαριστώ για τα σχόλια σας (είμαι ο αρχικός poster). Η άποψη μου όμως δεν αλλάζει μετά από εμπειρία 33+ χρόνων στα εμπορικά-λογιστικά προγράμματα και μάλιστα προερχόμενος με αρχικό πτυχίο της Αν.Βιομ.Σχολής Θεσ/κης (νυν Πανεπιστήμιο Μακεδονίας). Ιδιαίτερα το θέμα απεικόνισης των χαρακτηρισμών όχι μόνο ανά συντ.ΦΠΑ αλλά και ανά χαρακτηρισμό εσόδου του εκδότη με βρίσκει απόλυτα αντίθετο. Θα συμφωνήσω όμως ως προς τον τζάμπα κώδικα, το θέμα αυτό δεν λύνεται με επιπλέον κώδικα αλλά με επιπλέον εγγραφές χρησιμοποιώντας αναγκαστικά διαφορετικούς λογ/σμούς (στο παράδειγμα μου άλλον για τα Εμπορεύματα και άλλον για τα Προιόντα 24%).
    Posted by Hidden Fri, 31 Jul 2020 13:24:17 GMT
  •  
    Συναδελφε αν εισαι ο ληπτης πως θα ξερεις τι ειναι εμπορευμα και τι προιον.Τα προιοντα του εκδοτη ειναι εμπορευματα για σενα.Επισης δεν εχω δει πουθενα καποιο πινακα συσχετισμων μεταξυ των Classifications του εκδοτη και ρου ληπτη.Η αισθηση που εχω ειναι οτι το μονο που ελεγχεται ειναι το ΦΠΑ ανα συντελεστη και τιποτα αλλο.Με επιφυλαξη ολα αυτα που γραφω.Ας μας πει το mYDATA τι γινεται.
    Posted by Hidden Fri, 31 Jul 2020 13:43:28 GMT
  •  
    Fri, 31 Jul 2020 08:47:42 GMT Αγαπητε συναδελφε νομιζω οτι ειμασατε σε ενα τεχνικο Forum και προσπαθουμε να βοηθηθουμε λιγο να φτιαξουμε τα προγραμματα μας πανω στις προδιαγραφες που μας εχουνε δωσει.Το να παρουσιαζουμε δικες μας εκδοχες αναλυσης και να διαμαρτυρωμαστε γιατι δεν μας αρεσει το Detail ή το Summary ειναι αντιπαραγωγικο και δεν βοηθαει σε τιποτα.
    Posted by Hidden Fri, 31 Jul 2020 14:01:04 GMT
  •  
    Συνάδελφε του post Fri, 31 Jul 2020 13:43:28 GMT, ακριβώς αυτό λέω. Δυστυχώς όμως όπως ανέφερα απορρίπτεται η εγγραφή αν κάνεις διαχωρισμό μόνο ανά ΦΠΑ, εφόσον ο εκδότης έχει ποστάρει χωριστές εγγραφές για προιόντα και εμπορεύματα πρέπει να ακολουθήσεις το ίδιο, 3 εγγραφές ο εκδότης 3 και εσύ (προιόντα 13 & 24% και εμπορεύματα 24%).
    Posted by Hidden Fri, 31 Jul 2020 14:02:34 GMT
  •  
    Δυο εγγραφες πρεπει να ποσταρει ο εκδοτης 13 και 24 με τα αντιστοιχα Classifications απο κατω για εμπορευματα και προιοντα. Δυο εγγραφες και ο ληπτης 13 και 24 για εμπορευματα
    Posted by Hidden Fri, 31 Jul 2020 14:10:34 GMT
  •  
    Συνάδελφε Fri, 31 Jul 2020 08:47:42 GMT είσαι εκτός θέματος, εδώ το πρόβλημα δεν αφορά εμάς και είναι απόλυτα συγκεκριμένο, αφορά τους λογιστές που θα πρέπει ανάλογα με το πως καταχωρείται το παραστατικό (δηλαδή ανά είδος για μεταπώληση σε περίπτωση super market ή ως δαπάνη συγκεντρωτικά) να διαχωρίσουν την κατηγορία των αγαθών (για τον λήπτη εμπορεύματα) με βάσει την κατηγοριοποίηση του εκδότη.
    Posted by Hidden Fri, 31 Jul 2020 14:11:47 GMT
  •  
    Συνάδελφε Fri, 31 Jul 2020 14:10:34 GMT αυτό που λες έχει βάση, θα το δοκιμάσω να δω αν περνάει. Βέβαια προυποθέτει ότι και το λογισμικό του εκδότη έχει ακολουθήσει αυτόν τον τρόπο εγγραφής!
    Posted by Hidden Fri, 31 Jul 2020 14:16:31 GMT
  •  
    Fri, 31 Jul 2020 14:10:34 GM δεν το εχω δοκιμασει αλλα κανονικα δεν θα πρεπει να επιτρεπεται η επαναλυψη ενος vatcategory στο detail.Αν εχεις χρονο και δυνατοτητα δοκιμασετο και ενημερωσε μας.
    Posted by Hidden Fri, 31 Jul 2020 14:21:28 GMT
  •  
    Fri, 31 Jul 2020 14:11:47 GMT Οι λογιστες αγαπητε συναδελφε θα εχουν τα προβληματακια τους.Αν παρακολουθεις την κουβεντα που εχουμε ισωσ βγαλεις ακρη.Εγω βασικα υποστηριζω οτι η μονη διασταυρωση που ειναι εφικτη ειναι το ΦΠΑ.Αν to super market εχει 13 και 24 τοτε ειτε τα περασεις σαν εμπορευματα ειτε σαν δαπανη θα πρεπει να τα περασεις με 13 και 24 φπα.Ιδωμεν
    Posted by Hidden Fri, 31 Jul 2020 14:41:11 GMT
  •  
    Η μόνη λύση ετσι πως το διαβαζω είναι να μας εκδιδουν ξεχωριστά τιμολόγια για τα προιόντα και ξεχωριστά τιμολόγια για τα εμπορεύματα !
    Posted by Hidden Fri, 31 Jul 2020 14:55:39 GMT
  •  
    Η μονη λυση ειναι να μας η ΑΑΔΕ πως το διαχειριζεται
    Posted by Hidden Fri, 31 Jul 2020 14:59:22 GMT
  •  
    Είμαι ο αρχικός poster. Λοιπόν κύριοι η μόνη λύση (και δείχνει και περνάει σωστά) είναι αυτή που πρότεινε ο Fri, 31 Jul 2020 14:10:34 GMT. Δηλαδή όταν έχουμε 2 κατηγορίες αγαθών με ίδιο συντελεστή ΦΠΑ να μην γράφουμε 2 lines αλλά μία με 2 classifications. Με αυτό τον τρόπο, δηλαδή αρχικό grouping ανά ΦΠΑ και εσωτερικά ανά classification, μπορεί να γίνει και ο χαρακτηρισμός ανά ΦΠΑ από την πλευρά του λήπτη και με ένα classification. Το δέχεται κανονικά. Παραθέτω παράδειγμα Invoice εκδότη και Classification λήπτη. Το θέμα είναι βέβαια ότι μέχρι στιγμής,΄για να απαντήσω και στον poster Fri, 31 Jul 2020 14:21:28 GMT, ο έλεγχος επιτρέπει να γίνονται περισσότερες από μία εγγραφή ανά ΦΠΑ, άρα θα πρέπει αυτό να αλλάξει ώστε να ακολουθούν όλα τα λογισμικά αυτόν τον κανόνα!
    Posted by Hidden Fri, 31 Jul 2020 16:30:07 GMT
  •  
    Μπραβο συναδελφε επιτελους κατι παραγωγικο σημερα.Στα περισοτερα threads που εχω μπει πεφτει γκρινια.Η ΑΑΔΕ φανταζομαι μας διαβαζει οποτε θα κανει τα απαραιτητα.
    Posted by Hidden Fri, 31 Jul 2020 16:55:25 GMT
  •  
    Θα ηθελα και γω με την σειρά μου να ευχαριστήσω ολους όσους έγραψαν σε αυτό το θέμα. Αναδεικνύεται οτι ολοι μαζύ μπορούμε να λύσουμε τις απορίες και τα θέματα που δημιουργούνται απο τις δοκιμές που κάνουμε και να βρούμε λύσεις. Σαφώς απο τα παραδείματα που πέσανε στο forum φάνηκε οτι θέλει group κατα ΦΠΑ και μετά εσωτερικά group κατά ΦΠΑ και classifications. Είχα ποστάρει τέτοιο παράδειγμα στο https://mydata-dev.portal.azure-api.net/issues/5f14616ac7573029fc6a9a9f αλλά είχα Εμπορεύματα - Υπηρεσίες στο 24 και Προιόντα στο 13.
    Posted by Hidden Fri, 31 Jul 2020 17:41:45 GMT
  •  
    Επειδή θεωρώ πολύ σοβαρό το συμπέρασμα απο αυτό τα Post το ξαναδημοσιεύω σε νέο Post ωστε να το διαβάσουν ΟΛΟΙ και φυσικά να ενημερωθούν γιατί θα το βρούμε ΜΠΡΟΣΤΑ ΜΑΣ !
    Posted by Hidden Fri, 31 Jul 2020 19:04:19 GMT
  •  
    Πολύ σωστά συνάδελφε Fri, 31 Jul 2020 17:41:45 GMT η αλήθεια είναι ότι έτσι το είχα στο νου μου, είχα δει και το παράδειγμα σου, απλά μου ήταν πιο εύκολο στον κώδικα κάνοντας στον SQL το αρχικό grouping ανά ΦΠΑ & χαρακτηρισμό να δημιουργώ ισάριθμες εγγραφές (3), ενώ τώρα χρειαζόταν και μία επεξεργασία στο loop :) Ευχαριστώ για την αναδημοσίευση. Πάντα με την επιφύλαξη βέβαια ότι η ΑΑΔΕ θα το λάβει υπόψη και θα μπλοκάρει εγγραφές με ίδιο συντελεστή ΦΠΑ, διότι βλέπω με το νέο xsd να προσανατολίζονται σε αναλυτικές εγγραφές ανά είδος!
    Posted by Hidden Sat, 01 Aug 2020 13:43:23 GMT
  •  
    Δεν νομίζω οτι θα απαιτήσουν τόσο γρήγορα αναλυτικές εγγραφές ανά είδος. Μπορεί να το δούμε δοκιμαστικά σαν myDATA version 2 αλλά επειδή έχει αργήσει να ξεκινήσει το myDATA νομίζω οτι θα ξεκινήσει με version 1. Πάντως απ οτι έχω ακούσει και διαβάσει υπάρχουν αντιρήσεις με ουσιαστικά επιχειρήματα για την αναδρομική αποστολή όλου του 2020. Τεχνικά θα σου αναφέρω οτι εμένα με βγηκε με 3 query. Το 1ο ανα ΦΠΑ , το 2ο ανα ΦΠΑ - χαρακτηρισμό - τύπο. Οταν επεξεργάζομαι το 1o με το ΦΠΑ βαζω filter στο 2ο ωστε να αναγραφούν σωστά οι χαρακτηρισμοί και οι τύποι απο το 2ο QUERY (αυτά που ανήκουν στο τρέχον ΦΠΑ). Τέλος ένα 3ο για τα σύνολα των χαρακτηρισμών και τύπων που αναφέρονται στο τέλος του παραστατικού. Το 3ο query είναι απαραίτητο γιατι είχε τύχει σε διαφορετικά ΦΠΑ να συμπέσει ιδιος χαρακτηρισμός και τύπος και εκεί εμφανίζει λάθος ( δεν βόλευε να τα παρω απο το 2ο ). Και μία ερώτηση την ευρεση απο το είδος αποθήκης του χαρακτηρισμού και του τύπου πως την έχεις υλοποιήσει ? με sql function η παραμετρικά με δομη σε sql πίνακα ? . Αμφιταλαντεύομαι μεταξύ των 2 λύσεων. Επίσης σε τι περιβάλον έχεις αναπτύξει την λύση ? Είμαι ο 31 Jul 2020 17:41:45 ( ή Γιώργος !) Το email μου geoatan@gmail.com
    Posted by Hidden Sat, 01 Aug 2020 22:03:10 GMT
  •  
    Μπορεί να μου εξηγήσει κάποιος συνάδελφος το υποτιθέμενο όφελος από την αναλυτική αποστολή εγγραφών ανα είδος?
    Posted by Hidden Sun, 02 Aug 2020 14:33:59 GMT
  •  
    Καλησπέρα σας, Η ενδεδειγμένη λύση σε περίπτωση που υποβάλλετε το παραστατικό είναι η τελευταία, δλδ μια γραμμή ανά ΦΠΑ και όσες γραμμές χαρακτηρισμών χρειάζονται υπό αυτή. Προκειμένου το grouping των γραμμών της σύνοψης να γίνεται όσο το δυνατό μόνο λόγω κατηγοριοποίησης του ΦΠΑ και όχι λόγω άλλων λοιπών φόρων (κατηγοριοποίηση η οποία δεν αφορά των λήπτη), οι λοιποί φόροι μπορούν να συμπεριλαμβάνονται στο section TaxesTotals και έτσι να υπάρχουν τότσες γραμμές μόνο όσες είναι και οι κατηγορίες ΦΠΑ Ωστόσο σε κάθε περίπτωση εάν είστε λήπτης το πλήθος των γραμμών εξαρτάται από τον τρόπο με τον οποίο υπέβαλλε το παραστατικό ο εκδότης καθώς το line matching είναι απαραίτητο για την διενέργεια ελέγχων. Ευχαριστούμε, Ομάδα Development REST API MyData
    Posted by Hidden Mon, 03 Aug 2020 11:37:30 GMT


You're not signed in. Please sign-in to report an issue or post a comment.