Δελτίο Παραγγελίας Εστίασης 8.6: ο κανόνας των 24 ωρών και η συσχέτιση με την απόδειξη

Ένα εστιατόριο δέχεται μια παραγγελία στο τραπέζι 12. Ένα λογισμικό εστίασης πρέπει να αποφασίσει τι στέλνει στο myDATA και πότε. Ένας λογιστής ρωτάει τι ακριβώς κλείνει ένα δελτίο παραγγελίας. Και οι τρεις κοιτάνε το ίδιο παραστατικό: τον τύπο 8.6, το Δελτίο Παραγγελίας Εστίασης.

Αυτή είναι όλη η ουσία, και είναι και το σημείο όπου γίνεται το λάθος. Το «έκλεισα το τραπέζι» είναι κατάσταση του λογισμικού. Η συσχέτιση είναι πράξη στο myDATA. Οι δύο καταστάσεις δεν έχουν σχέση μεταξύ τους, και μια πλατφόρμα μπορεί κάλλιστα να δείχνει οθόνη γεμάτη τακτοποιημένα κλειστά τραπέζια, με ανοιχτές φορολογικές εκκρεμότητες από κάτω.

Τι είναι το 8.6, και τι δεν είναι

Το Δελτίο Παραγγελίας Εστίασης δεν αποτελεί νόμιμο παραστατικό αξίας. Είναι ειδικό στοιχείο που φέρει σήμανση από τον πάροχο, δεν δημιουργεί πληρωτέο ποσό, και δεν αντικαθιστά την απόδειξη. Τεκμηριώνει την παραγγελία, τη στιγμή που γίνεται.

Το τι το κλείνει το ορίζει ρητά το κείμενο: συσχετίζεται με παραστατικά αξίας, δηλαδή απόδειξη λιανικής πώλησης ή πιστωτική απόδειξη λιανικής για τις λιανικές συναλλαγές, και τιμολόγιο ή πιστωτικό τιμολόγιο για τις χονδρικές. Δεν υπάρχει ξεχωριστό βήμα «κλεισίματος» στο myDATA. Η συσχέτιση είναι το κλείσιμο.

Ποιος από τους δύο δρόμους σε αφορά, λιανικής ή χονδρικής, δεν το απαντά αυτή η σελίδα. Το κείμενο ονομάζει και τους δύο, και η επιλογή εξαρτάται από τη συναλλαγή και τα βιβλία σου. Είναι κρίση του λογιστή σου.

Ο κανόνας των 24 ωρών

Τα δελτία διαβιβάζονται υποχρεωτικά στο myDATA και λαμβάνουν ΜΑΡΚ. Η συσχέτισή τους με τα παραστατικά εσόδων που τα αφορούν διενεργείται εντός είκοσι τεσσάρων ωρών από την έκδοσή τους.

Και αν δεν το αποκτήσει, το κείμενο λέει τι γίνεται. Ο πάροχος έχει την υποχρέωση να διακόψει τη διαδικασία αυθεντικοποίησης και διαβίβασης του συνόλου των δεδομένων της υπόχρεης οντότητας, μέχρι την ημερομηνία ολοκλήρωσης της συσχέτισης των ανοιχτών δελτίων.

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

Το ανοιχτό τραπέζι δεν είναι το πρόβλημα

Αυτό είναι το καθησυχαστικό μισό, και είναι εξίσου σημαντικό. Η ΑΑΔΕ απαιτεί τον Α/Α Τραπεζιού σαν πεδίο του παραστατικού, και περιγράφει το 8.6 σαν παραστατικό που περιέχει «δεδομένα διαχείρισης ανοικτών τραπεζιών». Δεν ορίζει όμως πουθενά αντικείμενο τραπεζιού, ούτε κύκλο ζωής ανοίγματος και κλεισίματος.

Το τραπέζι στο λογισμικό σου είναι δική σου διευκόλυνση. Δεν είναι φορολογική οντότητα, και ένα τραπέζι που μένει ανοιχτό δεν είναι από μόνο του παράβαση. Αυτό που μετράει είναι ένα δελτίο που έμεινε ασυσχέτιστο.

Το παράδειγμα που ακολουθεί σε όλο το άρθρο

Δύο συντελεστές ΦΠΑ στο ίδιο δελτίο επίτηδες: φαγητό στο 13% δίπλα σε ποτό στο 24% είναι η συνηθισμένη περίπτωση της εστίασης, και το κείμενο ζητάει καθαρές αξίες και ποσά ΦΠΑ ανά συντελεστή. Ένα παράδειγμα με έναν συντελεστή δεν θα σου έδειχνε τίποτα από αυτό.

Το δελτίο: τι είναι πραγματικά υποχρεωτικό στο σώμα του

