Sviluppo Odoo su misura

Uno sviluppo Odoo non è mai un'operazione puramente tecnica quando tocca la fatturazione, l'IVA, gli stipendi o la contabilità. Impegna l'azienda nel tempo, con obblighi legali svizzeri che non si negoziano con un capitolato. Sul mercato romando, questa realtà oppone spesso due profili: gli integratori che padroneggiano il codice di Odoo senza conoscere il piano contabile svizzero, la fattura QR o le norme Swissdec; e le fiduciarie che padroneggiano la contabilità ma non sviluppano nulla in proprio, rinviando ogni richiesta di personalizzazione a terzi. AX-Fiduciaire, partner ufficiale Odoo, riunisce entrambe le competenze nello stesso team: lo sviluppo (moduli, campi, workflow, report, connettori) e l'expertise fiduciaria (contabilità, IVA, stipendi, conformità svizzera). Questa pagina presenta il nostro sviluppo Odoo su misura: cosa copre, il metodo seguito e i limiti che poniamo noi stessi.

Quando uno sviluppo su misura si giustifica

Odoo standard copre gran parte delle esigenze gestionali di una PMI: contabilità, fatturazione, acquisti, magazzino, vendite, risorse umane. Una parte di queste esigenze si risolve senza scrivere una riga di codice, tramite la configurazione o Odoo Studio. Uno sviluppo su misura si giustifica solo quando queste opzioni sono esaurite: un processo di business realmente specifico dell'azienda, una regola gestionale che lo standard non prevede, un connettore verso un sistema esterno che non esiste sotto nessuna forma di modulo, o un documento la cui struttura non corrisponde ad alcun modello fornito.

Al contrario, uno sviluppo non si giustifica quando:

• l'esigenza è già coperta dalla configurazione standard (campi aggiuntivi, regole di fatturazione, sequenze, diritti di accesso);
• Odoo Studio permette di aggiungere il campo, la vista o l'automazione senza toccare il codice sorgente;
• un modulo OCA (Odoo Community Association) esistente risponde all'esigenza, con il vantaggio di essere mantenuto da una comunità piuttosto che da un solo fornitore;
• l'esigenza reale è un cambio di abitudine di lavoro, non un limite del software.

Questa disciplina condiziona la sopravvivenza dello sviluppo nel tempo. Un modulo aggiunto per riprodurre un'abitudine anziché per rispondere a un vincolo reale diventa, al primo aggiornamento di versione maggiore, un onere di lavoro supplementare senza giustificazione chiara. Il criterio determinante non è il numero di funzioni che uno sviluppo può aggiungere, ma la sua capacità di attraversare le future versioni di Odoo. Odoo 19 è l'attuale versione stabile; Odoo 20 viene presentata il 24 settembre 2026. Ogni sviluppo su misura deve essere pensato per questa continuità, non solo per rispondere all'esigenza del momento.

Questa domanda si pone con particolare acutezza non appena un modulo tocca la contabilità, l'IVA o gli stipendi. Un campo aggiunto su una fattura, una regola di calcolo inserita in un workflow di validazione, o un'automazione che modifica una registrazione contabile non sono mai sviluppi banali: si eseguono a ogni transazione, spesso senza supervisione umana diretta. La domanda da porsi prima di ogni sviluppo non è quindi solo «è possibile», ma «questo sviluppo resterà corretto tra due anni, con un team diverso, su una versione di Odoo diversa». È questa domanda, più della fattibilità tecnica, a distinguere uno sviluppo pertinente da uno sviluppo che diventerà un problema.

Cosa è possibile sviluppare in Odoo

Lo sviluppo su misura in Odoo copre diversi livelli, dal più semplice al più strutturante. Si combinano spesso in uno stesso progetto: un connettore è quasi sempre accompagnato da un nuovo modello di dati per memorizzare ciò che riceve, un workflow modifica generalmente una vista per restare leggibile.

Moduli

