In sintesi
Quando una PMI italiana decide di digitalizzare la tentata vendita sopra SAP Business One, si trova davanti a due famiglie architetturali: una in cui SAP B1 resta l’unica fonte di verità (è la scelta di MTF.Sales.Suite, che combina cache locale per l’offline e API gateway proprietario sul server cliente), e una in cui un secondo database completo replica B1 e diventa la sorgente per l’app mobile. La differenza non è solo tecnica: impatta l’allineamento dei dati visti dall’agente, il modo in cui passa la fattura elettronica, i costi di licenza ricorrenti e i tempi di messa in produzione. Questo articolo spiega le due architetture senza brochure e dà le domande giuste da fare al fornitore prima di firmare.
Cos’è la tentata vendita su SAP B1
La tentata vendita è la vendita effettuata direttamente da un agente con merce a bordo del mezzo: l’agente arriva dal cliente, propone, vende, consegna, fattura e incassa nello stesso momento. Convive con due processi affini ma diversi: la prevendita (raccolta ordini in mobilità senza consegna immediata) e il fattorinaggio (consegna di merce già ordinata, con prova di consegna).
Tre cose rendono questo scenario molto più esigente di un CRM mobile classico:
- L’agente lavora spesso in zone con copertura cellulare scarsa, quindi serve modalità offline vera, non un fallback degradato.
- Listini multi-cliente, scontistica plurivocale, scadenzario aperto: l’agente ha bisogno di vedere il dato giusto al momento giusto, sennò promette qualcosa di sbagliato.
- La parte fiscale italiana (DDT, fattura accompagnatoria, fattura elettronica via SDI, lotti FEFO per food e farma) non ammette improvvisazione architetturale.
L’asse vero: dove vive la fonte di verità
La distinzione che conta non è “service layer diretto vs middleware” — qualunque applicazione enterprise seria ha qualche componente server-side per autenticazione, business logic, rate-limiting. La distinzione vera è un’altra:
Dove vivono ordini, anagrafiche, listini, scadenzari? In un solo posto (il database SAP Business One) oppure duplicati in un secondo database che vive di vita propria?
Questa è la domanda da fare in selezione fornitore. Risponderla onestamente svela due famiglie architetturali ben diverse, con conseguenze concrete.
Architettura “single source of truth”: SAP B1 resta l’unica fonte
Nelle architetture pulite (è la categoria in cui rientra MTF.Sales.Suite) il database SAP Business One rimane l’unica fonte di verità per dati transazionali e anagrafiche. L’app mobile non legge da un replica, e non scrive in un sistema parallelo che dovrà essere riconciliato. Per renderlo possibile servono due componenti, entrambi compatibili con il principio della fonte unica.
Cache locale per la coda offline
Sul dispositivo dell’agente c’è una cache locale: è una conseguenza fisica della disconnessione, non un secondo repository. Quando l’agente lavora senza copertura, la cache memorizza temporaneamente le operazioni (ordini, incassi, consegne) e le accoda. Alla prima riconnessione la coda viene smaltita e i dati confluiscono in B1. Una cache di questo tipo è caratteristica di qualsiasi applicazione offline-first: senza, semplicemente, non si lavora in zone con copertura scarsa.
API gateway di MTF.Sales.Suite + Service Layer di SAP B1
Sul server del cliente è installato l’API gateway di MTF.Sales.Suite: un componente proprietario MTF che espone API REST verso l’app mobile e dialoga con il Service Layer di SAP Business One — l’API REST/OData esposta da B1 a partire dalla versione 10.0. Il gateway si occupa di tre cose: autenticazione e autorizzazione utenti, traduzione dei flussi mobile in transazioni B1, applicazione di business logic specifica della suite (calcolo provvigioni, gestione listini speciali, regole di scontistica plurivocale). Quello che il gateway non fa è duplicare i dati: ogni scrittura finisce in SAP B1, ogni lettura passa da B1. Quando l’agente conferma un ordine cliente, è SAP Business One a eseguire le proprie regole (controllo fido, blocco anagrafica cliente, riservazione lotti) e a restituire l’esito.
Il pattern funziona allo stesso modo su SAP B1 con Microsoft SQL Server e su SAP B1 con SAP HANA. Il passaggio da SQL a HANA non richiede di rifare l’integrazione mobile.
Dal punto di vista del flusso fiscale, una soluzione che segue questo principio si appoggia al flusso fattura elettronica di SAP Business One — i documenti generati confluiscono nel modulo FE già configurato sul gestionale. Stesso discorso per UDF, UDT, UDO: i campi e le tabelle user-defined configurati dall’azienda nel proprio B1 sono visibili e scrivibili dall’app senza moduli intermedi e senza mappature replica-side.
Architettura “shadow database”: una seconda fonte di verità
L’altra grande famiglia di add-on è quella che mantiene un database completo che replica l’intera base dati B1, con sincronizzazione periodica (notturna o oraria). L’app mobile lavora contro il replica, non contro B1. La sincronizzazione avviene a batch, in entrambe le direzioni: dati B1 → replica per la lettura, replica → B1 per le scritture.
Le conseguenze sono nette:
- Disallineamento temporale: l’agente vede dati vecchi di N ore. Listini di ieri, scadenzario non aggiornato, credito residuo cliente già consumato e non ancora replicato.
- Componente in più da governare: il replica DB e i job di sync vanno installati, monitorati, aggiornati a ogni minor SAP B1, e diventano superficie di failure aggiuntiva.
- Mappature parallele: ogni UDF/UDT del B1 originale va mappato esplicitamente nel replica. Quando aggiungi un campo personalizzato, non basta crearlo in B1 — va anche replicato.
- Conflitti di scrittura: se un’altra applicazione modifica un dato in B1 mentre il replica è offline, il prossimo sync potrebbe sovrascriverlo o richiedere risoluzione manuale.
Architetture shadow database hanno casi d’uso legittimi (volumi enormi che il Service Layer non regge in tempo reale, requisiti di analytics che non si vogliono caricare sul DB transazionale, integrazioni storiche pre-Service Layer). Ma il prezzo strutturale è lo stesso: la fonte di verità non è più solo SAP B1. Ogni claim di tipo “integrazione perfetta” da parte di un vendor andrebbe sempre verificato chiedendo dove vengono scritti i dati e con che frequenza.
Tabella comparativa
| Dimensione | Single source of truth (es. MTF) | Shadow database |
|---|---|---|
| Fonte di verità per ordini, listini, scadenzari | Solo SAP B1 | B1 + replica completo |
| Allineamento dati visti dall’agente | Near real-time online, in coda offline | Vecchi di ore (batch) o minuti (incrementale) |
| Fattura elettronica / SDI | Si appoggia al flusso FE di SAP B1 | Dipende dall’integrazione del vendor |
| UDF, UDT e UDO esistenti | Visibili senza mappature parallele | Vanno mappati nel replica |
| Componenti server da governare | Gateway API + Service Layer | Replica DB + job di sync + spesso gateway |
| Tempi tipici di go-live | ~4 settimane per setup standard | Variabile, spesso più lungo per il sync iniziale |
| Passaggio SQL Server → SAP HANA | Non richiede rilavoro mobile | Replica e sync da rivalidare |
Onestà sul perimetro: dove guardare anche altrove
Per evitare conversazioni a vuoto, vale la pena essere espliciti sui due assi che davvero discriminano la scelta tra MTF.Sales.Suite e un add-on globale.
Asse 1 — Il processo è davvero van sales / prevendita / fattorinaggio? MTF.Sales.Suite è progettata per il caso “agente in mobilità con merce a bordo (o ordine in carico) + listini multi-cliente + scadenzario aperto + stampa documenti sul mezzo”. È fortemente flessibile sul modello dati (UDF, UDT, regole custom) e sui processi adiacenti — la suite si adatta a varianti settoriali importanti. Se però il tuo scenario di vendita è categorialmente diverso — vendita di machinery industriale dove l’offerta è un configuratore tecnico CAD-driven, vendita consulenziale dove il deliverable è un sopralluogo + offerta tecnica firmata da un ingegnere applicativo, vendita B2C retail dove il punto vendita è fisso — allora il caso d’uso non è van sales e nessuna suite di mobile sales (la nostra né le concorrenti) è la categoria giusta.
Asse 2 — Investimento pregresso significativo su un add-on globale Se sei già cliente di un grande add-on internazionale da molti anni, con integrazioni custom verso BI, e-commerce, marketplace e sistemi di gruppo, e una popolazione di utenti già formata, il costo di switch (re-training agenti + re-integrazione + parallel running esteso) può superare il beneficio architetturale di una migrazione, anche quando la nuova soluzione è tecnicamente migliore. In questi scenari il confronto va fatto con onestà sui costi totali, non solo sull’architettura. Spesso la risposta giusta è “valutiamo tra 12-18 mesi, quando l’investimento attuale sarà ammortizzato”.
Cosa NON è un fattore discriminante: la dimensione dell’azienda né la sua estensione internazionale. MTF.Sales.Suite serve oggi sia PMI italiane sia filiali italiane di gruppi multinazionali; e poiché il principio architetturale è “una installazione dedicata per ciascuna entità con SAP B1 sotto”, la stessa suite si replica con la stessa logica su nuove installazioni B1 in altri paesi — Spagna, Francia, Germania — con la sola adozione delle specifiche fiscali locali. Una soluzione che oggi gestisce 30 agenti italiani può gestire domani 300 agenti distribuiti su più paesi, finché c’è un’installazione SAP B1 sotto ciascuna geografia.
Domande frequenti
Posso usare un add-on di terze parti senza il Service Layer?
Sì, esistono integrazioni storiche basate su DI API o B1IF. Sono più rigide del Service Layer, scalano meno bene e impongono requisiti di rete e infrastruttura più stringenti. Per progetti nuovi nel 2026 il Service Layer è la scelta naturale.
Quanto è critica davvero la modalità offline?
Nei settori food, beverage e materiale elettrico, dove gli agenti lavorano fuori da città medio-piccole, l’offline non è un nice-to-have: è la differenza tra “ho lavorato la mattina” e “ho perso 4 ore in attesa di campo”. MTF.Sales.Suite offre tentata vendita con modalità offline e sincronizzazione automatica al rientro o quando torna la rete.
Cosa cambia se passo da SQL Server a SAP HANA?
Per una soluzione single source of truth con gateway che parla al Service Layer, niente sul lato mobile: l’API è la stessa. Cambiano i tempi di alcune query lato server e l’infrastruttura sottostante, ma non l’integrazione. Per un add-on con shadow database, il replica e gli script di sync vanno rivalidati.
Posso conservare i miei UDF e UDT esistenti?
Sì. La forza di una soluzione single source of truth è esattamente questa: i campi user-defined e le tabelle user-defined già configurate nel tuo SAP B1 restano la fonte di verità e l’app mobile li usa attraverso il gateway proprietario, senza duplicarli su un database secondario.
Quali sono i tempi tipici di go-live per la tentata vendita su SAP B1?
Per un setup standard MTF prevede 4 settimane dal kick-off al go-live, includendo configurazione, formazione agenti, parallel running e tuning. Tempi maggiori sono possibili se ci sono integrazioni con sistemi esterni (e-commerce, BI, marketplace) o se la qualità dei dati anagrafici richiede una bonifica preliminare.
Cosa fa MTF qui
MTF è Silver Partner SAP e implementa SAP Business One per le PMI italiane da oltre dieci anni. Quando il processo della tentata vendita esce dal perimetro standard di B1 — agente in mobilità, listini complessi, modalità offline obbligatoria, fattorinaggio con proof of delivery — usiamo MTF.Sales.Suite, la nostra suite mobile costruita sul principio single source of truth: cache locale per la coda offline, API gateway proprietario sul server cliente, Service Layer di SAP Business One come unica fonte di verità. Compatibile con SAP B1 10.0+ sia su SQL Server sia su HANA.