SAP Business One stays where it is.
What changes is who can talk to it.
We connect to SAP from the outside. Nothing changes inside it.
SAP Business One already holds the customer records, the price lists, the stock and the orders. The problem is never SAP: it is that the e-commerce, the marketplace, the warehouse and the customers can't reach it - so someone re-types what the ERP already knows, and two systems quoting different numbers become a monthly argument. We put one point in the middle that talks to SAP and to everything else.
What comes in, what goes out.
The technical question isn't which protocol. It is who owns the truth: for every piece of data you decide once, and you write it down in the mapping before writing any code. With SAP Business One the answer is almost always SAP - it is the system that invoices, so it is the system that is right.
- Customer recordsfrom SAP
- Code, payment terms, assigned price list, holds. Outside SAP you don't create a customer: you read one.
- Price lists and discountsfrom SAP
- Per-customer prices, tiers, currencies. The rules stay where they are already configured; whatever sits outside applies them rather than reinventing them.
- Stockfrom SAP
- Available per warehouse, committed, on order. With a cache in between, because a storefront can't query the ERP on every click.
- OrdersSAP imports them
- The order is born outside - portal, e-commerce, the sales rep's web app - and stays exposed on our API. A job inside SAP comes and takes it: no code of ours writes into the ERP, and the order enters through SAP's own rules.
- Documentsfrom SAP
- Delivery notes, invoices, order confirmations. The customer downloads them instead of asking your back office.
- Order and shipping statusfrom SAP
- From the status in SAP to the notification the customer gets, with nobody writing it by hand.
These are the flows we have already put into production: examples, not a catalogue. In principle anything held in SAP can be read; whatever has to get into SAP is decided case by case, and that is one of the things the mapping puts in writing before anyone starts.
The API SAP queries is idempotent: if the job retries - the network drops, the machine restarts - it gets the same order back and not a duplicate. It is the boring part of the work, and the only part that matters on the day it happens.
The system that invoices is the system that is right. Everything else adapts to it.
One point in the middle, not two systems wired by hand.
The fast way is to wire SAP straight into the e-commerce. It works, until the marketplace arrives, then the courier, then the warehouse system: at that point every pair is a piece of software to maintain, and each one breaks when either end changes. The middleware is the single point in the middle - the systems talk to it, not to each other.
- // permissions
Per-role permissions
Who reads what is decided outside SAP. The e-commerce sees price lists and stock, not costs; an AI agent sees what it was granted and nothing else.
- // log
A log of every call
Every request and every response stays written down. When someone asks why that order came through the way it did, the answer is a record - not a reconstruction from memory.
- // queue
Queue and retries
If SAP doesn't answer - maintenance, a backup, a restart - the flow isn't lost: it queues and resumes. Nobody outside notices.
- // no-copies
No second copy of the data
The middleware never becomes a second ERP: it holds cache and state, not the truth. The truth stays in SAP, where it already is.
We are not SAP resellers and we take no commission on licences: we connect to SAP the way we'd connect to any other system, including an ERP written to measure twenty years ago. When we say something isn't worth doing in SAP, we aren't defending a margin.
A real project, not a diagram.
A pharmaceutical company with a network of business customers: orders, documents and forecasts all went through email, phone calls and spreadsheets. The portal we built is integrated with SAP Business One in real time - and a confirmed forecast becomes a proposed order with nobody re-typing it.
The questions we always get.
Are you an SAP partner or reseller?
No, and we take no commission on licences. We connect to SAP Business One the way we'd connect to any other system. That is the whole advantage for you: when we say something isn't worth doing, we aren't defending a margin.
Will it work with our installation?
That is the first question we answer, and you answer it by looking. The mapping is the first step of every project: it says what is reachable, how, and what it costs to connect. What comes out is a readable document - and from there you can also decide to stop.
How long does it take?
It depends how many flows you actually need, and it is almost always fewer than it looks at the start. You begin with one - usually stock or orders - put it in production, and add the rest once the first one holds. We don't ship six integrations together on go-live day.
What if we change ERP later?
The connector to SAP changes, not everything else: that is exactly why the point in the middle exists. The e-commerce, the marketplace and the warehouse talk to the middleware, not to SAP, so they don't even notice the ERP changed. And the code is yours either way.