Sviluppi custom Odoo mantenibili: pattern, anti-pattern, costi (guida PMI italiane)

Trentaseiesima guida operativa Odoo 19 per PMI italiane. Prima o poi ogni PMI italiana deve estendere Odoo: aggiungere un campo custom, modificare un report, sviluppare un workflow specifico per il proprio business. Il modo in cui questi sviluppi vengono fatti determina se nei prossimi 5 anni saranno un asset o un debito tecnico ingestibile. In questa guida vediamo come progettare e implementare sviluppi custom Odoo mantenibili nel tempo, con framework concreto, pattern, anti-pattern e casi pratici PMI italiane.

Vediamo: livelli di customizzazione Odoo (config, Studio, codice), principi di codice mantenibile, struttura di un modulo custom, repository management, test, documentazione, costi e ROI delle customizzazioni, errori comuni.

I 4 livelli di customizzazione Odoo

Livello 1: Configurazione (no-code, gratis)

• Settings standard per ogni modulo
• Sequenze documentali, regole IVA, conti contabili
• Tag, categorie, stage workflow
• Workflow attivazione/disattivazione feature
• Quando usarlo: SEMPRE come prima opzione

Livello 2: Studio (low-code, Enterprise)

• Aggiungere campi custom a modelli esistenti
• Modificare form/list/kanban view
• Creare automazioni base (server actions)
• Generare report semplici
• Quando usarlo: customization rapide, non critical

Livello 3: Moduli custom Python/XML (code)

• Estendere modelli con logica business complessa
• Creare nuovi modelli e workflow
• Override metodi standard
• Integrazioni con sistemi esterni
• Quando usarlo: logica complessa, mantenibilità lungo termine

Livello 4: Core modifications (sconsigliato!)

• Modificare codice Odoo standard
• Vantaggi: nessuno reali
• Svantaggi: ogni upgrade è un incubo
• Quando usarlo: MAI. Sempre estendere via moduli custom.

Quando scegliere quale livello

Esigenza	Livello raccomandato
Aggiungere campo “data scadenza contratto” su cliente	Studio
Calcolare bonus venditori con formula complessa	Modulo Python
Cambiare colore brand su report fattura	Modulo XML (template QWeb)
Integrazione con software gestione cantiere esterno	Modulo Python + API
Workflow approvazione spese con 4 livelli	Studio + se complesso Modulo Python
Nuovo modulo verticale per il proprio settore	Modulo Python completo

Anatomia di un modulo custom mantenibile

Struttura di base

my_custom_module/
├── __init__.py
├── __manifest__.py       # Metadati modulo
├── models/
│   ├── __init__.py
│   └── my_model.py       # Logica business
├── views/
│   └── my_views.xml      # Form/list/kanban
├── data/
│   └── data.xml          # Dati seed
├── security/
│   └── ir.model.access.csv  # ACL
├── reports/
│   └── my_report.xml     # Report QWeb
├── static/
│   └── description/
│       └── icon.png
├── tests/
│   └── test_my_model.py
└── README.md

Convenzioni di naming

• Modulo: prefisso azienda (es. brentasoft_ per evitare conflitti)
• Modelli: lowercase con underscore (brentasoft.lead.priority)
• Campi: snake_case (x_priority_score per Studio, priority_score per moduli custom)
• View IDs: prefisso modulo + tipo (brentasoft_lead_form_view)
• Security groups: gerarchia chiara (group_brentasoft_lead_user, _manager)

Personalizzazione viste: dove vivono le modifiche

Tutte le view di Odoo (form, list, kanban, calendar, pivot) sono archiviate come record nel database. Modificarle in modo non distruttivo è la chiave per mantenibilità:

• View base fornite da Odoo
• View di estensione (inherit_id) che modificano la base
• View custom che sostituiscono completamente
• Strategia inherit: 90% dei casi, sempre preferibile

Esempio view inherit pulita

<record id="view_partner_form_inherit_brentasoft" model="ir.ui.view">
    <field name="name">res.partner.form.inherit.brentasoft</field>
    <field name="model">res.partner</field>
    <field name="inherit_id" ref="base.view_partner_form"/>
    <field name="arch" type="xml">
        <xpath expr="//field[@name='vat']" position="after">
            <field name="brentasoft_priority"/>
        </xpath>
    </field>