{
  "invoice_type_code": "8.6",
  "billing_book_id": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "catering_table_id": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "counterpart": {
    "name": "Τραπέζι 12",
    "vat": "",
    "city": "",
    "street": "",
    "number": "",
    "postal_code": ""
  },
  "net_total_amount": 19.11,
  "vat_total_amount": 2.99,
  "total_amount": 22.10,
  "payable_total_amount": 22.10,
  "invoice_lines": [
    {
      "line_number": 1,
      "name": "Μπριάμ",
      "quantity": 2,
      "quantity_type": 1,
      "unit_price": 8.85,
      "net_total_price": 17.70,
      "vat_rate": 13,
      "vat_total": 2.30,
      "subtotal": 20.00
    },
    {
      "line_number": 2,
      "name": "Νερό 1lt",
      "quantity": 1,
      "quantity_type": 1,
      "unit_price": 1.41,
      "net_total_price": 1.41,
      "vat_rate": 24,
      "vat_total": 0.69,
      "subtotal": 2.10
    }
  ]
}

Αντικατέστησε το billing_book_id με το id της δικής σου σειράς για τύπο 8.6, από το GET /billing_books, και το catering_table_id με ένα ανοιχτό τραπέζι από τα catering_tables.

Οι γραμμές εδώ δεν κουβαλάνε χαρακτηρισμούς, και αξίζει μια πρόταση γιατί. Το δελτίο δεν είναι παραστατικό αξίας, οπότε δεν χαρακτηρίζει έσοδο. Χαρακτηρισμοί πάνω σε δελτίο δεν προκαλούν απόρριψη, περνάει καθαρό και με αυτούς. Απλώς δεν χρειάζονται. Μη γενικεύσεις όμως προς την άλλη κατεύθυνση: η απόδειξη που κλείνει το δελτίο είναι κανονικό παραστατικό εσόδου και θέλει τους δικούς της.

Η απόδειξη που το κλείνει

Η συσχέτιση γίνεται από την πλευρά της απόδειξης, με το ΜΑΡΚ του δελτίου μέσα στο correlated_invoices. Στο εκδοθέν παραστατικό εμφανίζεται σαν ΣΥΣΧ.

{
  "invoice_type_code": "11.1",
  "billing_book_id": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "payment_method_type": 3,
  "correlated_invoices": ["400001900000000"],
  "counterpart": {
    "name": "Ιδιώτης πελάτης",
    "country_code": "GR",
    "city": "ΑΘΗΝΑ",
    "street": "ΕΡΜΟΥ",
    "number": "1",
    "postal_code": "10563"
  },
  "invoice_lines": [
    {
      "line_number": 1,
      "name": "Μπριάμ",
      "quantity": 2,
      "quantity_type": 1,
      "unit_price": 8.85,
      "vat_rate": 13,
      "classification_category": "category1_1",
      "classification_type": "E3_561_003"
    },
    {
      "line_number": 2,
      "name": "Νερό 1lt",
      "quantity": 1,
      "quantity_type": 1,
      "unit_price": 1.41,
      "vat_rate": 24,
      "classification_category": "category1_1",
      "classification_type": "E3_561_003"
    }
  ]
}

Αν ο λογαριασμός πληρωθεί σε δύο αποδείξεις, το ίδιο ΜΑΡΚ μπαίνει σε καθεμία. Δεν μοιράζεται: ίδια τιμή, δύο φορές. Το κείμενο μιλάει σε πληθυντικό, για «τα παραστατικά εσόδων που αφορούν» το δελτίο, και τεχνικά δέχεται και τις δύο. Ρητή διατύπωση της ΑΑΔΕ για τον χωρισμένο λογαριασμό δεν υπάρχει, οπότε δεν σου λέμε ότι υποχρεούσαι. Η συντηρητική υλοποίηση συσχετίζει κάθε απόδειξη που κλείνει το δελτίο.

Ένα ΜΑΡΚ δεν αποδεικνύει τη συσχέτιση

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

Πρακτικά: το αρχείο του τι συσχετίστηκε πρέπει να το κρατάει το δικό σου σύστημα. Το myDATA δεν θα σου το επιστρέψει και το API δεν θα σου πει ότι αστόχησες.

Πώς βλέπεις τι είναι ακόμη ανοιχτό

{
  "invoices": [
    {
      "id": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
      "issued_at": "2026-08-25T21:45:07.739+03:00",
      "my_data_mark": "400001900000000",
      "catering_table_id": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
    }
  ],
  "total_pages": 1,
  "current_page": 1
}

Το GET /invoices/list_open_catering_order_notes είναι η μόνη ορατή εικόνα του τι μετράει αντίστροφα. Επιστρέφει τα δελτία που δεν έχουν συσχετιστεί, με την ώρα έκδοσης δίπλα στο ΜΑΡΚ, οπότε η ηλικία κάθε εκκρεμότητας είναι αφαίρεση. Αν χτίζεις ένα μόνο πράγμα πάνω από την ίδια την έκδοση, χτίσε αυτό: μια εργασία που κοιτάει τη λίστα και ειδοποιεί, αντί για έναν άνθρωπο που θυμάται να κοιτάξει.