Un modulo Odoo raggruppa un insieme coerente di funzionalità: modelli di dati, viste, regole di business, diritti di accesso. Un modulo su misura si installa accanto ai moduli standard senza modificarli, il che limita l'impatto sui futuri aggiornamenti di versione. È il livello che privilegiamo di default, piuttosto che intervenire direttamente nel codice dei moduli forniti da Odoo.

Campi e modelli

Aggiungere un campo a un formulario esistente, creare un nuovo modello di dati per tracciare un'informazione propria dell'azienda (un numero di pratica, una categoria interna, uno stato specifico), e collegare queste informazioni ai modelli esistenti — clienti, fatture, ordini, dipendenti. È spesso il punto di partenza di uno sviluppo più ampio: una volta memorizzata l'informazione, deve essere visualizzata, filtrata e talvolta riportata in un documento.

Viste

Adattare la visualizzazione di un formulario, di una lista o di un cruscotto affinché corrisponda al flusso di lavoro reale del team, senza sovraccaricare l'interfaccia standard di opzioni inutili per gli altri utenti. Una vista mal concepita, aggiunta per una sola postazione di lavoro, finisce spesso per infastidire tutti gli altri.

Workflow e automazioni

Automatizzare una sequenza di fasi — validazione, notifica, cambio di stato — secondo regole proprie dell'azienda, nei limiti in cui l'automazione resta comprensibile e correggibile da un essere umano. Un'automazione opaca, che nessuno sa spiegare né correggere, pone un rischio superiore al tempo che fa guadagnare.

Report e documenti

Progettare documenti stampati o PDF (fatture, buste paga, documenti di trasporto, report di analisi) che rispettino un'identità grafica o una struttura informativa particolare, restando comunque generati dai dati reali di Odoo, mai da una fonte parallela che rischierebbe di divergere.

Connettori e API

Collegare Odoo a un sistema esterno — banca, cassa registratrice, piattaforma e-commerce, strumento di settore — tramite l'API di Odoo (XML-RPC, JSON-RPC o REST a seconda dei casi) o tramite connettori dedicati agli standard svizzeri di pagamento, ISO 20022 e fattura QR. Un connettore mal isolato può far fallire un'intera sincronizzazione per un errore minore lato sistema esterno; l'analisi d'impatto, descritta più avanti, serve proprio a limitare questo rischio.

Portali

Aprire un accesso limitato e sicuro a terzi — clienti, fornitori, dipendenti — per consultare o depositare documenti, senza dare loro accesso all'interfaccia gestionale completa. I diritti di accesso del portale devono essere definiti con lo stesso rigore di quelli di un utente interno.

Il metodo seguito per ogni sviluppo

Uno sviluppo Odoo che tocca dati gestionali segue una sequenza di lavoro fissa, indipendentemente dalla sua dimensione.

Due fasi di questo metodo sono spesso trascurate dagli integratori che non conoscono la contabilità svizzera: l'analisi d'impatto, che deve includere una lettura delle conseguenze contabili e fiscali dello sviluppo, e il collaudo, che deve essere validato da una persona in grado di giudicare se il risultato prodotto è corretto in senso contabile, non solo in senso funzionale.

Il vincolo svizzero: cosa cambia la doppia competenza

Uno sviluppo che tocca la contabilità, l'IVA o gli stipendi non è mai uno sviluppo neutro. Deve rispettare il piano contabile adottato dall'azienda, le posizioni fiscali applicate a ogni tipo di operazione, la struttura della fattura QR, lo standard di pagamento ISO 20022 e i requisiti Swissdec per la gestione degli stipendi. Un campo aggiunto senza tener conto di questi vincoli può produrre una registrazione contabile errata, una posizione IVA scorretta o una fattura QR non conforme.

Odoo installa automaticamente la localizzazione svizzera (modulo l10n_ch) quando la società è configurata in Svizzera, il che pone una base corretta per il piano contabile e le aliquote IVA — 8.1%, 2.6% e 3.8% dal 1° gennaio 2024. Questa base standard non dispensa dal verificare, a ogni sviluppo, che la personalizzazione resti allineata con essa piuttosto che aggirarla.

