Introduzione
In Odoo, i modelli definiscono come i dati sono strutturati e memorizzati nel database. Ogni pezzo di dati aziendali con cui lavori, dagli ordini di vendita alle fatture ai contatti, vive in un modello.
Comprendere i modelli di Odoo è essenziale sia per gli sviluppatori che per i consulenti funzionali. I modelli sono la base dell'architettura dei dati di Odoo. Definiscono campi, relazioni e logica aziendale.
Questo articolo si concentra su uno dei modelli più importanti di Odoo: sales.order. Che tu stia costruendo moduli personalizzati, integrando sistemi esterni o configurando flussi di lavoro di vendita, lavorerai con questo modello.
Cos'è il modello sales.order
Il modello sales.order rappresenta le quotazioni e gli ordini di vendita in Odoo. È il luogo centrale dove tutte le transazioni di vendita vengono registrate prima di diventare fatturate o consegnate.
Questo modello in Odoo è utilizzato dal modulo Vendite.
Quando un venditore crea una quotazione, crea un record sales.order. Quando il cliente conferma, l'ordine passa da bozza a confermato. Lo stesso modello in Odoo contiene sia le quotazioni in bozza che gli ordini confermati. Il campo stato tiene traccia del ciclo di vita.
Altri moduli estendono questo modello attraverso l'ereditarietà dei modelli Odoo. Il CRM collega le opportunità agli ordini. La contabilità aggiunge campi per le fatture. L'inventario aggiunge date di consegna e di impegno. Ogni modulo aggiunge ciò di cui ha bisogno senza duplicare la struttura di base.
Campi chiave nel modello
Ecco i campi più importanti del modello sales.order in Odoo. Comprendere questi campi ti aiuterà a lavorare in modo efficace con le quotazioni e gli ordini.
1. name
Tipo: Char. Questo campo memorizza il riferimento dell'ordine o il numero della quotazione. Viene tipicamente generato automaticamente (ad es. S00042) e visualizzato nelle viste elenco e sui documenti. È l'identificatore principale per l'ordine.
2. state
Tipo: Selection. Tiene traccia del ciclo di vita dell'ordine. Valori: bozza (quotazione), inviato (quotazione inviata al cliente), vendita (ordine confermato), completato (completamente consegnato e fatturato), annullato (annullato). Lo stato determina quali azioni sono disponibili.
3. partner_id
Tipo: Many2one (res.partner). Il cliente. Obbligatorio. Questo è il contatto principale o l'azienda per l'ordine. Utilizzato per tutta la logica e la reportistica relative ai clienti.
4. partner_invoice_id
Tipo: Many2one (res.partner). L'indirizzo di fatturazione. Se non impostato, predefinito a partner_id. Utilizzare questo quando l'indirizzo della fattura è diverso dal contatto principale (ad es. fatturazione centrale).
5. partner_shipping_id
Tipo: Many2one (res.partner). L'indirizzo di consegna. Se non impostato, predefinito a partner_id. Utilizzato per ordini di consegna e calcoli di spedizione.
6. user_id
Tipo: Many2one (res.users). Il venditore o l'utente responsabile. Utilizzato per CRM, commissioni e assegnazione di attività. Spesso impostato dal team di vendita o dall'opportunità.
7. team_id
Tipo: Many2one (crm.team). Il team di vendita. Raggruppa i venditori e guida la reportistica. Utilizzato per dashboard e quote basate sul team.
8. date_order
Tipo: Datetime. La data dell'ordine. Per ordini in bozza: data di creazione. Per ordini confermati: data di conferma. Utilizzato per reportistica e ordinamento.
9. validity_date
Tipo: Data. La data di scadenza della quotazione. Dopo questa data, la quotazione potrebbe diventare non valida. Utile per offerte a tempo limitato.
10. commitment_date
Tipo: Data e ora. La data di consegna promessa. Quando impostata, gli ordini di consegna sono programmati in base a questa data piuttosto che ai tempi di consegna del prodotto. Importante per gli impegni con i clienti.
11. order_line
Tipo: One2many (sale.order.line). Le righe dell'ordine. Ogni riga contiene prodotto, quantità, prezzo e tassa. Questo è il dettaglio principale dell'ordine.
12. amount_untaxed
Tipo: Float. Il subtotale prima delle tasse. Calcolato dalle righe dell'ordine. Utilizzato per la reportistica e la visualizzazione.
13. amount_tax
Tipo: Float. L'importo totale delle tasse. Calcolato dalle righe dell'ordine in base alla configurazione fiscale. Visualizzato sull'ordine e sulla fattura.
14. amount_total
Tipo: Float. L'importo totale comprensivo di tasse. L'importo principale per la fatturazione e la reportistica.
15. currency_id
Tipo: Many2one (res.currency). La valuta. Di solito ereditata dall'azienda o dal listino prezzi. Tutti i campi monetari utilizzano questa valuta.
16. pricelist_id
Tipo: Many2one (product.pricelist). Il listino prezzi utilizzato per l'ordine. Determina i prezzi unitari sulle righe. Può essere impostato dal partner o manualmente.
17. payment_term_id
Tipo: Many2one (account.payment.term). Termini di pagamento (ad es. Net 30, 50% in anticipo). Utilizzato durante la creazione delle fatture.
18. fiscal_position_id
Tipo: Many2one (account.fiscal.position). La posizione fiscale per la mappatura delle tasse. Applicata quando il cliente si trova in un paese diverso o ha un regime fiscale speciale.
19. client_order_ref
Tipo: Char. Il riferimento del cliente o il numero dell'ordine di acquisto. Utilizzato quando il cliente fornisce il proprio riferimento d'ordine. Visualizzato su documenti e report.
20. origin
Tipo: Char. Il documento sorgente. Ad esempio, quando un ordine è creato da un'opportunità, il nome dell'opportunità è memorizzato qui. Utilizzato per la tracciabilità.
21. create_date
Tipo: Datetime. Memorizza la data e l'ora in cui il record è stato creato. Gestito automaticamente da Odoo. Utile per report e audit.
22. write_date
Tipo: Data e ora. Memorizza la data e l'ora dell'ultima modifica. Gestito automaticamente. Aiuta a tenere traccia di quando i dati sono stati aggiornati per l'ultima volta.
23. nota
Tipo: Testo. Termini e condizioni o note interne. Può essere visualizzato nel preventivo e nella fattura. Utilizzato per testi legali o istruzioni speciali.
24. richiedi_firma
Tipo: Booleano. Quando è Vero, il cliente deve firmare online prima che l'ordine venga confermato. Utilizzato per flussi di e-commerce e portali.
25. richiedi_pagamento
Tipo: Booleano. Quando è Vero, il pagamento è richiesto prima della conferma. Utilizzato per ordini prepagati o basati su deposito.
26. stato_fattura
Tipo: Selezione. Tiene traccia della fatturazione: no (non fatturato), da fatturare (pronto per la fatturazione), fatturato (completamente fatturato) o upsell (linee aggiuntive da fatturare).
27. bloccato
Tipo: Booleano. Quando è Vero, l'ordine non può essere modificato. Impostato automaticamente quando l'ordine è confermato o quando i documenti correlati sono stati pubblicati.
28. id_azienda
Tipo: Many2one (res.company). In configurazioni multi-azienda, questo indica a quale azienda Odoo appartiene l'ordine. Influisce sulla visibilità e sull'accesso ai record.
29. tag_ids
Tipo: Many2many (crm.tag). Tag per la categorizzazione. Utilizzati per filtrare, riportare e segmentare. Flessibili per flussi di lavoro personalizzati.
30. signed_by
Tipo: Char. Nome della persona che ha firmato l'ordine quando viene utilizzato require_signature. Memorizzato per audit.
31. signed_on
Tipo: Datetime. Data e ora della firma. Utilizzato quando è richiesta la firma per la conferma.
32. prepayment_percent
Tipo: Float. La percentuale dell'ordine che deve essere pagata come prepagamento. Utilizzato con require_payment per ordini basati su deposito.
Come viene utilizzato questo modello nei flussi di lavoro aziendali
1. Preventivo a Ordine
Il venditore crea un preventivo (bozza). Aggiunge righe, imposta i prezzi, invia al cliente. Il cliente conferma. L'ordine è confermato (stato = vendita). Possono essere creati fatture e ordini di consegna.
2. E-commerce e Portale
I clienti effettuano ordini sul sito web. Gli ordini vengono creati come record sales.order. require_signature e require_payment possono imporre il pagamento online o la firma prima della conferma.
3. CRM a Vendite
Quando un'opportunità viene vinta, viene creata una quotazione da essa. Il campo origine si collega all'opportunità. user_id e team_id guidano la reportistica delle vendite e le commissioni.
4. Fatturazione
Da un ordine confermato, gli utenti creano fatture. Le righe della fattura vengono estratte dalle righe dell'ordine. payment_term_id e fiscal_position_id provengono dall'ordine. invoice_status tiene traccia dei progressi.
5. Consegna e Impegno
commitment_date guida la pianificazione delle consegne. Quando impostato, gli ordini di consegna vengono pianificati attorno ad esso. partner_shipping_id definisce l'indirizzo di consegna.
Come gli sviluppatori estendono questo modello
Gli sviluppatori estendono sales.order utilizzando diversi modelli. L'ereditarietà del modello Odoo è il meccanismo principale.
Ereditarietà del Modello
Usa _inherit = 'sale.order' per estendere il modello. Aggiungi nuovi campi Odoo, sovrascrivi metodi o aggiungi vincoli. Il modello ereditato in Odoo mantiene le tue modifiche in un modulo separato per aggiornamenti facili.
Aggiunta di Campi
Definisci nuovi campi Odoo nel tuo modello ereditato. Usa il tipo di campo corretto: Char, Many2one, Boolean, Integer, Text, Selection. Considera i campi dipendenti dall'azienda per multi-azienda.
Estensioni Python
Sovrascrivi action_confirm, create o write per aggiungere logica. Usa super() per chiamare l'originale. Fai attenzione ai campi calcolati e alle loro dipendenze.
Odoo Studio
Odoo Studio ti consente di aggiungere campi senza codice. Utile per personalizzazioni rapide. Per logiche complesse o aggiornamenti, i moduli personalizzati sono più manutenibili.
Migliori pratiche
- Usa lo stato corretto per ogni fase. Non saltare stati o eludere la logica di conferma.
- Imposta commitment_date quando il cliente ha una data promessa. Migliora la pianificazione delle consegne.
- Usa commercial_partner_id quando hai bisogno dell'entità di livello superiore per il raggruppamento (ad esempio, per credito o reportistica).
- Quando costruisci integrazioni API, usa l'API XML-RPC o JSON-RPC. Il modello sales.order è completamente esposto. Mappa gli ID esterni con attenzione.
- Per campi personalizzati, usa il prefisso
x_o un prefisso di modulo per evitare conflitti con le future versioni di Odoo.
Errori comuni
- Modificare ordini confermati senza controllare i bloccati. Gli ordini bloccati non possono essere modificati. Crea una nuova revisione o usa il flusso di lavoro appropriato.
- Confondere partner_id, partner_invoice_id e partner_shipping_id. Ognuno ha uno scopo distinto. Imposta tutti e tre quando gli indirizzi differiscono.
- Sovrascrivere action_confirm senza chiamare super(). Questo può rompere altri moduli o futuri aggiornamenti.
- Aggiunta di campi personalizzati richiesti senza valori predefiniti. Gli ordini esistenti non supereranno la convalida durante l'aggiornamento.
- Dimenticare di impostare il pricelist_id quando la valuta o i prezzi differiscono dal predefinito. Prezzi errati possono portare a fatturazioni incorrette.
Conclusione
Il modello sales.order è centrale per Odoo Sales. Memorizza le quotazioni e gli ordini confermati. Comprendere i suoi campi e come i moduli lo estendono ti aiuterà a configurare, personalizzare e integrare Odoo in modo efficace.
Che tu sia un consulente funzionale che mappa i processi di vendita o uno sviluppatore che costruisce moduli personalizzati, una solida comprensione di sales.order ti farà risparmiare tempo e prevenire errori.
Hai bisogno di aiuto con la tua implementazione di Odoo?
Dasolo aiuta le aziende a implementare, personalizzare e ottimizzare Odoo. Siamo specializzati in integrazioni API e sviluppo Odoo. Il nostro team ha una profonda esperienza con l'architettura dei dati di Odoo e modelli come sales.order.
Se hai bisogno di aiuto con la tua implementazione di Odoo, moduli personalizzati o integrazioni, siamo qui per aiutarti. Prenota una demo per discutere del tuo progetto.