Pianificare il flusso di dati tra shop, ERP e contabilità: verificare le interfacce

Quando lo shop cresce e i flussi di dati non tengono il passo

Gli shop online in crescita affrontano gli stessi problemi: i processi manuali in magazzino, negli acquisti e nella fatturazione richiedono tempo e sono soggetti a errori. Manca una trasparenza in tempo reale su giacenze, movimenti di magazzino e margini. Shop, spedizioni, contabilità e reporting coesistono come strumenti isolati, privi di flussi di dati stabili.

Con volumi gestibili spesso bastano liste Excel, flussi di lavoro manuali e interfacce instabili. Con l'aumento degli ordini, dei prodotti e dei canali di vendita aggiuntivi, i requisiti per processi, magazzino e contabilità crescono significativamente. I sistemi con possibilità di estensione limitate nei processi, nelle integrazioni o nelle strutture dati diventano un collo di bottiglia.

È decisivo stabilire se l'ERP automatizzi proattivamente i processi o si limiti a gestire gli ordini. Le risposte non arrivano dalle liste delle funzionalità, ma dai propri flussi di dati: direzione, frequenza e trigger di ogni scambio.

Nel confronto, oltre a funzionalità, automazione e scalabilità, rientrano anche la logica dei prezzi e la struttura dei costi. In questa catena, la contabilità non è un sottoprodotto, ma un destinatario autonomo dei dati.

Come sistemi ERP per tali configurazioni figurano, tra gli altri, SAP, MS Business Central, ProMode e SelectLine. Billbee e Afterbuy vengono spesso impiegati in setup standardizzati e supportano i processi fondamentali legati agli ordini e alle spedizioni; plentyONE si concentra sul collegamento di più marketplace e canali di vendita.

Dal lato della contabilità, quale destinatario, vige un regime di formati specifico: la fattura QR è in circolazione dal giugno 2020 e ha definitivamente sostituito i bollettini di versamento svizzeri il 1° ottobre 2022. I documenti che vi arrivano seguono quindi prescrizioni diverse rispetto agli ordini nello shop.

Chi possiede quali dati? Chiarire le responsabilità prima della tecnica

Prima di qualsiasi tecnologia di interfaccia viene la responsabilità: per ogni tipo di dato esiste esattamente una fonte. I dati anagrafici dei prodotti risiedono nell'ERP, gli aggiornamenti dello stato degli ordini provengono dallo shop.

Ne derivano le direzioni del flusso. I dati dei prodotti, i prezzi e le giacenze vanno dall'ERP allo shop. Gli ordini, le modifiche di stato e le registrazioni di nuovi clienti fluiscono dallo shop all'ERP e parzialmente viceversa.

Nell'esempio di SIGVARIS, lo shop si basa su Magento Commerce ed è concepito come shop B2B: solo un utente registrato può effettuare ordini. I prodotti vengono importati da SAP tramite XML e assegnati al rispettivo shop nazionale tramite un attributo univoco, con una dimensione temporale «da» e «fino a» per ogni Paese.

La registrazione di un nuovo cliente nello shop viene trasmessa a SAP, dove viene assegnato a un gruppo di clienti e aggiornato al successivo allineamento dei dati clienti nello shop. Da quel momento, il cliente può ordinare con login e password.

La doppia inserzione nasce quando lo stesso tipo di dato viene gestito in due sistemi – per prezzi, giacenze e dati indirizzi. Se manca un proprietario definito, le correzioni vengono effettuate in due luoghi e i sistemi divergono. Se il proprietario è stabilito, è chiaro quale lato di un'interfaccia può scrivere e quale può solo leggere.

Per le integrazioni Shopify vale concretamente questa regola: i dati anagrafici dei prodotti risiedono nell'ERP, gli aggiornamenti dello stato degli ordini provengono da Shopify. Un'unica fonte per tipo di dato previene la doppia gestione.

Alla sovranità sui dati anagrafici appartengono anche le regole sulle quantità: la quantità minima d'ordine di un prodotto è identica in tutti gli shop nazionali di SIGVARIS. Tali valori appartengono alla fonte principale, l'ERP, altrimenti dovrebbero essere aggiornati singolarmente per ogni shop nazionale.

