Skip to Content

Το purchase.order στο Odoo: Κατανόηση της Αρχιτεκτονικής Purchase Order

Ολοκληρωμένος οδηγός για το μοντέλο εντολών αγοράς του Odoo — για προγραμματιστές και λειτουργικούς συμβούλους
11 Μαρτίου 2026 από
Το purchase.order στο Odoo: Κατανόηση της Αρχιτεκτονικής Purchase Order
Dasolo
| No comments yet

Εισαγωγή


Στο Odoo, τα μοντέλα καθορίζουν την «σχέση» της πληροφορίας με τη βάση δεδομένων: πώς αποθηκεύεται, με τι πεδία και πώς συνδέεται με άλλα αντικείμενα. Κάθε επιχειρησιακή οντότητα —αγορές, τιμολόγια, αποθέματα— αντιστοιχίζεται σε ένα μοντέλο που οργανώνει τα δεδομένα και τη λογική γύρω τους.


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


Εστιάζουμε εδώ σε ένα από τα πιο κρίσιμα μοντέλα του Odoo: το purchase.order. Είτε φτιάχνετε προσαρμοσμένα modules, είτε συνδέετε εξωτερικά συστήματα, είτε διαμορφώνετε προμήθειες, αυτό το μοντέλο θα είναι καθημερινή σας αναφορά.

Τι είναι το μοντέλο purchase.order


Το purchase.order αντιπροσωπεύει τις παραγγελίες προμήθειας και τα αιτήματα προσφοράς (RFQ). Είναι το σημείο όπου καταγράφονται όλες οι πληροφορίες προμήθειας —προτού γίνουν δεχτά εισερχόμενα ή τιμολόγια προμηθευτή— και από εκεί ακολουθεί η υπόλοιπη ροή procure-to-pay.


Το μοντέλο χρησιμοποιείται από το module Προμηθειών. Όταν ένας αγοραστής δημιουργεί RFQ, δημιουργείται ένα purchase.order. Με την επιβεβαίωση από προμηθευτή ή την έγκριση του αγοραστή, η κατάσταση αλλάζει από πρόχειρη σε επιβεβαιωμένη. Το ίδιο μοντέλο διαχειρίζεται τόσο τα RFQ όσο και τις τελικές παραγγελίες —η στήλη state δείχνει σε ποιο στάδιο βρίσκεται η συναλλαγή.


Άλλα modules επεκτείνουν αυτό το μοντέλο μέσω της κληρονομιάς μοντέλων του Odoo. Το απόθεμα προσθέτει λογική παραλαβών και μεταφορών, η λογιστική συνδέει πεδία τιμολόγησης και πληρωμών, ενώ η Παραγωγή μπορεί να δημιουργεί παραγγελίες από BOM. Κάθε επέκταση εμπλουτίζει τη λειτουργία χωρίς να επαναλαμβάνει την κεντρική δομή.

Κύρια πεδία του μοντέλου


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


1. name

Τύπος: Char. Αναγνωριστικό παραγγελίας (π.χ. PO00042). Συνήθως δημιουργείται αυτόματα και εμφανίζεται σε λίστες και έγγραφα. Είναι το βασικό «όνομα» με το οποίο θα ανατρέχετε στην παραγγελία.


2. state

Τύπος: Selection. Παρακολουθεί τη ζωή της παραγγελίας: draft (RFQ), sent (απεστάλη), to approve (αναμονή έγκρισης), purchase (επιβεβαιωμένη), done (παραληφθείσα & τιμολογημένη), cancel (ακυρωμένη). Η τιμή ελέγχει ποιες ενέργειες είναι διαθέσιμες.


3. partner_id

Τύπος: Many2one (res.partner). Ο προμηθευτής. Υποχρεωτικό. Χρησιμοποιείται για όλες τις λογικές vendor, επικοινωνίας και αναφορών.


4. partner_ref

Τύπος: Char. Αναφορά προμηθευτή —ο αριθμός παραγγελίας του προμηθευτή. Εμφανίζεται σε έγγραφα και βοηθά στο ταίριασμα παραλαβών και τιμολογίων.


5. date_order

