The problem this solves
Somebody on your team exports a CSV from SAP Business One every Monday morning. They paste it into a spreadsheet, fix the date column, re-run a lookup against a second export, and refresh a dashboard that the leadership team looks at once. By Wednesday the numbers are stale. By the following Monday the person who built the spreadsheet is on leave and nobody else knows which query produced column K.
The deeper problem is that every consumer builds their own version of the truth. Sales pulls revenue one way, finance pulls it another, and the two never reconcile because one included credit notes and the other did not. The dashboard is only as trustworthy as an undocumented export chain, and the ERP has no record that any of it happened.
What ECOSIRE builds
We build a connector that publishes defined SAP Business One datasets into Looker Studio and Sheets as live, refreshable data sources. Your reporting layer stops being a pile of exports and becomes a governed set of datasets that everyone reads from.
Governed datasets, not a raw table dump
This is the important distinction. We do not expose your schema and leave analysts to guess join conditions. During scoping we agree the datasets you actually report on and build each one as a defined, documented model with named fields, correct grain and explicit business rules. Typical datasets:
- Sales — Sales Orders (ORDR/RDR1) and A/R Invoices (OINV/INV1) at line grain, with Business Partner, sales employee, item, item group, warehouse, document currency and local currency, credit notes netted, and open versus invoiced clearly separated.
- Inventory — on-hand by item and warehouse (OITW), in-stock versus committed versus ordered, valuation, batch and serial detail where you use it, and slow-mover ageing.
- Purchasing — Purchase Orders and A/P Invoices at line grain with supplier, expected date and receipt status.
- Receivables and payables — open items with ageing buckets calculated to your own definition, not a generic 30/60/90 if that is not how you work.
- Financials — Journal Entries (OJDT/JDT1) rolled to your chart of accounts, with cost centre and distribution rule dimensions where you use them.
Each dataset gets a data dictionary: field name, source table and column, calculation where it is derived, and grain. When two people disagree about a number, the dictionary settles it.
Two delivery surfaces
Looker Studio. We build a community connector so your datasets appear as native data sources: pick the dataset, pick fields, apply date ranges and filters, and build charts. Date parameters push down to the query rather than pulling everything and filtering in the browser, so a two-year dashboard does not drag your database. Aggregations and calculated fields defined in the dataset behave consistently across every report anyone builds.
Sheets. A bound add-on writes a dataset into a sheet range on demand or on a schedule, with parameters (date range, warehouse, Business Partner group) taken from named cells. Refresh replaces the range in place, so formulas, pivot tables and charts built on top of it survive. This is the honest answer for the finance analyst who genuinely needs a spreadsheet — it gives them one, fed from a governed dataset instead of a manual export.
How it is built technically
The connector reads SAP Business One through the Service Layer (REST/OData), using the DI API where a specific object requires it. Where a dataset needs a shape the Service Layer does not express efficiently, we define it as a query or view inside your company database and expose it through the connector — read-only, parameterised, never string-concatenated from user input.
Dataset definitions, field mappings and refresh schedules live in UDTs, and a dataset registry is exposed as a UDO so adding a field or a new dataset is a configuration change your team can make and audit inside SAP Business One rather than a code deployment. UDFs you have already added to Business Partners, items or documents can be included in any dataset — a common request, since your custom fields are usually the ones the business actually reports on.
Access is scoped. A service account authenticates to SAP Business One, and the connector applies its own dataset-level and row-level rules on top: a regional manager's Looker Studio credentials can be restricted to their warehouses or their sales employee codes. Every request is logged with the requesting identity, dataset, parameters and row count, so you can see who pulled what.
The connector is read-only by design. It never writes to your company database. Where you also need a printed or e-mailed document, Crystal Reports remains the right tool and we will say so rather than pushing everything into a dashboard.
Who this is for
SAP Business One companies standardised on Google Workspace whose reporting currently runs on manual exports. It fits management teams who want a small number of dashboards they trust, finance analysts who need live spreadsheet data, and operations managers who want a warehouse or item view refreshed daily without asking IT.
It is not a replacement for a data warehouse if you need to blend SAP Business One with several other large source systems and keep years of history — we will tell you that during scoping rather than selling you a connector that will be outgrown. It is also not the answer if your reporting need is really a formatted, statutory document.
How delivery works
1. Scoping call. We work from the reports you actually use. Which questions get asked every week, which fields matter, which of your UDFs must appear, how you define a fiscal period and an ageing bucket, what your currency setup is, and whether you are on SQL Server or SAP HANA. We agree the dataset list and the grain of each.
2. Fixed quote. A written scope naming every dataset, its fields, its grain, the refresh model, the access rules, the timeline and a fixed price.
3. Build. Typical lead time is one working week depending on how many datasets you take and how much derived logic they carry.
4. Install into your test company. Connector installed against a copy of your production company database. You connect from your own Looker Studio and Sheets accounts and reconcile each dataset against a report you already trust. That reconciliation is the acceptance test — a dataset is not done until its totals match a number you already believe.
5. Production install. Scheduled cutover with the service account, access scoping and refresh schedules configured. We repoint your verified dashboards at production.
6. Support window. A defect-fix window after go-live, with the length stated in your quote. Adding a field to an existing dataset afterwards is a UDT change your team can make; a genuinely new dataset is quoted as a small change.
Everything is delivered per tenant, for your company database, with source code, dataset definitions and the data dictionary handed over.