In short
When an Italian SME decides to digitise van sales on top of SAP Business One, two architectural families compete: one in which SAP B1 remains the only source of truth (the choice MTF.Sales.Suite makes, combining a local cache for offline operation with a proprietary API gateway on the customer’s server), and one in which a complete second database mirrors B1 and becomes the system of record for the mobile app. The difference is not cosmetic. It changes the freshness of the data the agent sees, the way Italian e-invoicing flows out, recurring licensing cost and time to go-live. This article explains both architectures honestly and gives you the right questions to ask a vendor before signing.
What van sales on SAP B1 really means
Van sales is the practice of selling directly from the truck: the agent reaches the customer, proposes, sells, delivers, invoices and collects in one visit. It coexists with two close cousins: pre-sales (mobile order capture without immediate delivery) and delivery with proof of delivery (handing over goods that were ordered earlier, with signed confirmation).
Three things make van sales much more demanding than a typical mobile CRM:
- Agents often work in areas with poor cellular coverage, so offline mode has to be real, not a degraded fallback.
- Multi-customer price lists, multi-tier discounting and live receivables visibility: agents need accurate data the moment they need it, otherwise they promise something wrong.
- The Italian fiscal layer — delivery notes (DDT), accompanying invoices, e-invoicing through the SDI hub, FEFO lot tracking for food and pharma — does not tolerate architectural improvisation.
The real axis: where the source of truth lives
The distinction that matters is not “direct Service Layer vs middleware” — any serious enterprise application has some kind of server-side component for authentication, business logic and rate-limiting. The real distinction is different:
Where do orders, master data, price lists and aging reports live? In one place (the SAP Business One database) or duplicated in a second database that runs its own life?
That is the question to put to a vendor. Answering it honestly reveals two very different architectural families, each with concrete consequences.
Single source of truth: SAP B1 stays the only system of record
In clean architectures (the family MTF.Sales.Suite belongs to) the SAP Business One database stays the only source of truth for transactional and master data. The mobile app does not read from a replica, and does not write to a parallel system that then has to be reconciled. Two components make this possible, both compatible with the single-source principle.
Local cache for the offline queue
On the agent’s device there is a local cache: it is a physical consequence of disconnection, not a second repository. When the agent works without coverage, the cache temporarily stores operations (orders, payments, deliveries) and queues them. As soon as connectivity is back, the queue drains and the data flows into B1. A cache like this is a feature of any offline-first application: without it, you simply cannot work in low-coverage areas.
MTF.Sales.Suite API gateway + Service Layer of SAP B1
On the customer’s server the MTF.Sales.Suite API gateway is installed: a proprietary MTF component that exposes REST APIs to the mobile app and talks to the Service Layer of SAP Business One — the REST/OData API exposed by B1 from version 10.0 onwards. The gateway handles three things: user authentication and authorisation, translation of mobile flows into B1 transactions, and suite-specific business logic (commission calculation, special price lists, multi-tier discounting rules). What the gateway does not do is duplicate data: every write ends up in SAP B1, every read passes through B1. When the agent confirms a sales order, it is SAP Business One that enforces its own rules (credit limit, customer block, lot reservation) and returns the outcome.
The same pattern works on SAP B1 with Microsoft SQL Server and on SAP B1 with SAP HANA. Migrating the database from SQL to HANA does not require redoing the mobile integration.
On the fiscal side, a solution that follows this principle leans on SAP Business One’s e-invoicing flow: the documents created by the field user feed straight into the e-invoicing module already configured on the ERP. Same story for UDF, UDT and UDO: the user-defined fields and tables already configured in the company’s own B1 are visible and writable from the app, with no intermediate mapping module and no replica-side mappings.
Shadow database: a second source of truth
The other large family of add-ons is the one that keeps a complete database mirroring the entire SAP B1 dataset, with periodic synchronisation (nightly or hourly). The mobile app works against the replica, not against B1. Synchronisation happens in batch, in both directions: B1 → replica for reads, replica → B1 for writes.
The consequences are clear:
- Time-shifted data: agents see information that is hours old. Yesterday’s price list, an aging report out of sync with reality, a customer credit limit already consumed and not yet replicated.
- Extra component to operate: the replica DB and the sync jobs must be installed, monitored and upgraded with every SAP B1 minor release, and they become an additional failure surface.
- Parallel mappings: every UDF/UDT in the original B1 has to be explicitly mapped into the replica. When you add a custom field, creating it in B1 is not enough — it has to be replicated too.
- Write conflicts: if another application changes data in B1 while the replica is offline, the next sync may overwrite it or require manual resolution.
Shadow database architectures have legitimate use cases (huge volumes the Service Layer cannot serve in real time, analytics requirements that should not load the transactional DB, legacy integrations from the pre-Service-Layer era). But the structural price is always the same: SAP B1 is no longer the only source of truth. Any “perfect integration” claim from a vendor deserves to be verified by asking where the data is written and how often.
Side-by-side comparison
| Dimension | Single source of truth (e.g. MTF) | Shadow database |
|---|---|---|
| Source of truth for orders, price lists, aging | SAP B1 only | B1 + complete replica |
| Freshness of data the agent sees | Near real-time online, queued offline | Hours old (batch) or minutes (incremental) |
| E-invoicing / SDI | Leans on the SAP B1 flow | Depends on the vendor’s integration |
| Existing UDF, UDT and UDO | Visible without parallel mappings | Have to be mapped into the replica |
| Server components to operate | API gateway + Service Layer | Replica DB + sync jobs + often a gateway |
| Typical go-live | ~4 weeks for a standard setup | Variable, often longer for the initial sync |
| SQL Server → SAP HANA migration | No mobile rework needed | Replica and sync must be re-validated |
Honest scope: when to look also elsewhere
To avoid sterile conversations, it is worth being explicit about the two axes that really discriminate between MTF.Sales.Suite and a global add-on.
Axis 1 — Is the process really van sales / pre-sales / delivery? MTF.Sales.Suite is built for the case “mobile agent with goods on the truck (or order in hand) + multi-customer price lists + open receivables ledger + document printing on the move”. It is highly flexible on the data model (UDF, UDT, custom rules) and on adjacent processes — the suite adapts to significant sector-specific variants. But if your selling scenario is categorically different — industrial machinery sales where the offer is a CAD-driven technical configurator, consultative selling where the deliverable is a site visit + technical proposal signed by an application engineer, or B2C retail with a fixed point of sale — then the use case is not van sales, and no mobile-sales suite (ours or competitors’) is the right category.
Axis 2 — Significant prior investment in a global add-on If you have been a customer of a large international add-on for years, with custom integrations into BI, e-commerce, marketplaces and group-wide systems, plus a population of trained users, the switching cost (re-training agents + re-integration + extended parallel running) can outweigh the architectural benefit of a migration, even when the new solution is technically better. In these scenarios the comparison has to be fair on total cost, not just architecture. The right answer is often “let’s reassess in 12-18 months, when the current investment is amortised”.
What is NOT a discriminator: the size of the company, nor its international footprint. MTF.Sales.Suite serves both Italian SMEs and Italian subsidiaries of multinational groups; and because the architectural principle is “one dedicated installation per entity that runs SAP B1 underneath”, the same suite can be replicated on new B1 installations in other countries — Spain, France, Germany — with only the local fiscal specifics to adopt. A solution that today serves 30 Italian agents can serve 300 agents distributed across multiple countries tomorrow, as long as there is a SAP B1 installation under each geography.
FAQ
Can I use a third-party add-on without the Service Layer?
Yes — older integrations rely on DI API or B1IF. They are more rigid than the Service Layer, scale less well and impose stricter network and infrastructure requirements. For new projects in 2026 the Service Layer is the natural choice.
How critical is offline mode, really?
In food, beverage and electrical wholesale, where agents drive far outside major towns, offline is not a nice-to-have: it is the difference between “I worked all morning” and “I lost four hours waiting for signal.” MTF.Sales.Suite ships van sales with offline mode and automatic synchronisation on reconnect.
What changes if I move from SQL Server to SAP HANA?
For a single source of truth solution with a gateway that talks to the Service Layer, nothing on the mobile side: the API is the same. Some server-side query timings change, and the underlying infrastructure changes, but the integration does not. For a shadow-database add-on, the replica and the sync scripts must be re-validated.
Can I keep my existing UDF and UDT?
Yes. That is exactly the strength of a single source of truth solution: the user-defined fields and tables already configured in your SAP B1 stay the source of truth, and the mobile app uses them through the proprietary gateway, with no need to duplicate them in a secondary store.
What is a typical go-live timeframe for van sales on SAP B1?
For a standard setup MTF plans for 4 weeks from kick-off to go-live, including configuration, agent training, parallel running and tuning. Longer timelines are realistic when there are integrations with external systems (e-commerce, BI, marketplaces) or when master data quality requires preliminary cleanup.
Where MTF fits
MTF is a Silver Partner SAP and has been implementing SAP Business One for Italian SMEs since 2017. When van sales steps outside the standard SAP B1 perimeter — mobile agents, complex price lists, mandatory offline mode, delivery with proof of delivery — we use MTF.Sales.Suite, our mobile suite built on a single source of truth principle: a local cache for the offline queue, a proprietary API gateway on the customer’s server, and the SAP Business One Service Layer as the only system of record. Compatible with SAP B1 10.0+ on both SQL Server and HANA.