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 acquisto alle fatture fino all'inventario, 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 i campi di Odoo, le relazioni e la logica aziendale.
Questo articolo si concentra su uno dei modelli più importanti di Odoo: purchase.order. Che tu stia costruendo moduli personalizzati, integrando sistemi esterni o configurando flussi di lavoro di approvvigionamento, lavorerai con questo modello.
Cos'è il modello purchase.order
Il modello purchase.order rappresenta ordini di acquisto e richieste di preventivo (RFQ) in Odoo. È il luogo centrale dove tutte le transazioni di approvvigionamento vengono registrate prima di diventare ricevute o fatture fornitore.
Questo modello in Odoo è utilizzato dal modulo Acquisti. Quando un acquirente crea un RFQ, crea un record purchase.order. Quando il fornitore conferma o l'acquirente approva, l'ordine passa da bozza a confermato. Lo stesso modello in Odoo contiene sia RFQ in bozza che ordini di acquisto confermati. Il campo stato tiene traccia del ciclo di vita.
Altri moduli estendono questo modello attraverso l'ereditarietà dei modelli Odoo. L'Inventario aggiunge logica di ricezione e prelievo. La Contabilità aggiunge campi per le fatture dei fornitori. La Produzione può creare ordini di acquisto da distinte base. Ogni modulo aggiunge ciò di cui ha bisogno senza duplicare la struttura principale.
Campi chiave nel modello
Ecco i campi Odoo più importanti nel modello purchase.order. Comprendere questi campi ti aiuterà a lavorare in modo efficace con gli ordini di acquisto.
1. name
Tipo: Char. Questo campo memorizza il riferimento dell'ordine (es. PO00042). Viene tipicamente generato automaticamente e visualizzato nelle viste elenco e sui documenti. È il principale identificatore per l'ordine di acquisto.
2. state
Tipo: Selection. Tiene traccia del ciclo di vita dell'ordine. Valori: bozza (RFQ), inviato (inviato al fornitore), da approvare (in attesa di approvazione), acquisto (confermato), completato (completamente ricevuto e fatturato), annullato (annullato). Lo stato determina quali azioni sono disponibili.
3. partner_id
Tipo: Many2one (res.partner). Il fornitore o fornitore. Obbligatorio. Questo è il contatto principale o l'azienda per l'ordine. Utilizzato per tutta la logica e la reportistica relative ai fornitori.
4. partner_ref
Tipo: Char. Il riferimento del fornitore o il numero d'ordine del fornitore. Utilizzato quando il fornitore fornisce il proprio riferimento d'ordine. Visualizzato sui documenti e aiuta a abbinare ricevute e fatture.
5. data_ordine
Tipo: Datetime. La data dell'ordine. Per ordini bozza: data di creazione. Per ordini confermati: data di conferma. Utilizzato per report, ordinamento e come data prevista predefinita per le righe d'ordine.
6. data_approvazione
Tipo: Datetime. La data di approvazione o conferma. Impostata quando l'ordine passa allo stato di acquisto. Solo in lettura. Utilizzato per report e audit trail.
7. riga_ordine
Tipo: One2many (purchase.order.line). Le righe d'ordine. Ogni riga contiene prodotto, quantità, prezzo e tassa. Questo è il dettaglio principale dell'ordine di acquisto.
8. importo_non_imponibile
Tipo: Float. Il subtotale prima delle tasse. Calcolato dalle righe d'ordine. Utilizzato per report e visualizzazione.
9. importo_tasse
Tipo: Float. L'importo totale delle tasse. Calcolato dalle righe d'ordine in base alla configurazione fiscale. Visualizzato sull'ordine e sulla fattura del fornitore.
10. importo_totale
Tipo: Float. L'importo totale comprensivo di tasse. L'importo principale per la fatturazione e la reportistica.
11. currency_id
Tipo: Many2one (res.currency). La valuta. Di solito ereditata dall'azienda o dal fornitore. Tutti i campi monetari utilizzano questa valuta.
12. origin
Tipo: Char. Il documento sorgente. Ad esempio, quando un ordine viene creato da un ordine di vendita (dropship) o da un ordine di produzione, il nome sorgente è memorizzato qui. Utilizzato per la tracciabilità.
13. dest_address_id
Tipo: Many2one (res.partner). L'indirizzo di consegna. Se non impostato, predefinito all'indirizzo dell'azienda. Utilizzato per il dropshipping quando le merci vanno direttamente al cliente.
14. priority
Tipo: Selezione. Priorità dell'ordine: Normale o Urgente. Utilizzato per ordinare e evidenziare. Gli ordini urgenti possono ricevere un trattamento speciale nei flussi di lavoro.
15. invoice_status
Tipo: Selezione. Tiene traccia della fatturazione: no (non fatturato), da fatturare (pronto per la fatturazione), fatturato (completamente fatturato). Determina la visibilità dell'azione Crea Fattura.
16. invoice_count
Tipo: Intero. Numero di fatture fornitore correlate. Calcolato. Utilizzato per la visualizzazione e per aprire l'elenco delle fatture.
17. invoice_ids
Tipo: One2many (account.move). Le fatture dei fornitori correlate. Collega gli ordini di acquisto alla contabilità. Utilizzato per il matching a tre e il tracciamento dei pagamenti.
18. picking_ids
Tipo: One2many (stock.picking). Gli ordini di consegna o le ricevute correlate. Utilizzato quando il modulo Acquisti è installato con Inventario.
19. picking_count
Tipo: Intero. Numero di picking correlati. Calcolato. Utilizzato per la visualizzazione e per aprire l'elenco delle ricevute.
20. 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.
21. write_date
Tipo: Datetime. Memorizza la data e l'ora dell'ultima modifica. Anche gestito automaticamente. Aiuta a tenere traccia di quando i dati sono stati aggiornati per l'ultima volta.
22. notes
Tipo: Testo. Termini e condizioni o note interne. Possono essere visualizzati sull'ordine di acquisto. Utilizzato per istruzioni speciali al fornitore.
23. company_id
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.
24. user_id
Tipo: Many2one (res.users). L'acquirente o l'utente responsabile. Utilizzato per i flussi di approvazione e l'assegnazione delle attività.
25. fiscal_position_id
Tipo: Many2one (account.fiscal.position). La posizione fiscale per la mappatura fiscale. Applicata quando il fornitore si trova in un paese diverso o ha un regime fiscale speciale.
26. payment_term_id
Tipo: Many2one (account.payment.term). Termini di pagamento (ad es. Net 30, 50% in anticipo). Utilizzato durante la creazione delle fatture dei fornitori.
27. display_name
Tipo: Char. Nome visualizzato calcolato. Combina il nome con le informazioni del fornitore. Utilizzato nei menu a discesa many2one e nei risultati di ricerca. Solo lettura.
28. active
Tipo: Boolean. Flag di eliminazione soft. Quando è False, il record è archiviato e nascosto dalle visualizzazioni predefinite. Gli ordini di acquisto non vengono fisicamente eliminati per preservare la storia.
Come viene utilizzato questo modello nei flussi di lavoro aziendali
1. RFQ a Ordine di Acquisto
L'acquirente crea una richiesta di offerta (bozza). Aggiunge righe, invia al fornitore. Il fornitore conferma o l'acquirente conferma manualmente. L'ordine è confermato (stato = acquisto). Possono essere creati ricevute e fatture del fornitore.
2. Ricezione del Fornitore
Quando le merci arrivano, l'utente crea una ricevuta dall'ordine di acquisto. Gli picking_ids sono collegati. Le quantità ricevute aggiornano le scorte. I costi dei prodotti vengono aggiornati dal prezzo di acquisto.
3. Fattura del Fornitore
Da un ordine confermato, gli utenti creano fatture del fornitore. 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.
4. Dropshipping
Quando un ordine di vendita attiva un acquisto, l'origine si collega all'ordine di vendita. dest_address_id è impostato sull'indirizzo del cliente in modo che il fornitore possa spedire direttamente. Il modello purchase.order è il ponte tra vendite e approvvigionamento.
5. Produzione e MRP
Quando un ordine di produzione ha bisogno di componenti, può creare ordini di acquisto per materie prime. Il campo origine si collega all'ordine di produzione. Questo modello è centrale nel ciclo procure-to-pay.
Come gli sviluppatori estendono questo modello
Gli sviluppatori estendono purchase.order utilizzando diversi modelli. L'ereditarietà del modello Odoo è il meccanismo principale.
Ereditarietà del Modello
Usa _inherit = 'purchase.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 facilitare gli aggiornamenti.
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 button_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. Ottimo per personalizzazioni rapide. Per logiche complesse o aggiornamenti, i moduli personalizzati sono più manutenibili. Il modello API in Odoo (purchase.order) è completamente esposto tramite XML-RPC e JSON-RPC per integrazioni.
Migliori pratiche
- Usa lo stato corretto per ogni fase. Non saltare stati o eludere la logica di conferma.
- Imposta partner_ref quando il fornitore fornisce un riferimento. Aiuta a abbinare ricevute e fatture.
- Usa origin per tracciare la fonte degli ordini di acquisto. Essenziale per il dropshipping e la produzione.
- Quando costruisci integrazioni API, usa l'API XML-RPC o JSON-RPC. Il modello purchase.order è completamente esposto. Mappa con attenzione gli ID esterni.
- 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 lo stato. Gli ordini confermati hanno campi limitati. Crea un nuovo ordine o utilizza il flusso di lavoro appropriato.
- Confondere partner_id e dest_address_id. partner_id è il fornitore; dest_address_id è dove vanno le merci (per il dropshipping).
- Sovrascrivere button_confirm senza chiamare super(). Questo può rompere altri moduli o futuri aggiornamenti.
- Aggiungere campi personalizzati richiesti senza valori predefiniti. Gli ordini esistenti falliranno la validazione durante l'aggiornamento.
- Dimenticare di impostare currency_id quando si tratta di fornitori multi-valuta. Una valuta errata può portare a costi e fatturazione errati.
Conclusione
Il modello purchase.order è centrale per Odoo Purchase. Memorizza RFQ e ordini di acquisto confermati. Comprendere i suoi campi Odoo 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 approvvigionamento o uno sviluppatore che costruisce moduli personalizzati, una solida comprensione di purchase.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 Odoo e modelli come purchase.order.
Se hai bisogno di aiuto con la tua implementazione Odoo, moduli personalizzati o integrazioni, siamo qui per aiutarti. Prenota una demo per discutere del tuo progetto.