</record>

Template email custom: branding e comunicazione

I template email Odoo permettono di personalizzare ogni comunicazione automatica (conferma ordine, fattura, riassunto settimanale) mantenendo brand coerente:

• Template Jinja2/QWeb con dati dinamici
• Logo, colori, footer personalizzati
• Versioning template via moduli (no edit diretto in produzione)
• Test ambiente staging prima di attivare
• Multilingua per export

Configurazioni come codice: il principio

I settings Odoo influenzano comportamenti critici (sconti, tasse, sequenze). Mantenere settings importanti come configurazione in moduli custom (vs UI manuale) garantisce riproducibilità tra ambienti:

• Settings critici versionati come data.xml in modulo custom
• Setup riproducibile su staging/produzione automaticamente
• Documentazione settings nel commit message
• Audit log per cambiamenti settings produzione

Principi di codice mantenibile

1. Single Responsibility Principle

Un modulo = una responsabilità chiara. Non un mega-modulo che fa tutto.

• NO: brentasoft_customizations con dentro 30 feature diverse
• SÌ: brentasoft_lead_priority, brentasoft_invoice_branding, brentasoft_warehouse_kpi separati

2. Extension over Modification

Sempre estendere modelli/view standard via inherit, mai sostituire/sovrascrivere.

3. Documentation as Code

• README.md in ogni modulo con: scopo, dipendenze, screenshot, esempi
• Docstring Python per ogni metodo non banale
• Commit message significativi (no “fix”, “update”)

4. Test automatici

• Almeno unit test per logica business critica
• CI/CD che gira test su ogni push
• Code coverage target: 70%+ per moduli core, 40%+ per moduli accessori

5. Version Control

• Repository Git per ogni modulo custom
• Branching strategy: feature branches + main per produzione
• Tag per release production
• Pull request con code review obbligatoria

Repository management

Struttura raccomandata

brentasoft-odoo-customs/
├── README.md (overview, setup)
├── docker-compose.yml (dev environment)
├── requirements.txt (Python deps)
├── modules/
│   ├── brentasoft_base/
│   ├── brentasoft_lead_enhanced/
│   ├── brentasoft_invoice_custom/
│   └── ...
├── tests/
└── .github/workflows/ci.yml

Branching strategy

• main: protetto, solo merge via PR, deployato in produzione
• develop: integrazione feature in corso, deployato su staging
• feature/xyz: branch temporanea per ogni feature nuova
• hotfix/xyz: branch da main per fix urgenti produzione

Release management

• Tag semantici (v1.2.3) per ogni deploy produzione
• Changelog automatizzato da commit conventional
• Rollback con tag precedente disponibile

Anti-pattern da evitare

“Customization su customization su customization”

Problema: ogni nuova esigenza aggiunge un modulo che modifica un altro modulo custom. Dopo 2 anni 30+ moduli interdipendenti.
Soluzione: refactor periodico, consolidare moduli simili, eliminare obsoleti.

“Customization che replica core Odoo”

Problema: sviluppata feature custom poi Odoo la include in versione successiva.
Soluzione: prima di sviluppare custom, verificare roadmap Odoo + cercare community Apps.

“Hard-coded values”

Problema: codice fisso (es. if account_id == 142:) che funziona solo in produzione.
Soluzione: usare external IDs, parametri sistema, config Odoo.

“Logica nascosta in onchange”

Problema: logica critica solo in onchange JavaScript, non eseguita da import/API.
Soluzione: logica in Python (compute, constrains), onchange solo UI hint.

“Skip migration scripts”

Problema: cambio field type senza migration script, dati persi in upgrade.
Soluzione: ogni breaking change deve avere script SQL/Python di migrazione.

Costi e ROI customizzazioni

Costi tipici per tipologia

Tipologia customization	Effort	Costo tipico
Campo custom + view modifica (Studio)	2-4 ore	200-400 €
Workflow approval semplice	1-2 giorni	800-1.500 €
Report custom QWeb	1-3 giorni	800-2.500 €
Integrazione API esterna	3-10 giorni	2.500-8.000 €
Modulo verticale custom completo	10-40 giorni	8.000-35.000 €
Refactor 5-10 moduli legacy	15-30 giorni	12.000-25.000 €

