Introduzione
In Odoo, i modelli sono lo scheletro che tiene insieme i dati: definiscono quali informazioni si salvano, come si relazionano e dove finiscono in database. Ogni elemento operativo — ordini, fatture, anagrafiche — è una voce in uno di questi modelli.
Per consulenti funzionali e sviluppatori conoscere i modelli è imprescindibile: sono la base dell’architettura dati di Odoo. Stabilire campi, relazioni e regole di business a livello di modello significa decidere come l’intero sistema parla di quelle informazioni.
Questo articolo mette sotto la lente uno dei modelli più usati: sales.order. Che tu stia creando moduli personalizzati, collegando sistemi esterni o disegnando i flussi di vendita, prima o poi ti troverai a lavorare con questo modello.
Cos'è il modello sales.order
Il modello sales.order è dove Odoo registra preventivi e ordini di vendita. È il punto di raccolta delle transazioni commerciali prima che diventino consegne o fatture.
Lo troverai principalmente nel modulo Vendite (Sales) di Odoo.
Il flusso tipico parte da un preventivo: il venditore crea una bozza, la invia al cliente e, alla conferma, lo stato passa da draft a sale. Lo stesso record può rappresentare sia la proposta sia l’ordine confermato; lo stato (state) traccia questo ciclo di vita.
Altri moduli estendono il modello tramite l’ereditarietà di Odoo: il CRM collega opportunità, la contabilità aggiunge campi per la fatturazione, la logistica inserisce date di consegna. Ogni estensione arricchisce il modello senza riscriverne la struttura di base.
Campi chiave del modello
Ecco i campi più importanti del modello sales.order: comprenderli ti permette di gestire correttamente preventivi e ordini in Odoo.
1. name
Tipo: Char. Contiene il riferimento dell’ordine o del preventivo (es. S00042). Spesso è generato automaticamente e funge da identificatore principale visibile nelle liste e nei documenti.
2. state
Tipo: Selection. Indica il passo del processo (es. draft, sent, sale, done, cancel). Lo stato determina quali azioni sono disponibili su quel record.
3. partner_id
Tipo: Many2one (res.partner). Il cliente principale. Campo obbligatorio usato per tutta la logica commerciale e i report.
4. partner_invoice_id
Tipo: Many2one (res.partner). Indirizzo di fatturazione. Se non impostato, eredita partner_id. Utile quando la fatturazione è centralizzata o differente dal cliente principale.
5. partner_shipping_id
Tipo: Many2one (res.partner). Indirizzo di consegna. Di default coincide con partner_id; serve per la logistica e i calcoli di spedizione.
6. user_id
Tipo: Many2one (res.users). Il commerciale responsabile. Utilizzato per reportistica, commissioni e attività correlate.
7. team_id
Tipo: Many2one (crm.team). La squadra di vendita. Segmenta venditori, quota obiettivi e dashboard di team.
8. date_order
Tipo: Datetime. Data dell’ordine: in bozza è la data di creazione, su conferma è la data di conferma. Importante per report e ordinamento.
9. validity_date
Tipo: Date. Data di scadenza del preventivo: oltre tale data l’offerta può non essere più valida. Utile per offerte a tempo.
10. commitment_date
Tipo: Datetime. Data promessa per la consegna. Se impostata, la pianificazione delle spedizioni la prende come riferimento anziché i lead time dei prodotti.
11. order_line
Tipo: One2many (sale.order.line). Le righe d’ordine: prodotto, quantità, prezzo, tasse. È il dettaglio operativo dell’ordine.
12. amount_untaxed
Tipo: Float. Subtotale senza imposte, calcolato dalle righe. Usato per visualizzazioni e reportistica.
13. amount_tax
Tipo: Float. Totale imposte, calcolato dalle righe in base alle configurazioni fiscali. Visualizzato su ordine e fattura.
14. amount_total
Tipo: Float. Totale comprensivo di imposte: valore principale per la fatturazione e i report.
15. currency_id
Tipo: Many2one (res.currency). La valuta del documento, solitamente ereditata dalla società o dal listino. Tutti i campi monetari fanno riferimento a questa valuta.
16. pricelist_id
Tipo: Many2one (product.pricelist). Il listino usato per l’ordine: determina i prezzi unitari delle righe.
17. payment_term_id
Tipo: Many2one (account.payment.term). Modalità di pagamento (es. Net 30, acconto 50%). Applicata in fase di fatturazione.
18. fiscal_position_id
Tipo: Many2one (account.fiscal.position). Posizione fiscale per il mapping delle tasse, utile per clienti esteri o regimi particolari.
19. client_order_ref
Tipo: Char. Riferimento cliente o numero PO fornito dal cliente. Mostrato sui documenti per riconciliazione.
20. origin
Tipo: Char. Documento di origine (es. nome opportunità). Serve per tracciare da dove nasce l’ordine.
21. create_date
Tipo: Datetime. Data/ora di creazione del record, gestita automaticamente da Odoo. Utile per audit e report.
22. write_date
Tipo: Datetime. Data/ora dell’ultima modifica, anch’essa automatica. Aiuta a capire quando l’ordine è stato aggiornato.
23. note
Tipo: Text. Note o condizioni contrattuali visualizzabili su preventivo e fattura; adatto a testi legali o istruzioni particolari.
24. require_signature
Tipo: Boolean. Se vero, richiede la firma del cliente online prima della conferma — utile per e-commerce e portali.
25. require_payment
Tipo: Boolean. Se vero, impone il pagamento prima della conferma: utile per ordini con acconto o prepagamento.
26. invoice_status
Tipo: Selection. Stato di fatturazione: no, to invoice, invoiced, upsell — serve a capire cosa resta da fatturare.
27. locked
Tipo: Boolean. Se attivo, l’ordine non è modificabile; viene impostato automaticamente quando l’ordine è confermato o i documenti correlati sono registrati.
28. company_id
Tipo: Many2one (res.company). In ambienti multi-company indica a quale società appartiene l’ordine e influisce su visibilità e permessi.
29. tag_ids
Tipo: Many2many (crm.tag). Tag per categorizzazione e filtri personalizzati, utili per segmentazione e reporting.
30. signed_by
Tipo: Char. Nome della persona che ha firmato l’ordine quando è richiesta la firma; mantiene la tracciatura per audit.
31. signed_on
Tipo: Datetime. Data/ora della firma elettronica, registrata quando la firma è obbligatoria.
32. prepayment_percent
Tipo: Float. Percentuale di acconto richiesta: usata insieme a require_payment per ordini con deposito.
Come viene usato nei processi aziendali
1. Da preventivo a ordine
Flusso tipico: il commerciale compila una bozza, aggiunge righe e prezzi, invia il preventivo; al via libera del cliente il documento viene confermato (state = sale) e si possono generare fatture e movimenti di magazzino.
2. E-commerce e portale
Gli ordini web entrano come sales.order. Impostazioni come require_payment o require_signature gestiscono pagamenti online e firme prima della conferma automatica.
3. Dal CRM alle vendite
Quando un’opportunità è vinta si genera un preventivo collegato: origin conserva il riferimento all’opportunità mentre user_id e team_id alimentano report e regole di commissione.
4. Fatturazione
Da un ordine confermato si creano fatture: le righe vengono importate dall’ordine, e parametri come payment_term_id e fiscal_position_id sono ereditati; invoice_status mostra il progresso.
5. Consegne e date di impegno
commitment_date è il parametro che guida la pianificazione delle spedizioni: quando presente la logistica programma le consegne rispetto a quella data; partner_shipping_id definisce il punto di consegna.
Come gli sviluppatori estendono questo modello
Gli sviluppatori possono estendere sales.order con diversi approcci: l’ereditarietà dei modelli è lo strumento centrale in Odoo.
Ereditarietà del modello
Dichiarando _inherit = 'sale.order' crei un’estensione del modello: puoi aggiungere campi, sovrascrivere metodi o introdurre vincoli. Tenere le modifiche in un modulo separato facilita gli aggiornamenti.
Aggiungere campi
Definisci nuovi campi nel modello ereditato scegliendo il tipo corretto (Char, Many2one, Boolean, Integer, Text, Selection). Valuta se i campi devono essere dipendenti dalla company in scenari multi-azienda.
Estensioni in Python
Sovrascrivi metodi come action_confirm, create o write per inserire logica personalizzata, richiamando sempre super() quando appropriato. Attenzione ai campi computed e alle loro dipendenze per evitare incoerenze.
Odoo Studio
Odoo Studio permette di aggiungere campi senza codice: ottimo per modifiche rapide. Per logiche complesse o manutenzione a lungo termine è preferibile sviluppare moduli dedicati.
Buone pratiche
- Usa lo stato corretto per ogni fase del processo: non saltare passaggi né aggirare la logica di conferma prevista dal flusso standard.
- Imposta commitment_date quando il cliente richiede una data di consegna precisa: migliora la pianificazione e riduce le eccezioni logistiche.
- Quando ti serve raggruppare entità di business usa commercial_partner_id: è utile per controllo credito, aggregazioni e report che devono lavorare a livello di società madre.
- Per integrazioni API utilizza XML-RPC o JSON-RPC: il modello sales.order è esposto e va mappato con attenzione, gestendo gli ID esterni e le regole di sincronizzazione.
- Per campi custom adotta il prefisso x_ o aggiungi il prefisso del tuo modulo per evitare collisioni con futuri rilasci di Odoo.
Errori ricorrenti
- Non modificare ordini confermati senza verificare lo stato locked: se bloccati, crea revisioni o segui il processo corretto per apportare variazioni.
- Non confondere partner_id, partner_invoice_id e partner_shipping_id: hanno ruoli distinti. Quando gli indirizzi differiscono impostali tutti e tre correttamente.
- Non sovrascrivere action_confirm senza chiamare super(): puoi compromettere altri moduli o rompere compatibilità con aggiornamenti futuri.
- Evita di aggiungere campi obbligatori senza prevedere valori di default: altrimenti le registrazioni esistenti possono fallire durante aggiornamenti o installazioni.
- Ricordati di settare pricelist_id quando valuta o politiche di prezzo differiscono dal default: prezzi sbagliati si traducono in fatture errate.
Conclusione
Il modello sales.order è il nucleo del modulo Vendite in Odoo: conserva preventivi e ordini confermati. Conoscerne i campi e le estensioni ti permette di configurare, personalizzare e integrare Odoo in modo efficace.
Che tu sia un consulente funzionale che mappa processi di vendita o uno sviluppatore che costruisce moduli, padroneggiare sales.order riduce tempi e rischi operativi.
Hai bisogno di supporto per la tua implementazione Odoo?
Dasolo supporta aziende nell’implementazione, personalizzazione e ottimizzazione di Odoo, con particolare esperienza in integrazioni API e nello sviluppo su misura. Conosciamo a fondo l’architettura dei dati e modelli come sales.order.
Se ti serve assistenza per implementazioni Odoo, sviluppo di moduli personalizzati o integrazioni, possiamo aiutarti. Prenota una demo per discutere il tuo progetto.