Ακύρωση, κεράσματα και πελάτες που έφυγαν

Ένα παραστατικό που πήρε ΜΑΡΚ δεν ξεγίνεται ποτέ. Δεν τροποποιείται, δεν διαγράφεται, και κάθε προσπάθεια αλλαγής του επιστρέφει σφάλμα. Η διόρθωση είναι πάντα καινούριο παραστατικό.

{
  "billing_book_id": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "correlated_invoices": ["400001900000000"]
}

Η κλήση εκδίδει ένα νέο δελτίο 8.6 στο ίδιο τραπέζι: μία γραμμή, όλα τα ποσά μηδέν, συσχετισμένο με το αρχικό, με δικό του ΜΑΡΚ. Το αρχικό κρατάει το δικό του. Το billing_book_id είναι υποχρεωτικό και πρέπει να είναι η σειρά του 8.6. Το catering_table_id είναι προαιρετικό: αν λείπει, η πλατφόρμα το βρίσκει από το δελτίο που ακυρώνεις.

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

Τι βλέπεις όταν είναι λάθος

Η τελευταία διάκριση αξίζει τον χρόνο της. Οι δύο τελευταίες γραμμές δεν έρχονται από την ΑΑΔΕ. Ένας developer που υποθέτει ότι κάθε αποτυχία είναι myDATA θα ψάξει σε λάθος μέρος, και το μήνυμα δεν μοιάζει με τα υπόλοιπα επειδή ακριβώς δεν είναι.

Τι πρέπει να φαίνεται πάνω στο δελτίο

Τα πεδία που ορίζει το κείμενο είναι υποχρεωτικά στην έκδοση, την εκτύπωση και τη σάρωση: ΑΦΜ, επωνυμία και διεύθυνση εγκατάστασης του εκδότη, ο τύπος του παραστατικού, σειρά και αριθμός, ημερομηνία και ώρα έκδοσης, είδος, ποσότητα, καθαρές αξίες ανά συντελεστή ΦΠΑ, ποσά ΦΠΑ ανά συντελεστή, ο Α/Α Τραπεζιού, και το συνολικό ποσό της συναλλαγής.

Με μία σημαντική εξαίρεση, που φαίνεται αντιφατική και δεν είναι: το συνολικό ποσό είναι υποχρεωτικό πεδίο του παραστατικού, αλλά δεν εκτυπώνεται, ούτε του τρέχοντος σερβιρίσματος ούτε των προηγούμενων από μεταφορά. Το ποσό ταξιδεύει στα δεδομένα, δεν τυπώνεται στο χαρτί.

Πάνω από αυτά, τρία ακόμη: QR code υποχρεωτικά, που η σάρωσή του οδηγεί σε σελίδα του παρόχου, η ώρα έκδοσης ευδιάκριτη σε εμφανές σημείο με έντονη γραμματοσειρά, και το δίγλωσσο λεκτικό, αυτολεξεί:

Πού γράφεται ο κανόνας

Στο άρθρο 9 της Α.1112/2025, ΦΕΚ Β' 4206/1.8.2025, «Περιεχόμενο Τύπου Παραστατικού 8.6 Δελτίο Παραγγελίας Εστίασης». Εννέα παράγραφοι, και είναι το κείμενο σε ισχύ.

Το πλήρες κείμενο είναι δημοσιευμένο από την ΑΑΔΕ. Η επιχειρησιακή ανάλυση και η τεχνική τεκμηρίωση του τύπου 8.6 αναρτώνται από την ΑΑΔΕ στο aade.gr/mydata.

Πώς ξεκινάς

Για πρόσβαση στο staging περιβάλλον, συμπλήρωσε τη φόρμα στη σελίδα συνεργασίας μέσω API με το ΑΦΜ σου. Ο staging λογαριασμός σου δημιουργείται αυτόματα και θα επανέλθουμε άμεσα με τα credentials σου. Θα χρειαστείς σειρά τιμολόγησης για τύπο 8.6 και μία για τον τύπο της απόδειξης που κλείνει το δελτίο.

Το πλήρες σχήμα των πεδίων, μαζί με τα catering_tables και την ακύρωση, είναι στην τεκμηρίωση του REST API. Αν χτίζεις πλατφόρμα εστίασης που τιμολογεί για λογαριασμό των πελατών της, το API onboarding συνεργατών είναι το κομμάτι που δημιουργεί τους λογαριασμούς τους, και ο οδηγός για την πλατφόρμα εστίασης και τον πάροχο ΥΠΑΗΕΣ καλύπτει τη συνολική εικόνα. Οι αποδεκτές τιμές είναι στους πίνακες αναφοράς για τα είδη παραστατικών και τους τύπους χαρακτηρισμού.

Συχνές ερωτήσεις

Χρειάζεσαι βοήθεια;

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