ROI realistico

• Customization sostituisce operazione manuale ricorrente: payback 6-18 mesi
• Customization abilita revenue stream nuovo: ROI molto variabile
• Customization solo per “preferenza estetica”: ROI difficile, rivalutare

Maintenance cost: il costo invisibile

• Ogni customization ha un maintenance cost ricorrente (10-20% del setup all’anno)
• Customization durante upgrade major: 20-100% effort rispetto al setup iniziale
• Regola: massimo 15-20 customization “vive” contemporaneamente per PMI
• Cleanup annuale: rimuovere customization non più usate

Casi pratici PMI italiane

Caso 1 — Manifattura: modulo custom configuratore prodotto

• Esigenza: configurazione prodotto con 200+ varianti e regole compatibilità
• Soluzione: modulo Python con engine regole + UI custom
• Effort: 25 giorni, costo 22k €
• ROI: -75% errori configurazione, +30% velocità preventivi
• Manutenzione: 4k €/anno

Caso 2 — Servizi: report finanziario PowerPoint-style

• Esigenza: report mensile CFO con 12 KPI + grafici brand
• Soluzione: template QWeb custom + integrazione Matplotlib per grafici
• Effort: 4 giorni, costo 3.5k €
• ROI: 8h/mese risparmiate per generazione report (= 4.2k €/anno)

Caso 3 — Retail: customization fuori controllo

• Anno 1: 8 customization “veloci” sviluppate
• Anno 3: 47 customization, dipendenze incrociate, upgrade impossibile
• Costo refactor: 35k € + 4 mesi blocco evoluzioni
• Lesson learned: governance cap a 15-20 customization da inizio

Caso 4 — E-commerce: modulo custom riconciliazione marketplace

• Esigenza: riconciliare 12.000 transazioni/mese da Amazon, eBay, Etsy
• Soluzione: modulo Python con job batch + UI dashboard
• Effort: 18 giorni, costo 15k €
• ROI: 1 FTE risparmiato (35k €/anno), payback 5 mesi

FAQ

Posso sviluppare customization senza partner Odoo?

Per Studio sì (no-code). Per moduli Python: serve uno sviluppatore con esperienza Odoo (sintassi ORM, decorator, security, view inheritance). Costo formazione interna: 4-8 settimane per sviluppatore Python esperto.

Devo testare ogni customization?

Sì, almeno smoke test manuale. Per customization critiche (logica business, integrazioni): unit test obbligatori + UAT. Costo aggiuntivo test: 20-40% effort totale, ROI molto positivo (cattura 80%+ bug prima della produzione).

Come gestisco customization quando passo a nuova versione Odoo?

Best practice: ogni customization ha test automatici che verificano funzionamento su nuova versione. Test falliti = refactor necessario. Approccio sistematico: prima upgrade test, poi fix, poi produzione.

Posso vendere customization sviluppate?

Sì, anzi Odoo App Store permette di pubblicare moduli (gratis o a pagamento). Revenue stream interessante per PMI con sviluppi specifici di nicchia. Verificare licenza Odoo per pubblicazione community.

Cosa fare se la customization sviluppata diventa obsoleta?

Dismissal process: (1) verificare se nessun utente la usa più (analytics); (2) disinstallare in staging, verificare nessun impatto; (3) disinstallare in produzione; (4) rimuovere modulo dal repository; (5) documentare in changelog perché rimosso.

Prossimi passi

Nelle prossime guide vedremo come creare report custom per BI con dashboard avanzati, come configurare workflow no-code con Studio per casi pratici, e come gestire la sicurezza avanzata Odoo (RBAC granulare, multi-company permissions).

Vuoi sviluppi custom Odoo mantenibili per la tua PMI?
G Tech Group sviluppa moduli custom Odoo con framework strutturato: repository Git versionato, test automatici, CI/CD, documentazione completa, code review. Cap 15-20 customization vive per PMI per sostenibilità lungo termine.
Richiedi un preventivo gratuito oppure prova la nostra demo Odoo 19 live. Oppure prova Odoo direttamente su odoo.com (link partner Brentasoft).