Guide pratiche

Come Personalizzare un Gestionale Senza Perdere gli Aggiornamenti

Hai personalizzato il gestionale, poi aggiornamento e tutto rotto. Vediamo come avere personalizzazioni che sopravvivono agli aggiornamenti.

Team Ingenia 09 May 2026
Come Personalizzare un Gestionale Senza Perdere gli Aggiornamenti

Hai pagato 30.000€ di personalizzazioni sul tuo gestionale 5 anni fa. Vendor rilascia aggiornamento. Personalizzazioni rotte. Rifare = altri 30.000€. Oppure stai sulla versione vecchia per sempre. Vediamo come uscire da questa trappola.

Perché succede

Personalizzazione "invasiva"

Sviluppatore ha modificato direttamente i sorgenti del gestionale: file modificati, tabelle aggiunte, query cambiate. Quando vendor aggiorna i suoi sorgenti, le tue modifiche vengono sovrascritte o entrano in conflitto.

Mancanza di architettura modulare

Gestionale anni '90/2000 non era pensato per estensioni. Era monolitico. Modificare = mettere mani nel motore.

Vendor che non collabora

Vendor non ha API ufficiali, non documenta hook, non considera personalizzazioni come parte del prodotto.

L'architettura corretta

1. API stabili

Vendor espone API REST/GraphQL per leggere e scrivere dati. Le API sono versionate: v1 continua a funzionare anche quando v2 esce. Personalizzazione usa solo API → sopravvive ad aggiornamenti.

2. Hook e eventi

Gestionale notifica eventi: "fattura creata", "ordine confermato", "anagrafica modificata". Tu scrivi codice che reagisce. Codice in modulo separato. Aggiornamento gestionale non tocca i tuoi moduli.

3. Configurazione vs codice

Molte personalizzazioni sono configurazioni, non codice:

  • Layout PDF fattura.
  • Campi anagrafica aggiuntivi.
  • Flussi approvazione.
  • Notifiche, alert.

Configurate da pannello admin, non da sviluppo. Persistono ad aggiornamenti.

4. Tabelle separate

Hai bisogno di nuove entità (es. "ispezioni qualità custom")? Le metti in tabelle separate. Non modifichi quelle del gestionale. Aggiornamento gestionale = zero impatto.

5. Frontend componibile

Aggiungere widget, dashboard, viste? Frontend a componenti che si registrano. Tuo componente in plugin, non in sorgenti core.

Esempi pratici

Esempio 1: Notifica WhatsApp a cliente quando ordine spedito

Modo sbagliato: modificare codice spedizione del gestionale.

Modo corretto: registrare hook su evento "DDT emesso". Hook chiama API WhatsApp Business. Codice in plugin separato. Aggiornamento gestionale: zero impatto.

Esempio 2: Campo "Lotto cliente" su anagrafica

Modo sbagliato: aggiungere colonna a tabella clienti del gestionale.

Modo corretto: usare sistema "campi personalizzati" del gestionale (configurazione, non codice).

Esempio 3: Report custom "marginalità per agente per zona"

Modo sbagliato: modificare moduli report del gestionale.

Modo corretto: usare Reportistica e KPI self-service.

Esempio 4: Integrazione con e-commerce esterno

Modo sbagliato: trafilare dati direttamente nel DB.

Modo corretto: API REST del gestionale → connettore in middleware esterno → e-commerce. Standardizzato, manutenibile.

Quando serve sviluppo vero

Alcune personalizzazioni richiedono sviluppo dedicato (no configurazione possibile). Esempi:

  • Workflow complesso specifico settore.
  • Integrazione con macchinario proprietario.
  • Algoritmo di calcolo unico (es. pricing dinamico complesso).
  • UI custom dedicata a operatore specializzato.

Architettura giusta per sviluppo custom

  • Modulo in plugin separato (non fork core).
  • Codice in repository git separato.
  • Test automatici.
  • Documentazione.
  • Compatibilità versioni gestionale dichiarata.

Approccio Gestya

Modulo Personalizzazione e Sviluppi Custom:

  • API REST documentate per ogni entità.
  • Webhook su 50+ eventi sistema.
  • Campi personalizzati configurabili su tutte le anagrafiche.
  • Workflow engine: regole di approvazione e notifica configurabili da admin.
  • Plugin SDK: per sviluppi dedicati, framework per non toccare il core.
  • Garanzia: personalizzazioni sviluppate da Ingenia rimangono compatibili con aggiornamenti futuri.

Cosa chiedere al vendor prima di firmare

  1. API documentate per tutte le entità?
  2. Garanzia retrocompatibilità API per quanti anni?
  3. Eventi/webhook esposti?
  4. Sistema "campi custom" configurabile?
  5. Plugin in moduli separati?
  6. Aggiornamenti rompono personalizzazioni? (la risposta deve essere "no").

Conclusione

Personalizzazione che invecchia bene = architettura estensibile fin dall'inizio. Modulo Personalizzazione Gestya garantisce che i tuoi investimenti su sviluppi custom rimangano vivi negli anni.

Pronto a trasformare il tuo business?

Raccontaci il tuo progetto. Ti risponderemo entro 24 ore.