Dall'ingresso dell'ordine al documento contabile: registrare il flusso di dati

Il primo passo è un'analisi dello stato attuale (IST-Aufnahme). Vengono esaminati congiuntamente il panorama dei sistemi attuale e la configurazione ERP esistente. Tutti i flussi di dati vengono mappati e i requisiti di integrazione definiti. Si documenta quale informazione deve essere scambiata, quando e tra quali sistemi.

Da registrare sono almeno: ordini e stati degli ordini, dati clienti e indirizzi, giacenze e movimenti di magazzino, prezzi, aggiornamenti dei prodotti, fatturazione nonché il trasferimento dei documenti alla contabilità.

Per ogni flusso di dati vengono fissate quattro indicazioni: causa di avvio (evento o intervallo di tempo), direzione, ritmo e formato. Per i dati dei prodotti si aggiunge se valgano specificamente per Paese o canale e se abbiano un periodo di validità. Presso SIGVARIS i prodotti vengono assegnati allo shop nazionale tramite un attributo univoco e gestiti con «da» e «fino a» per ogni Paese.

Il trasferimento alla contabilità è un flusso di dati a sé stante. Viene registrato con causa di avvio, direzione, ritmo e formato, come qualsiasi altro flusso. Per gli shop con focus sulla gestione merci e sulla contabilità, SelectLine viene spesso scelto; i processi di e-commerce vengono integrati come parte del sistema complessivo.

Per il trasferimento dei documenti, la Svizzera impone un formato: la fattura QR consiste in una sezione pagamento e in una ricevuta; lo Swiss QR Code contiene tutte le informazioni di pagamento in forma digitale. Le linee guida si rivolgono agli emittenti di fatture, agli istituti finanziari e agli sviluppatori di software per emittenti e destinatari di fatture.

Il campo «Informazioni sulla fattura» integra le usuali informazioni di pagamento e permette al software aziendale del destinatario della fattura di automatizzare l'assegnazione e la verifica della fattura. La definizione sintattica (S1) è definita e mantenuta dal gruppo di lavoro ERP di Swico; Swico mette a disposizione il validatore.

Come ulteriori vie nel traffico dei pagamenti sono disponibili eBill – la specifica per l'utilizzo della procedura alternativa nello Swiss QR Code, versione 1.1 del 3 febbraio 2020 – e i messaggi cliente-banca per i bonifici (pain.001), versione 2.9 del 20 novembre 2020.

Le versioni rientrano nella pianificazione: le Implementation Guidelines svizzere per la fattura QR versione 2.3 sono valide dal 22 novembre 2025. La versione 2.4 sarà valida dal 14 novembre 2026; l'indirizzo strutturato (tipo di indirizzo «S») è previsto per novembre 2026.

I dati dei documenti strutturati aumentano il grado di automazione della contabilità fornitori, poiché molti dati possono essere letti dallo Swiss QR Code. Run my Accounts legge la contabilizzazione e il pagamento e carica il pagamento nell'E-Banking per l'approvazione da parte del cliente.

Chi coinvolge la contabilità solo dopo l'integrazione, pianifica un flusso senza punto di arrivo. Per questo motivo, il trasferimento dei documenti figura fin dall'inizio dell'analisi dello stato attuale nell'elenco dei flussi di dati.

Il risultato è un'analisi dello stato attuale documentata. Essa funge successivamente da base di confronto: solo con essa si può valutare se una nuova integrazione elimini effettivamente un collo di bottiglia o lo sposti semplicemente.

Verificare le interfacce: API, scambio di file e ritmo di sincronizzazione

Per il collegamento di uno shop a un ERP esistono due varianti di base. L'API nativa del sistema shop collega lo shop direttamente all'ERP; viene implementata tramite soluzioni standard preconfigurate o un connettore sviluppato individualmente. In alternativa, formati di file strutturati – solitamente XML – vengono scambiati periodicamente via FTP con push e pull.

