Come si integrano davvero i moduli di un ERP

La parola «integrato» nasconde tre cose diverse

Quasi ogni brochure di un ERP usa la parola «integrato». Sotto di essa si celano almeno tre soluzioni che si comportano in modo molto diverso quando qualcosa va storto alla chiusura mensile. La prima è il trasferimento di file o batch programmato: un sistema esporta, un altro importa, di solito di notte. La seconda è la sincronizzazione tramite API o middleware, in cui due database separati restano allineati scambiandosi messaggi. La terza sono i dati realmente condivisi, in cui i moduli non sono sistemi separati ma viste diverse su un unico insieme di tabelle, un’unica contabilità generale e un unico insieme di anagrafiche.

Nessuna di queste soluzioni è giusta in assoluto. Il trasferimento batch è economico, facile da capire e sopravvive a un’interruzione su uno dei due lati, perché il file semplicemente aspetta. È però sempre in ritardo per costruzione, e un’elaborazione fallita può passare inosservata finché qualcuno non mette in dubbio un report. La sincronizzazione via API offre un comportamento quasi in tempo reale e consente di mantenere sistemi che avete buone ragioni per tenere, ma a quel punto gestite un sistema distribuito: tentativi ripetuti, ordine dei messaggi, errori parziali e due copie della verità che possono non concordare. I dati condivisi eliminano l’intera categoria di problemi in cui due database divergono, perché ce n’è uno solo, ma impongono ai moduli di adottare un unico piano dei conti, un’unica definizione degli articoli e un unico ritmo di rilascio, il che è un vincolo e non un vantaggio gratuito.

La domanda pratica non è quale livello sia il migliore, ma quale livello meriti ciascun flusso. Il trasferimento notturno di un estratto conto bancario va benissimo. Il trasferimento notturno delle giacenze dietro un punto vendita attivo no. Skyline Nexus si colloca al terzo livello per i propri moduli: contabilità, punto vendita e magazzino, CRM, manutenzione, risorse umane, flotta e cespiti scrivono in un’unica contabilità e in un unico insieme di anagrafiche, e si integrano verso l’esterno tramite API quando un cliente dispone già di un sistema che vale la pena mantenere.

La divergenza comincia dalle anagrafiche

Dei fallimenti d’integrazione si incolpano di solito le interfacce, ma la prima crepa è normalmente un’anagrafica che esiste due volte con contenuti leggermente diversi. Quando due sistemi tengono ciascuno il proprio elenco clienti, gli elenchi divergono nel giro di settimane, e ogni dato a valle eredita la divergenza.

• Cliente: un’unica identità per vendite, fatturazione, incassi e controllo del credito, altrimenti lo scadenziario clienti non concorderà con il report delle vendite.
• Fornitore: condiviso tra acquisti, contabilità fornitori e pagamenti, coordinate bancarie comprese, che sono un bersaglio di frode quando sono duplicate.
• Articolo: un codice, un’unità di misura, un metodo di valorizzazione. Due anagrafiche articoli significano due valorizzazioni di magazzino.
• Piano dei conti: una sola struttura. Se un modulo tiene un proprio elenco di conti e lo mappa sul vostro, la mappatura è una seconda cosa da mantenere e da sbagliare.
• Codici IVA: un’unica definizione di aliquota, trattamento e date di validità, usata sia dall’operazione sia dalla dichiarazione.
• Filiale e ubicazione: condivise, perché sia il magazzino sia la contabilità sono articolati per filiale.
• Dipendente: un’unica scheda dietro paghe, presenze, ordini di lavoro di manutenzione e assegnazione dei veicoli.
• Cespite: un unico registro dietro ammortamento, storia della manutenzione e dismissione.

Contabilità sezionali e conto di controllo

La contabilità generale contiene saldi riepilogativi. Il dettaglio sta nelle contabilità sezionali, e ciascuna è collegata a un conto di controllo del libro mastro. La contabilità clienti contiene una riga per ogni fattura e ogni incasso, la cui somma corrisponde al conto di controllo crediti verso clienti. La contabilità fornitori fa lo stesso per le fatture passive. I movimenti di magazzino confluiscono in un conto di controllo delle rimanenze, con il costo del venduto rilevato all’uscita della merce. Le paghe registrano retribuzioni lorde, contributi a carico del datore di lavoro, trattenute e debiti netti. I cespiti registrano acquisizioni, ammortamenti e dismissioni su costo storico e fondo ammortamento. Il punto vendita registra vendite, imposta riscossa, mezzi di pagamento e, dove si adotta l’inventario permanente, la componente di costo di ogni vendita.

La regola che rende affidabile tutto questo è semplice: la contabilità sezionale deve sempre riconciliarsi con il proprio conto di controllo, fino all’unità di valuta. Se lo scadenziario clienti indica un importo e il conto di controllo crediti un altro, uno dei due è sbagliato e non si può sapere quale senza un’indagine. È per questo che le registrazioni dirette nei conti di controllo sono normalmente bloccate. Una scrittura manuale nei crediti crea un saldo che nessun cliente deve, e non comparirà in nessun estratto conto che invierete.

La riconciliazione dovrebbe essere un report da eseguire su richiesta, non un foglio di calcolo tenuto da qualcuno. Quando i moduli condividono un’unica contabilità, la riconciliazione è quasi tautologica. Quando non la condividono, è il controllo più importante che si possa automatizzare.

Regole di registrazione e traccia di revisione