Τύπος: Datetime. Η ημερομηνία της παραγγελίας. Σε πρόχειρα RFQ δείχνει την ημερομηνία δημιουργίας, σε επιβεβαιωμένες παραγγελίες την ημερομηνία επιβεβαίωσης. Χρησιμοποιείται σε αναφορές και για τις προεπιλεγμένες ημερομηνίες αναμενόμενης παράδοσης.


6. date_approve

Τύπος: Datetime. Η ημερομηνία έγκρισης/επιβεβαίωσης. Μπαίνει όταν η παραγγελία πάει σε κατάσταση purchase. Read-only —χρήσιμο για audit και αναφορές.


7. order_line

Τύπος: One2many (purchase.order.line). Οι γραμμές παραγγελίας. Κάθε γραμμή περιέχει προϊόν, ποσότητα, τιμή και φόρους —είναι η καρδιά της παραγγελίας.


8. amount_untaxed

Τύπος: Float. Το υποσύνολο πριν από τους φόρους. Υπολογίζεται από τις γραμμές παραγγελίας. Χρήσιμο για οθόνες και αναφορές.


9. amount_tax

Τύπος: Float. Το σύνολο φόρων. Υπολογίζεται από τις γραμμές σύμφωνα με τη ρύθμιση φόρων. Εμφανίζεται στην παραγγελία και στο τιμολόγιο.


10. amount_total

Τύπος: Float. Το συνολικό ποσό με φόρους. Το κύριο ποσό για τιμολόγηση και αναφορές.


11. currency_id

Τύπος: Many2one (res.currency). Το νόμισμα της συναλλαγής —συνήθως κληρονομείται από την εταιρεία ή τον προμηθευτή. Όλα τα χρηματικά πεδία συνδέονται με αυτό.


12. origin

Τύπος: Char. Πηγή παραγγελίας —π.χ. όνομα sale order όταν δημιουργείται purchase από πώληση ή από manufacturing order. Χρήσιμο για ιχνηλασιμότητα.


13. dest_address_id

Τύπος: Many2one (res.partner). Διεύθυνση παράδοσης. Αν δεν οριστεί, παίρνει προεπιλογή την εταιρική διεύθυνση. Σπουδαίο για dropshipping όπου τα αγαθά πηγαίνουν απευθείας στον πελάτη.


14. priority

Τύπος: Selection. Προτεραιότητα παραγγελίας: Normal ή Urgent. Χρησιμοποιείται για ταξινόμηση και προτεραιοποίηση ροών εργασίας.


15. invoice_status

Τύπος: Selection. Κατάσταση τιμολόγησης: no (όχι τιμολογημένη), to invoice (έτοιμη για τιμολόγηση), invoiced (πλήρως τιμολογημένη). Επηρεάζει την ορατότητα των ενεργειών δημιουργίας λογαριασμών.


16. invoice_count

Τύπος: Integer. Πόσα τιμολόγια προμηθευτή συνδέονται. Υπολογιζόμενο —διαδραστικό για άνοιγμα της λίστας τιμολογίων.


17. invoice_ids

Τύπος: One2many (account.move). Σύνδεση με λογαριασμούς προμηθευτή. Χρησιμοποιείται για τριπλό ταίριασμα (order–picking–invoice) και παρακολούθηση πληρωμών.


18. picking_ids

Τύπος: One2many (stock.picking). Σχετικές παραλαβές/αποστολές. Εμφανίζεται όταν το module Αποθέματος είναι ενεργό.


19. picking_count

Τύπος: Integer. Αριθμός σχετικών μεταφορών. Υπολογιζόμενο —γρήγορη πρόσβαση στη λίστα παραλαβών.


20. create_date

Τύπος: Datetime. Η ώρα δημιουργίας της εγγραφής. Διαχειρίζεται αυτόματα από το Odoo —χρήσιμο για αναφορές και έλεγχο αλλαγών.


21. write_date

Τύπος: Datetime. Η ώρα τελευταίας τροποποίησης. Αυτόματο —βοηθά στην παρακολούθηση ενημερώσεων.


22. notes

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


23. company_id

Τύπος: Many2one (res.company). Σε περιβάλλον πολλαπλών εταιρειών, δείχνει σε ποια εταιρεία ανήκει η παραγγελία —επηρεάζει ορατότητα και προσβάσεις.


24. user_id