Lo scambio di file conosce due modalità operative combinabili. Durante il giorno si esporta in modo incrementale a brevi intervalli – ad esempio ogni ora – di notte segue un'esportazione completa. Questa procedura è considerata molto robusta e tollerante agli errori.

È adatta per file di medie dimensioni, ad esempio per 5 fino a 10'000 clienti e da 10 a 30'000 prodotti. I brevi intervalli mantengono i dati aggiornati, l'esportazione completa notturna corregge le deviazioni accumulate durante il giorno. Lo svantaggio: non è in tempo reale e un errore in un'esecuzione ha effetto fino alla successiva.

Come modello aggiuntivo si aggiunge la sincronizzazione basata su intervalli. Essa mantiene la giacenza nello shop precisa e aggiorna i dati degli ordini nell'ERP senza ritardi.

Il collegamento può essere unidirezionale o bidirezionale. Presso SIGVARIS AG il processo di ordinazione è stato collegato completamente e bidirezionalmente a SAP. L'evasione degli ordini è così automatizzata al 100 percento – con oltre 17'000 articoli nello shop.

Come regola empirica per la scelta vale: modifiche granulari vicine all'evento, come i cambi di stato dei singoli ordini, parlano a favore dell'API. Grandi volumi di dati anagrafici parlano a favore dello scambio periodico di file.

Shopify mette a disposizione un'API nativa per questo scopo. what.digital integra Shopify nei sistemi ERP tramite questa API, sia con soluzioni standard preconfigurate sia con un connettore sviluppato individualmente.

Next AG punta per le interfacce SAP su formati di file strutturati, solitamente XML, che vengono scambiati periodicamente via FTP con push e pull. Durante il giorno si esporta in modo incrementale a brevi intervalli, di notte segue un'esportazione completa.

DevQon GmbH sviluppa interfacce bidirezionali tra Magento e i sistemi centrali.

Alla verifica delle interfacce appartiene anche il percorso dei documenti: lo Swiss QR Code come formato, il campo «Informazioni sulla fattura» e la definizione sintattica (S1), mantenuta dal gruppo di lavoro ERP di Swico. Essa corre parallelamente all'interfaccia degli ordini e dei prodotti e viene collaudata separatamente.

Da verificare sono quindi tre modelli e le loro combinazioni: l'API nativa, lo scambio periodico di file via FTP e la sincronizzazione basata su intervalli. Quale modello regga, lo decidono il volume e il tipo di modifica – non la lunghezza di una lista di funzionalità.

Prima dello sviluppo: analizzare documentazione API e strutture dati su entrambi i lati

L'analisi delle interfacce è un passaggio di lavoro a sé stante prima dello sviluppo. Vengono analizzati il sistema ERP, la documentazione API e le strutture dati su entrambi i lati. Il risultato è un piano architettonico concreto con flussi di dati chiari, che i responsabili vedono e approvano prima di ogni sviluppo.

Vengono fissate le assegnazioni dei campi tra le strutture dello shop e dell'ERP, i campi obbligatori e gli intervalli di valori ammessi, le risposte di errore dell'API nonché il momento del collaudo. DevQon GmbH analizza il sistema ERP, la documentazione API e le strutture dati su entrambi i lati; questa analisi delle interfacce è gratuita e non vincolante. Indipendentemente da ciò, il passo è economico rispetto allo sviluppo successivo.

Il vantaggio sta negli errori che emergono qui e che costerebbero denaro in seguito: un campo che non esiste nell'ERP, una modifica di stato che lo shop non riporta indietro, o un tipo di dato per cui due sistemi sono stati assunti contemporaneamente come principali. Se si sviluppa senza questa verifica, le ipotesi sulle strutture dati diventano la base del codice. Le correzioni successive diventano di conseguenza più costose.

Dal lato dei documenti, la stessa analisi verifica l'assegnazione dei campi delle informazioni sulla fattura secondo la definizione sintattica (S1). Per la migrazione della fattura QR, ad esempio verso l'indirizzo strutturato, SIX mette a disposizione schede informative; SIX gestisce inoltre un portale di validazione, Swico il validatore per la definizione sintattica (S1).