Per gli stipendi, Odoo figura al registro Swissdec al livello «swissdec certified basic» (certificato n. 1203.25, per ELM 5.3, verificato il 22.09.2026). Uno sviluppo che tocca il calcolo o la trasmissione degli stipendi deve rispettare questo quadro di certificazione: non è un ambito in cui ci si può permettere un adattamento che si discosti dallo standard certificato. È proprio a questa intersezione che conta la doppia competenza di AX-Fiduciaire: comprendere sia cosa deve fare il codice sia cosa richiede la legge svizzera da questo risultato. I nostri sviluppi che toccano la contabilità si articolano con la nostra offerta contabilità Odoo; quelli che toccano gli stipendi, con la nostra offerta stipendi e HR Odoo.

Mantenere uno sviluppo nel tempo

Uno sviluppo consegnato non è uno sviluppo terminato. Vive con il resto del sistema e deve restare compatibile con le sue evoluzioni. È un punto che i progetti guidati solo dalla messa in produzione iniziale trascurano spesso: il costo di uno sviluppo non si misura solo alla consegna, ma a quanto costa mantenerlo su più versioni successive.

• Aggiornamenti di versione: ogni nuova versione maggiore di Odoo può modificare API, modelli o viste su cui si appoggia un modulo su misura. Un modulo ben concepito, senza modifiche ai moduli standard, limita questo rischio senza eliminarlo. Vedere la nostra offerta migrazione Odoo.
• Debito tecnico: ogni sviluppo aggiunto aumenta la superficie da mantenere. Uno sviluppo non documentato, non testato o ridondante con lo standard diventa un onere che si accumula.
• Test di non regressione: verificare, a ogni aggiornamento, che gli sviluppi esistenti continuino a funzionare come previsto.
• Documentazione: registrare cosa è stato sviluppato, perché e secondo quali regole di business, affinché un altro sviluppatore possa riprendere il lavoro senza dover indovinare le intenzioni originarie.
• Reversibilità: uno sviluppo deve poter essere disattivato o rimosso senza compromettere il resto del sistema, qualora l'esigenza che lo ha motivato venga meno.

Questo monitoraggio nel tempo rientra nella nostra offerta di supporto Odoo, che copre sia i moduli standard sia gli sviluppi realizzati da AX-Fiduciaire.

Riprendere uno sviluppo esistente realizzato da un altro fornitore

Interveniamo anche su sviluppi Odoo realizzati da un fornitore precedente, che si tratti di correggere un'anomalia, preparare un aggiornamento di versione o riprendere la manutenzione di un sistema il cui fornitore originario non è più disponibile. Questa ripresa inizia sempre con un'analisi del codice esistente: cosa fa realmente, come è stato costruito, se modifica moduli standard o se vive in moduli separati, e quali rischi presenta per i futuri aggiornamenti di versione.

Questa analisi può mostrare che uno sviluppo esistente è solido e merita di essere conservato così com'è, che deve essere documentato prima di qualsiasi ulteriore intervento, o che deve essere parzialmente rivisto perché modifica direttamente moduli standard o aggira una regola contabile. In ogni caso, la ripresa avviene sulla base di ciò che esiste, non di una riscrittura sistematica.

Questo tipo di intervento è frequente dopo un aggiornamento di versione che rivela sviluppi diventati incompatibili, o quando uno sviluppo che tocca la contabilità o gli stipendi è stato realizzato da un fornitore senza expertise fiduciaria e deve essere verificato nel merito, non solo nella forma del codice.

Cosa AX-Fiduciaire non farà

Questi limiti vengono posti fin dalla definizione dell'esigenza, non scoperti a progetto in corso.

• Sviluppare ciò che lo standard copre già. Se una configurazione, un'opzione nativa o un modulo OCA esistente risponde all'esigenza, non proponiamo uno sviluppo su misura al suo posto.
• Aggirare una regola contabile, fiscale o salariale tramite codice. Uno sviluppo non serve mai a produrre un risultato che si discosta dal piano contabile, dalle posizioni IVA o dai requisiti Swissdec applicabili.
• Consegnare senza test. Uno sviluppo che tocca dati gestionali passa per test funzionali e test di non regressione prima della messa in produzione, senza eccezioni.