Integrare automazioni AI con Zucchetti, TeamSystem ed ERP custom

Premessa: l'integrazione è il 60% del progetto

In una PMI manifatturiera italiana, il modello AI è la parte facile. Connetterlo al gestionale che gira da 15 anni è il vero progetto.

Il motivo è semplice: i gestionali italiani sono stati pensati per durare 20 anni con la stessa user experience, non per essere consumati da agenti AI. I dati sono lì, ma sono dietro un firewall, dentro un database SQL Server o Oracle, accessibili attraverso interfacce che non sempre sono documentate in modo standard.

Questa pagina è una mappa pratica dei pattern di integrazione che funzionano. Niente teoria, solo "cosa abbiamo visto girare in produzione" e "cosa evitare".

Il primo principio: leggere prima di scrivere

In ogni progetto, separate sempre due fasi:

Fase 1: solo lettura. L'automazione AI legge dati dal gestionale. Niente write-back. Tipico per: reportistica, scoring, classificazione, narrative scritte dal modello.

Fase 2: write-back. L'automazione scrive dati nel gestionale. Tipico per: anagrafiche, ordini, riconciliazioni, ticket di assistenza.

Buona parte del valore arriva dalla fase 1. Dovete fare la fase 2 solo quando la fase 1 è stabile e validata. Mai partire da write-back: il rischio di sporcare il gestionale è troppo alto e il rollback è doloroso.

Pattern di integrazione: Zucchetti

Zucchetti ha una offerta articolata su più linee di prodotto. Le più diffuse nelle PMI manifatturiere italiane sono la famiglia Mago (Mago4, MagoWeb) e la famiglia Ad Hoc (Ad Hoc Revolution, Ad Hoc Revolution Web, Ad Hoc Enterprise, Ad Hoc Infinity).

Le modalità di integrazione variano per linea e versione: alcuni prodotti espongono webservice REST/SOAP, altri richiedono accesso al database o file di scambio, altri ancora hanno API più moderne nelle versioni cloud.

Pattern consigliato:

Chiedete al vostro partner Zucchetti la documentazione delle interfacce esposte dal vostro specifico prodotto e versione. Se non la conoscono, va recuperata dal canale Zucchetti centrale.
Configurate un account utente dedicato all'integrazione, con permessi di sola lettura per la fase 1.
Usate un layer intermedio (n8n, Node.js, .NET service) che fa il polling o riceve i webhook, normalizza i dati e li passa al modello AI.
Per fase 2, replicate l'architettura ma con un account scrittura limitato alle sole entità che dovete toccare.

Trabocchetti tipici:

I webservice gestionali italiani sono spesso lenti (1–5 secondi a chiamata). Bufferate e cachate, mai chiamate sincrone in cascata.
Le entità documentali (DDT, fatture) hanno relazioni complesse. Estraete sempre il "documento padre + tutte le righe" in un'unica chiamata, mai riga per riga.
Le date in molti gestionali italiani sono in formato DD/MM/YYYY. Convertitele subito a ISO 8601 in ingresso al vostro pipeline.
Le encoding non sempre sono UTF-8. Verificate prima di processare.

Pattern di integrazione: TeamSystem

TeamSystem ha un'offerta diversificata. Polyedro è la tecnologia di piattaforma su cui si appoggiano vari prodotti gestionali (Lynfa Azienda è uno dei più diffusi nelle PMI). ACG Enterprise è la linea ERP enterprise. Le offerte cloud (TeamSystem Digital e simili) hanno API più moderne, le offerte on-premise tipicamente espongono interfacce più tradizionali.

Pattern consigliato:

Preferite sempre i prodotti TeamSystem cloud se il cliente ha entrambe le opzioni. L'integrazione è significativamente più veloce.
Per i prodotti on-premise, valutate se conviene mettere un connector intermedio sul server cliente o esporre i dati via VPN/SFTP a un layer esterno.
Verificate sempre rate limit e timeout dei webhook prima di disegnare la pipeline. Variano per prodotto e versione.

Trabocchetti tipici:

I webhook di gestionali italiani hanno spesso timeout aggressivi. Se il vostro endpoint impiega più di 5 secondi a rispondere, perdete l'evento. Risposta sincrona deve essere sempre 200 OK rapida, elaborazione asincrona.
I codici fiscali e altri identificativi vengono talvolta restituiti come stringa con padding di spazi. Trim sempre prima di matchare.

Pattern di integrazione: ERP custom o legacy

Qui inizia il divertimento. ERP custom in PMI italiane sono spesso:

AS/400 con database DB2 ancora in produzione
SQL Server o Oracle con stored procedure scritte molti anni fa da consulenti che non ci sono più
Mix di moduli comprati e moduli sviluppati internamente con .NET o VB6

Pattern che funzionano:

Read replica con CDC. Replicate il database gestionale in un database secondario (PostgreSQL, MySQL) con Change Data Capture. La pipeline AI lavora sul replica, mai sul master. Latenza accettabile: 1–5 minuti.
Vista SQL dedicata. Se l'ERP è un database accessibile, create una vista SQL specifica per l'integrazione. Espone solo i campi necessari, già filtrati e normalizzati. Manutenzione minima.
Layer API custom. Costruite un piccolo servizio (Node.js, Python, .NET) che si pone tra il database ERP e il modello AI. Espone REST endpoint puliti. Più lavoro upfront, ma molto più manutenibile.
File drop pattern. L'ERP esporta CSV/XML su una cartella o SFTP a intervalli regolari. Il pipeline AI consuma da lì. Pattern "stupido" ma funziona sempre, anche su sistemi vecchissimi.

Trabocchetti tipici:

Mai connettervi direttamente al database master in scrittura. Sempre un layer applicativo in mezzo, anche se sembra sovra-ingegnerizzato. Il giorno che l'ERP cambia versione, ringrazierete.
Le encoding sono un inferno. AS/400 in EBCDIC, file CSV in CP1252 o ISO-8859-1, ERP custom che mescola UTF-8 e Latin-1 nelle stesse tabelle. Normalizzate tutto a UTF-8 in ingresso.

La domanda che vi farà il vostro IT

"E se l'AI sbaglia e scrive cazzate nel gestionale?"

Risposta: il pipeline ha sempre soglie di confidenza esplicite e una coda di revisione umana. Sotto soglia, l'output non viene mai scritto in automatico. Il responsabile di processo conferma o rifiuta. I log mostrano input e output di ogni esecuzione.

In pratica: la fase 2 (write-back) parte sempre con human-in-the-loop al 100%. Solo dopo settimane di tracciamento, alzate le soglie di automazione per i casi a bassa ambiguità.

Stack che usiamo noi

Per chi vuole il dettaglio tecnico di cosa gira nelle nostre integrazioni:

Orchestrazione: n8n self-hosted su VPS Hetzner. Workflow visuali, ma con Code Node JavaScript per la logica complessa.
Modelli: Claude (Anthropic) e Mistral. Entrambi con clausole API che non addestrano sui dati cliente.
Storage stato: PostgreSQL su stesso VPS, una schema per cliente.
Code custom: Node.js + TypeScript per i connector ai gestionali. .NET dove il cliente ha già tooling .NET in casa.
Hosting: solo EU. Default: Hetzner Helsinki.

Lo stack è meno importante della disciplina di integrazione. Una pipeline pulita su tool semplici batte sempre una pipeline complicata su tool sofisticati.

Quando vale la pena coinvolgerci in fase di scoping

Se il vostro IT sta valutando un'automazione AI ma:

Il gestionale è una versione vecchia di Zucchetti o TeamSystem e nessuno sa dove sono le interfacce
L'ERP è custom e la documentazione è "nella testa di Mario"
Il fornitore AI propone integrazione "nativa" senza specificare come

Vale mezz'ora di call. Ve la spendiamo per dirvi se ha senso, non per venderci. Se il vostro IT è già autonomo, leggete questa pagina con un caffè e amen.

Prenota una call di 15 minuti →