Ogni riga contabile deve poter essere ricondotta a un documento di origine: un numero di fattura, un carico di magazzino, un’elaborazione delle paghe, un piano di ammortamento, un’operazione del punto vendita. Se esiste una riga senza origine, qualcuno ha aggirato il processo. L’identificativo del documento deve viaggiare con la riga contabile, non stare in una tabella di corrispondenza separata.

Le scritture registrate non devono essere modificabili in silenzio. Le correzioni si fanno con scritture di storno o note di credito, che lasciano visibili sia l’originale sia la correzione, ciascuna con le proprie date e il proprio utente. La chiusura del periodo deve bloccarlo, anziché affidarsi alla memoria di chi non deve retrodatare. La prova è poter prendere qualsiasi saldo, aprirlo e risalire ai documenti che lo hanno generato senza uscire dal sistema.

Dove le integrazioni si rompono davvero

Le modalità di guasto sono note e quasi sempre le stesse.

• Tempi e competenza: una vendita registrata poco prima della mezzanotte dell’ultimo giorno del periodo arriva nell’altro sistema dopo il cut-off, così i due periodi non coincidono mai.
• Elaborazioni fallite che nessuno sorveglia: un trasferimento programmato smette di girare e l’assenza di dati sembra una settimana tranquilla.
• Scritture parziali: la testata della fattura viene creata, le righe falliscono, e un lato contiene ora un documento che l’altro non riconosce.
• Chiavi duplicate: un messaggio ritrasmesso crea una seconda copia della stessa fattura, oppure una numerazione collide tra filiali.
• Scostamenti di cambio e arrotondamento: due sistemi che arrotondano in punti diversi, o usano cambi diversi per lo stesso giorno, producono piccole differenze che si accumulano.
• Imposta calcolata due volte: il sistema delle operazioni e quello contabile calcolano ciascuno l’imposta, con regole leggermente diverse su sconti, prezzi IVA inclusa o arrotondamento per riga anziché per documento. La fattura consegnata al cliente e il dato nella dichiarazione finiscono per non coincidere.

Idempotenza e prova che i due lati concordano

Tutto ciò che può essere ritentato verrà ritentato, quindi ogni operazione di registrazione ha bisogno di una chiave stabile derivata dal documento di origine. Inviare due volte la stessa fattura deve produrre una registrazione, non due. Il lato ricevente deve annotare quali chiavi ha già elaborato e restituire il risultato precedente anziché crearne uno nuovo. Senza questo, il normale comportamento della rete si trasforma in ricavi duplicati.

Accanto a ciò serve la riconciliazione come funzione a pieno titolo: conteggi e totali per periodo e per tipo di documento, confrontati sui due lati, con le differenze elencate anziché riassunte. Una spunta verde che dice soltanto che l’ultima elaborazione è andata a buon fine non prova alcuna concordanza. Il report utile è quello che nomina i sette documenti presenti su un lato e non sull’altro.

Filiali e valute

Operare con più filiali significa che ogni operazione porta con sé la propria sede come dimensione fin dal momento in cui viene creata, non assegnata dopo dalla logica di un report. Giacenze, ricavi, costi e personale appartengono tutti a una filiale, e i trasferimenti tra filiali richiedono che entrambi i lati siano registrati, altrimenti le giacenze delle due filiali non sommeranno al dato aziendale. La numerazione dei documenti deve essere univoca tra filiali pur restando significativa all’interno di ciascuna.

La multivaluta richiede che sulla riga siano memorizzati la valuta dell’operazione, il cambio applicato e l’importo in valuta di conto. Memorizzare soltanto il valore convertito cancella la prova. La valutazione dei saldi aperti e le differenze di cambio realizzate all’incasso o al pagamento hanno così un posto in cui essere registrate, e la differenza di cambio smette di essere un mistero di arrotondamento.

Nota regionale: la liquidazione preventiva cambia i tempi

Dove si applica un regime di fatturazione elettronica, i tempi dell’integrazione smettono di essere una preferenza progettuale. Diverse amministrazioni fiscali richiedono ormai che le fatture siano autorizzate o comunicate all’amministrazione prima o nel momento in cui raggiungono l’acquirente. Il regime ZATCA in Arabia Saudita ne è un esempio attuale: le fatture sono generate con una struttura definita, elementi crittografici e identificativi, e l’amministrazione interviene nel ciclo di vita del documento anziché ricevere un riepilogo a posteriori. Ciò fa dell’emissione della fattura un problema di integrazione in tempo reale. Un batch notturno non può produrre un documento che il cliente sta aspettando alla cassa.

Altrove il quadro è diverso, e conviene essere precisi. Gli Stati Uniti non hanno un obbligo federale di fatturazione elettronica, e l’imposta sulle vendite è amministrata a livello statale, con regole e aliquote che variano da Stato a Stato e spesso da una giurisdizione locale all’altra. Il Canada applica GST e HST a livello federale con variazioni provinciali, comprese imposte provinciali sulle vendite in alcune province. Gli altri mercati dell’area MENA sono a stadi diversi. La lezione progettuale è tenere la determinazione dell’imposta e l’emissione del documento in un unico punto, così che un mercato che passa dalla comunicazione all’autorizzazione preventiva richieda un cambio di configurazione e non di architettura. Skyline Nexus gestisce l’autorizzazione ZATCA dalla stessa operazione che scrive la registrazione contabile, per cui la fattura ricevuta dal cliente e il dato nella dichiarazione provengono da un unico calcolo.