Τύπος: Many2one (res.users). Ο αγοραστής ή υπεύθυνος χρήστης. Χρήσιμο για εγκρίσεις, ειδοποιήσεις και ανάθεση δραστηριοτήτων.


25. fiscal_position_id

Τύπος: Many2one (account.fiscal.position). Φορολογική θέση για αντιστοίχιση φόρων —χρήσιμη σε διασυνοριακές αγορές ή ειδικά φορολογικά καθεστώτα.


26. payment_term_id

Τύπος: Many2one (account.payment.term). Όροι πληρωμής (π.χ. Net 30). Χρησιμοποιείται στη δημιουργία τιμολογίων προμηθευτή.


27. display_name

Τύπος: Char. Υπολογιζόμενο όνομα για εμφάνιση —συνδυάζει αναγνωριστικό παραγγελίας με πληροφορίες προμηθευτή. Read-only και χρήσιμο στα dropdowns.


28. active

Τύπος: Boolean. Flag αρχειοθέτησης. Όταν False, η εγγραφή «αποθηκεύεται» χωρίς φυσική διαγραφή —διατηρείται το ιστορικό.

Πώς χρησιμοποιείται αυτό το μοντέλο στις επιχειρησιακές ροές εργασίας


1. Από RFQ σε Παραγγελία

Ο αγοραστής δημιουργεί ένα RFQ (πρόχειρο), προσθέτει γραμμές και το στέλνει στον προμηθευτή. Με επιβεβαίωση από τον προμηθευτή ή χειροκίνητη επιβεβαίωση, η εγγραφή μετατρέπεται σε επιβεβαιωμένη παραγγελία (purchase) —στο επόμενο στάδιο δημιουργούνται παραλαβές και τιμολόγια.


2. Παραλαβή από προμηθευτή

Όταν τα αγαθά φτάνουν, δημιουργείται παραλαβή (receipt) συνδεδεμένη με την παραγγελία. Οι σχετικές μεταφορές ενημερώνουν το απόθεμα και οι ποσότητες που παραλήφθηκαν ενημερώνουν το κόστος προϊόντων βάση της τιμής αγοράς.


3. Τιμολόγιο προμηθευτή

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


4. Dropshipping

Σε dropshipping, η παραγγελία προκύπτει από πώληση και το πεδίο origin δείχνει την πηγή —η dest_address_id είναι η διεύθυνση του πελάτη, ώστε ο προμηθευτής να στείλει απευθείας στον τελικό παραλήπτη. Το purchase.order λειτουργεί ως γέφυρα ανάμεσα σε πωλήσεις και προμήθειες.



5. Παραγωγή και MRP

Όταν μια εντολή παραγωγής χρειάζεται πρώτες ύλες, μπορεί να δημιουργήσει purchase.orders για τα υλικά. Το origin συνδέει την παραγγελία με την εντολή παραγωγής. Το μοντέλο είναι κρίσιμο στην αλυσίδα procure-to-pay και στον συντονισμό MRP–προμηθειών.

Πώς το επεκτείνουν οι προγραμματιστές


Οι προγραμματιστές επεκτείνουν το purchase.order με διάφορα μοτίβα. Η κληρονομιά μοντέλων του Odoo είναι το βασικό εργαλείο για προσαρμογές.


Κληρονομιά Μοντέλου

Χρησιμοποιήστε _inherit = 'purchase.order' για να προσθέσετε πεδία, να επαναγράψετε μεθόδους ή να ορίσετε νέους περιορισμούς. Η επέκταση γίνεται σε ξεχωριστό module ώστε να διατηρείται οργανωμένη και εύκολη σε αναβαθμίσεις.


Προσθήκη Πεδίων

Προσθέστε νέα πεδία στο κληρονομημένο μοντέλο με τον κατάλληλο τύπο: Char, Many2one, Boolean, Integer, Text, Selection. Σε περιβάλλον πολλαπλών εταιρειών, σκεφτείτε πεδία εξαρτώμενα από εταιρεία.


Επεκτάσεις σε Python

Μπορείτε να επαναγράψετε μεθόδους όπως button_confirm, create ή write για να προσθέσετε λογική —πάντα καλώντας super() όπου χρειάζεται. Προσέξτε τις εξαρτήσεις σε υπολογιζόμενα πεδία και τα triggers τους.