L'approvazione del piano architettonico prima dello sviluppo è parte integrante della procedura. Chi verifica le strutture dati solo nel codice, paga la correzione in seguito.

Definire l'architettura di integrazione e il piano di progetto

Dall'analisi derivano l'architettura di integrazione e un piano di progetto dettagliato con milestone chiare e scadenze fisse. Codice e documentazione vengono archiviati centralmente e versionati – ad esempio in un repository GitHub. In questo modo ogni modifica rimane tracciabile e non esiste solo sul computer di una singola persona.

In Svizzera si tratta perlopiù di piccole e medie imprese con panorami di sistemi cresciuti organicamente. I sistemi ERP diffusi vengono collegati tramite soluzioni standard preconfigurate o connettori individuali. Lo spettro va dalle installazioni SAP presso le grandi aziende fino a soluzioni flessibili per le PMI.

La modalità operativa dell'ERP rientra nella decisione architetturale. Se l'ERP viene offerto esclusivamente come soluzione SaaS e utilizzato tramite browser, non è necessaria un'installazione locale; i percorsi dei file e i servizi server nella propria rete non sono allora disponibili per lo scambio. Se l'ERP gira localmente, lo scambio periodico di file può essere gestito sui propri sistemi. Questa questione decide insieme se API, scambio di file o una combinazione siano sensate.

Oltre a SAP figurano, tra gli altri, MS Business Central, ProMode e SelectLine. ProMode viene offerto esclusivamente come soluzione SaaS ed è utilizzabile tramite browser senza installazione locale; i clienti si trovano, tra l'altro, in Svizzera. I clienti del dettaglio gestiscono web shop collegati a ProMode tramite interfacce.

SelectLine viene spesso scelto quando il focus è sulla gestione merci e sulla contabilità; i processi di e-commerce fanno parte del sistema complessivo. Billbee e Afterbuy supportano in setup standardizzati i processi fondamentali legati agli ordini e alle spedizioni; plentyONE si concentra sul collegamento di più marketplace e canali di vendita.

La fatturazione rientra nella stessa decisione architetturale: se si fattura nell'ERP, il software deve supportare la versione valida delle Implementation Guidelines per la fattura QR. Dal 22 novembre 2025 vale la versione 2.3, dal 14 novembre 2026 la versione 2.4.

Sistemi ERP a confronto: punti di forza e ambiti di impiego

Test, go-live e esercizio: pianificare casi di errore e formazione

Dopo lo sviluppo si testa prima internamente secondo un processo QA definito. Segue la fase di test presso l'azienda stessa, con supporto nella risoluzione degli errori. Solo quando i test confermano che tutto funziona come desiderato, l'integrazione viene rilasciata. Da quel momento vengono monitorati prestazioni, affidabilità e sicurezza.

Al go-live appartengono una documentazione completa dell'integrazione e formazioni per il team, affinché i flussi di dati rimangano verificabili nella quotidianità.

Verificabile significa concretamente: nell'esercizio devono essere riconosciuti un guasto del sistema e un'esportazione interrotta. Prima del go-live vengono nominati i casi di errore: ordine non arrivato, chiamata API fallita, esecuzione FTP interrotta, giacenze contraddittorie tra shop ed ERP. Inoltre si stabilisce chi li riconosce, come riavviare un'esecuzione e come allineare i dati dopo un guasto. L'esportazione completa notturna ripulisce le deviazioni accumulate.

Dal lato dei documenti si aggiungono casi di errore specifici: una fattura le cui informazioni sulla fattura non possono essere assegnate dal software di contabilità, o una validazione che fallisce a causa della versione delle linee guida. SIX mette a disposizione un portale di validazione, Swico un validatore per la definizione sintattica (S1).

what.digital esegue sviluppo e test internamente secondo un processo QA, passa poi alla fase di test e supporta nella risoluzione degli errori. Dopo i test superati, l'integrazione viene rilasciata e vengono monitorati prestazioni, affidabilità e sicurezza.

Punti di controllo per la propria pianificazione