Εισαγωγή
Στο Odoo, τα μοντέλα καθορίζουν τη δομή και την αποθήκευση των δεδομένων στη βάση. Κάθε στοιχείο business—από παραγγελίες πώλησης μέχρι τιμολόγια και επαφές—αποθηκεύεται σε συγκεκριμένο μοντέλο.
Η γνώση των μοντέλων του Odoo είναι απαραίτητη τόσο για προγραμματιστές όσο και για συμβούλους λειτουργίας. Τα μοντέλα αποτελούν τη ραχοκοκαλιά της αρχιτεκτονικής δεδομένων: ορίζουν πεδία, σχέσεις και επιχειρησιακή λογική.
Το κείμενο αυτό εστιάζει στο μοντέλο sales.order —ένα από τα πιο κρίσιμα στο Odoo. Είτε φτιάχνετε προσαρμοσμένες εφαρμογές, είτε ενώνετε συστήματα τρίτων, είτε ρυθμίζετε ροές πωλήσεων, θα δουλέψετε με αυτό το μοντέλο.
Τι είναι το μοντέλο sales.order
Το sales.order αναπαριστά προσφορές και παραγγελίες πώλησης. Είναι το σημείο όπου καταχωρούνται οι συναλλαγές πώλησης πριν μετατραπούν σε τιμολόγια ή αποστολές.
Αυτό το μοντέλο χρησιμοποιείται κυρίως από το εφαρμογίδιο Πωλήσεις (Sales) στο Odoo.
Η τυπική ροή: ο πωλητής δημιουργεί μια προσφορά (draft). Όταν ο πελάτης επιβεβαιώσει, το record μεταφέρεται σε κατάσταση confirmed. Το ίδιο μοντέλο διατηρεί τόσο προσφορές όσο και επιβεβαιωμένες παραγγελίες —το πεδίο state παρακολουθεί την εξέλιξη.
Άλλα modules επεκτείνουν το sales.order μέσω της κληρονομικότητας μοντέλου. Το CRM συνδέει ευκαιρίες με παραγγελίες, η Λογιστική προσθέτει πεδία τιμολόγησης και το Αποθηκευτικό σύστημα προσθέτει ημερομηνίες παράδοσης. Κάθε module προσθέτει τις ανάγκες του χωρίς να αναπαράγει τον πυρήνα.
Κύρια πεδία του μοντέλου
Παρακάτω παρουσιάζονται τα πιο σημαντικά πεδία του sales.order. Κατανοώντας τα, θα χειρίζεστε πιο αποτελεσματικά προσφορές και παραγγελίες.
1. name
Τύπος: Char. Αποθηκεύει το αναγνωριστικό της παραγγελίας ή τον αριθμό προσφοράς. Συνήθως παράγεται αυτόματα (π.χ. SO00042) και εμφανίζεται στις λίστες και τα έγγραφα. Λειτουργεί ως η βασική ταυτότητα της παραγγελίας.
2. state
Τύπος: Selection. Καταγράφει τη φάση της παραγγελίας. Τυπικές τιμές: draft (προσφορά), sent (αποσταλμένη), sale (επιβεβαιωμένη), done (ολοκληρωμένη), cancel (ακυρωμένη). Η κατάσταση καθορίζει ποιες ενέργειες είναι διαθέσιμες.
3. partner_id
Τύπος: Many2one (res.partner). Ο πελάτης. Υποχρεωτικό. Πρόκειται για την κύρια επαφή ή εταιρεία της παραγγελίας και χρησιμοποιείται σε όλη τη λογική πελατειακής ροής και αναφορών.
4. partner_invoice_id
Τύπος: Many2one (res.partner). Η διεύθυνση τιμολόγησης. Αν δεν οριστεί, παίρνει την τιμή από partner_id. Χρήσιμο όταν ο λογαριασμός εκδίδεται σε άλλη οντότητα (π.χ. κεντρική χρέωση).
5. partner_shipping_id
Τύπος: Many2one (res.partner). Η διεύθυνση παράδοσης. Αν δεν οριστεί, προεπιλογή είναι το partner_id. Χρησιμοποιείται για δημιουργία παραστατικών αποστολής και υπολογισμό κόστους μεταφοράς.
6. user_id
Τύπος: Many2one (res.users). Ο υπεύθυνος/πωλητής. Χρησιμοποιείται για CRM, υπολογισμό προμηθειών και ανάθεση δραστηριοτήτων. Συνήθως προέρχεται από την ομάδα πωλήσεων ή την ευκαιρία.
7. team_id
Τύπος: Many2one (crm.team). Η ομάδα πωλήσεων. Ομαδοποιεί πωλητές και επηρεάζει τα reports και τους στόχους.
8. date_order
Τύπος: Datetime. Η ημερομηνία της παραγγελίας. Σε προσφορές αντιστοιχεί στην ημερομηνία δημιουργίας, σε επιβεβαιωμένες παραγγελίες στην ημερομηνία επιβεβαίωσης. Χρήσιμο για φιλτράρισμα και αναφορές.
9. validity_date
Τύπος: Date. Η ημερομηνία λήξης της προσφοράς. Μετά από αυτήν η προσφορά θεωρείται άκυρη —χρήσιμο για περιορισμένες χρονικά προσφορές.
10. commitment_date
Τύπος: Datetime. Η ημερομηνία δέσμευσης παράδοσης προς τον πελάτη. Όταν οριστεί, οι παραγγελίες αποστολής προγραμματίζονται γύρω από αυτή την ημερομηνία αντί για τους χρόνους παράδοσης προϊόντων.
11. order_line
Τύπος: One2many (sale.order.line). Οι γραμμές της παραγγελίας. Κάθε γραμμή περιέχει προϊόν, ποσότητα, τιμή και φόρους —είναι η καρδιά της παραγγελίας.
12. amount_untaxed
Τύπος: Float. Το υπόλοιπο χωρίς φόρους. Υπολογίζεται από τις γραμμές και χρησιμοποιείται για εμφανίσεις και αναφορές.
13. amount_tax
Τύπος: Float. Το συνολικό ποσό φόρου. Υπολογίζεται από τις γραμμές με βάση τη ρύθμιση των φόρων και εμφανίζεται σε παραγγελίες και τιμολόγια.
14. amount_total
Τύπος: Float. Το συνολικό ποσό με φόρους. Βασική τιμή για τιμολόγηση και αναφορές.
15. currency_id
Τύπος: Many2one (res.currency). Το νόμισμα της παραγγελίας. Συνήθως κληρονομείται από την εταιρεία ή την τιμοκατάλογο. Όλα τα χρηματικά πεδία χρησιμοποιούν αυτό το νόμισμα.
16. pricelist_id
Τύπος: Many2one (product.pricelist). Ο τιμοκατάλογος που εφαρμόζεται. Καθορίζει τις μοναδιαίες τιμές στις γραμμές και μπορεί να προέρχεται από τον πελάτη ή να οριστεί χειροκίνητα.
17. payment_term_id
Τύπος: Many2one (account.payment.term). Όροι πληρωμής (π.χ. 30 ημέρες, προκαταβολή 50%). Χρησιμοποιούνται κατά τη δημιουργία τιμολογίων.
18. fiscal_position_id
Τύπος: Many2one (account.fiscal.position). Η φορολογική θέση για αντιστοίχιση φόρων. Σημαντικό όταν ο πελάτης έχει διαφορετικό φορολογικό καθεστώς ή χώρα.
19. client_order_ref
Τύπος: Char. Αναφορά πελάτη ή αριθμός PO. Χρήσιμο όταν ο πελάτης δίνει δικό του αναγνωριστικό και εμφανίζεται σε έγγραφα.
20. origin
Τύπος: Char. Η πηγή δημιουργίας (π.χ. όνομα ευκαιρίας). Βοηθά στην ιχνηλασιμότητα μεταξύ εγγράφων.
21. create_date
Τύπος: Datetime. Η ημερομηνία και ώρα δημιουργίας της εγγραφής. Διαχειρίζεται αυτόματα από το Odoo —χρήσιμο για auditing.
22. write_date
Τύπος: Datetime. Η τελευταία ημερομηνία/ώρα τροποποίησης. Επίσης αυτόματα —βοηθά στην παρακολούθηση αλλαγών.
23. note
Τύπος: Text. Όροι, εσωτερικές σημειώσεις ή ειδικές οδηγίες. Μπορεί να εμφανιστεί στην προσφορά και στο τιμολόγιο.
24. require_signature
Τύπος: Boolean. Αν είναι True, απαιτείται ηλεκτρονική υπογραφή από τον πελάτη πριν την επιβεβαίωση —χρήσιμο για e‑commerce και portal flows.
25. require_payment
Τύπος: Boolean. Αν είναι True, απαιτείται πληρωμή πριν την επιβεβαίωση —για προκαταβολές ή πληρωμές εκ των προτέρων.
26. invoice_status
Τύπος: Selection. Παρακολουθεί την κατάσταση τιμολόγησης: no (δεν έχει τιμολογηθεί), to invoice (έτοιμο για τιμολόγηση), invoiced (έχει τιμολογηθεί πλήρως), upsell (έχουν προστεθεί επιπλέον γραμμές προς τιμολόγηση).
27. locked
Τύπος: Boolean. Όταν είναι True, η παραγγελία δεν μπορεί να τροποποιηθεί. Μπαίνει αυτόματα σε επιβεβαιωμένες παραγγελίες ή όταν τα σχετικά έγγραφα έχουν καταχωρηθεί.
28. company_id
Τύπος: Many2one (res.company). Σε multi‑company περιβάλλον, δείχνει σε ποια εταιρεία ανήκει η παραγγελία —επηρεάζει ορατότητα και δικαιώματα.
29. tag_ids
Τύπος: Many2many (crm.tag). Ετικέτες για κατηγοριοποίηση. Χρήσιμες για φιλτράρισμα, αναφορές και segmentation σε custom ροές.
30. signed_by
Τύπος: Char. Το όνομα του υπογράφοντος όταν απαιτείται υπογραφή. Χρησιμοποιείται για auditing.
31. signed_on
Τύπος: Datetime. Η ημερομηνία και ώρα υπογραφής. Σημαντικό όταν η υπογραφή είναι απαραίτητη για επιβεβαίωση.
32. prepayment_percent
Τύπος: Float. Το ποσοστό προκαταβολής που απαιτείται. Συνδυάζεται με require_payment για παραγγελίες με κατάθεση.
Πώς χρησιμοποιείται το μοντέλο στις επιχειρησιακές ροές
1. Από προσφορά σε παραγγελία
Ο πωλητής φτιάχνει προσφορά (draft), προσθέτει γραμμές και τιμές και την αποστέλλει στον πελάτη. Μετά την επιβεβαίωση, η κατάσταση αλλάζει σε sale και μπορούν να δημιουργηθούν τιμολόγια και παραστατικά αποστολής.
2. E‑commerce και Portal
Οι πελάτες μπορούν να παραγγείλουν μέσω του website. Οι παραγγελίες καταχωρούνται ως sales.order. Τα flags require_signature και require_payment εξασφαλίζουν απαιτούμενη υπογραφή ή πληρωμή πριν την επιβεβαίωση.
3. Από CRM σε Πωλήσεις
Σε κλείσιμο ευκαιρίας δημιουργείται αυτόματα προσφορά που συνδέεται μέσω του origin. Τα user_id και team_id επηρεάζουν αναφορές, προμήθειες και KPI της ομάδας.
4. Τιμολόγηση
Από επιβεβαιωμένη παραγγελία προκύπτουν τιμολόγια· οι γραμμές τιμολογούνται από τις order_line. Τα payment_term_id και fiscal_position_id προέρχονται από την παραγγελία, ενώ το invoice_status παρακολουθεί την πρόοδο.
5. Παράδοση και Ημερομηνία Δέσμευσης
Το commitment_date καθορίζει τον προγραμματισμό αποστολών. Όταν είναι ορισμένο, οι παραγγελίες παράδοσης σχεδιάζονται γύρω από αυτή την ημερομηνία και το partner_shipping_id ορίζει τον τόπο παράδοσης.
Πώς το επεκτείνουν οι προγραμματιστές
Οι προγραμματιστές επεκτείνουν το sales.order με διάφορες τεχνικές, με κύριο εργαλείο την κληρονομικότητα μοντέλου του Odoo.
Κληρονομικότητα Μοντέλου
Χρησιμοποιήστε _inherit = 'sale.order' για να επεκτείνετε το μοντέλο. Μπορείτε να προσθέσετε νέα πεδία, να παρακάμψετε μεθόδους ή να ορίσετε περιορισμούς. Με αυτόν τον τρόπο οι αλλαγές παραμένουν σε ξεχωριστό module και διευκολύνονται οι μελλοντικές ενημερώσεις.
Προσθήκη Πεδίων
Ορίζετε νέα πεδία στο κληρονομημένο μοντέλο. Επιλέξτε τον κατάλληλο τύπο: Char, Many2one, Boolean, Integer, Text, Selection. Σκεφτείτε τη δυνατότητα company‑dependent όταν δουλεύετε με πολλαπλές εταιρείες.
Επεκτάσεις σε Python
Παραμετροποιήστε μεθόδους όπως action_confirm, create ή write για να προσθέσετε λογική. Χρησιμοποιήστε super() για να καλέσετε την αρχική συμπεριφορά. Προσοχή στα υπολογιζόμενα πεδία και στις εξαρτήσεις τους.
Odoo Studio
Το Odoo Studio επιτρέπει την προσθήκη πεδίων χωρίς γραφή κώδικα —ιδανικό για γρήγορες προσαρμογές. Όμως για σύνθετη λογική ή περιβάλλον με upgrades, τα custom modules είναι πιο συντηρήσιμα.
Καλές πρακτικές
- Χρησιμοποιήστε τη σωστή κατάσταση για κάθε στάδιο. Αποφύγετε να παρακάμπτετε τη λογική επιβεβαίωσης ή να σκανδαλίζετε καταστάσεις.
- Ορίστε commitment_date όταν έχετε δεσμευμένη ημερομηνία παράδοσης —βοηθά στο σχεδιασμό αποστολών.
- Χρησιμοποιήστε το commercial_partner_id όταν χρειάζεστε το ανώτερο επιπέδου οντότητας για συγκεντρωτικές ανάγκες (π.χ. όριο πίστωσης ή αναφορές).
- Για συνδέσεις API, προτιμήστε XML‑RPC ή JSON‑RPC. Το sales.order είναι πλήρως εκτεθειμένο —κάντε προσεκτική χαρτογράφηση εξωτερικών IDs.
- Για custom πεδία χρησιμοποιήστε πρόθεμα
x_ή πρόθεμα του module για να αποφύγετε συγκρούσεις σε μελλοντικές εκδόσεις.
Συνηθισμένα λάθη
- Μην τροποποιείτε επιβεβαιωμένες παραγγελίες χωρίς έλεγχο του πεδίου locked. Οι κλειδωμένες παραγγελίες απαιτούν νέα αναθεώρηση ή σωστή ροή για αλλαγές.
- Μην συγχέετε partner_id, partner_invoice_id και partner_shipping_id —το καθένα έχει διακριτό ρόλο. Ορίστε και τα τρία όταν οι διευθύνσεις διαφέρουν.
- Μην παρακάμπτετε το
super()όταν υπερκαλύπτετε τοaction_confirm: αυτό μπορεί να σπάσει άλλες επεκτάσεις ή μελλοντικά updates. - Αποφεύγετε να προσθέτετε υποχρεωτικά πεδία χωρίς προκαθορισμένες τιμές —υπάρχει κίνδυνος ότι υπαρκτές εγγραφές θα αποτύχουν σε migrations.
- Μην ξεχνάτε να ορίσετε pricelist_id όταν το νόμισμα ή οι τιμές διαφέρουν από την προεπιλογή —λανθασμένες τιμές προκαλούν προβλήματα στη τιμολόγηση.
Συμπέρασμα
Το sales.order είναι κεντρικό για το module Πωλήσεις του Odoo. Αποθηκεύει προσφορές και επιβεβαιωμένες παραγγελίες. Κατανοώντας τα πεδία και τον τρόπο επέκτασης, θα ρυθμίσετε και θα προσαρμόσετε το σύστημα με ασφάλεια.
Είτε είστε functional consultant που χαρτογραφεί διαδικασίες πωλήσεων, είτε developer που δημιουργεί modules, η καλή γνώση του sales.order εξοικονομεί χρόνο και μειώνει λάθη.
Χρειάζεστε βοήθεια με την υλοποίηση του Odoo;
Η Dasolo συνεργάζεται με εταιρείες για την υλοποίηση, προσαρμογή και βελτιστοποίηση του Odoo. Ειδικευόμαστε σε API ενσωματώσεις και ανάπτυξη Odoo, με εμπειρία στην αρχιτεκτονική δεδομένων και μοντέλα όπως το sales.order.
Αν χρειάζεστε υποστήριξη για την υλοποίηση Odoo, custom modules ή ενσωματώσεις, μπορούμε να βοηθήσουμε. Κλείστε μια παρουσίαση για να συζητήσουμε το έργο σας.