Odoo Studio

Το Odoo Studio επιτρέπει την προσθήκη πεδίων χωρίς γραφή κώδικα —ιδανικό για γρήγορες ρυθμίσεις. Για πιο σύνθετη λογική ή έργα με διάρκεια και αναβαθμίσεις, προτιμήστε custom modules. Το API του Odoo (XML-RPC / JSON-RPC) εκθέτει πλήρως το μοντέλο purchase.order για ενσωματώσεις.

Καλές πρακτικές


  • Χρησιμοποιήστε την κατάλληλη κατάσταση (state) για κάθε στάδιο της ροής. Μην παρακάμπτετε τα στάδια επιβεβαίωσης ή έγκρισης.
  • Καταγράψτε το partner_ref όταν ο προμηθευτής δίνει δικό του αριθμό παραγγελίας —βοηθά σημαντικά στο ταίριασμα τιμολογίων και αποστολών.
  • Χρησιμοποιείτε το origin για ιχνηλασιμότητα —αναγκαίο σε σενάρια dropshipping και σύνδεσης με παραγωγή.
  • Σε integrations API, χρησιμοποιήστε XML-RPC ή JSON-RPC και χαρτογραφήστε προσεκτικά τα εξωτερικά IDs για αποφυγή διπλοεγγραφών.
  • Για προσαρμοσμένα πεδία, χρησιμοποιήστε πρόθεμα x_ ή το πρόθεμα του module σας ώστε να αποφύγετε συγκρούσεις με μελλοντικές εκδόσεις του Odoo.

Συνηθισμένα λάθη


  • Τροποποίηση επιβεβαιωμένων παραγγελιών χωρίς έλεγχο κατάστασης. Οι επιβεβαιωμένες παραγγελίες έχουν περιορισμένα πεδία —ακολουθήστε τις σωστές ροές ή δημιουργήστε νέα παραγγελία αν χρειάζεται.
  • Μπερδεμένο partner_id με dest_address_id. Το πρώτο είναι ο προμηθευτής· το δεύτερο το σημείο παράδοσης (συχνά πελάτης σε dropshipping).
  • Επαναγραφή του button_confirm χωρίς να καλείται το super(). Αυτό μπορεί να σπάσει λειτουργίες άλλων modules ή να δυσκολέψει αναβαθμίσεις.
  • Προσθήκη υποχρεωτικών custom πεδίων χωρίς default τιμές. Αυτό θα προκαλέσει σφάλματα σε παλιές εγγραφές κατά αναβάθμιση.
  • Ξεχασμός να οριστεί το currency_id σε πολυνομισματικό περιβάλλον. Λανθασμένο νόμισμα οδηγεί σε λάθος κόστη και τιμολόγηση.

Συμπέρασμα


Το purchase.order είναι ο πυρήνας του module Αγορών στο Odoo: αποθηκεύει RFQ και επιβεβαιωμένες παραγγελίες. Η γνώση των πεδίων και του τρόπου επέκτασης διευκολύνει τη διαμόρφωση, την παραμετροποίηση και τις ενσωματώσεις.


Είτε είστε functional consultant που χαρτογραφεί διαδικασίες προμηθειών είτε developer που υλοποιεί custom λογική, μια ισχυρή κατανόηση του purchase.order εξοικονομεί χρόνο και μειώνει λάθη.

Χρειάζεστε βοήθεια με την υλοποίηση του Odoo;


Η Dasolo συνεργάζεται με επιχειρήσεις για την υλοποίηση, παραμετροποίηση και βελτιστοποίηση του Odoo. Ειδικευόμαστε σε integrations και ανάπτυξη, με βαθιά γνώση της δομής δεδομένων και μοντέλων όπως το purchase.order.


Αν χρειάζεστε βοήθεια για υλοποίηση Odoo, δημιουργία custom modules ή ενσωματώσεις, μπορούμε να αναλάβουμε το project και να σας καθοδηγήσουμε. Κλείστε μια επίδειξη για να συζητήσουμε το έργο σας.

Το purchase.order στο Odoo: Κατανόηση της Αρχιτεκτονικής Purchase Order
Dasolo 11 Μαρτίου 2026
Share this post
Σύνδεση to leave a comment