Power BI Data Connector

SAP Business One holds the numbers the business actually runs on, and it ships perfectly good ways to print them - Crystal Reports layouts, the Excel report designer, interactive analysis. What it does not ship is a maintained Power BI semantic model. So the same pattern repeats in almost every installation: an analyst is given read access to the company database, writes a query, pastes it into Power BI Desktop as a native SQL statement, and publishes a report. Six months later there are eleven reports, four different definitions of gross margin, at least one of them wrong, nobody can say which query survived the last upgrade, and a scheduled refresh takes forty minutes because every model rescans the entire history of INV1.

The problem is not Power BI and it is not SAP. It is that nobody built a governed layer between them.

What ECOSIRE builds

ECOSIRE builds that layer for your tenant: a read-only data access layer over your company database, a Power BI semantic model in star schema with a documented DAX measure library, and a starter report pack that your team owns and extends. It is scoped to the modules you actually report on, and every measure definition is agreed with your finance lead before it is written, so the model becomes the single definition rather than the twelfth one.

The data access layer

Where direct database access is permitted, we build a set of read-only views - SQL Server views on a SQL Server installation, calculation views or SQL views on SAP HANA - over the standard tables: A/R Invoices (OINV/INV1), Sales Orders (ORDR/RDR1), Deliveries (ODLN), A/P Invoices (OPCH/PCH1), Journal Entries (OJDT/JDT1), the chart of accounts (OACT), items (OITM), item-warehouse stock (OITW), inventory transactions (OINM), Business Partners (OCRD), BP groups (OCRG), sales employees (OSLP), warehouses (OWHS), posting periods (OFPR) and exchange rates (ORTT). The views are the contract. Column names are business names, joins are made once and made correctly, and no report author ever needs to know which of two date columns is the posting date.

Where the system is cloud-hosted and direct SQL is not available, the same shape is served over the Service Layer as OData v4 feeds, consumed by a Power Query M custom connector packaged as a .mez file with named credentials, so analysts connect by picking your connector rather than pasting a URL and a password.

The semantic model

On top of that sits a proper star schema: fact tables for sales, purchasing, inventory movement and the general ledger, with conformed dimensions for item, Business Partner, warehouse, sales employee, posting period and a generated date table. Measures are written in DAX and documented: revenue, cost, gross margin and margin percentage, A/R and A/P ageing buckets, days sales outstanding, open order backlog, inventory value and turns, and period-over-period comparisons that behave correctly across your fiscal calendar rather than the Gregorian one. Multi-currency is handled explicitly using exchange rates from ORTT, so document, local and system currency measures exist side by side instead of being silently mixed.

Performance and refresh

Incremental refresh is configured on the fact tables using RangeStart and RangeEnd parameters against posting date, with change detection on the update timestamp so a nightly refresh loads a moving window rather than rescanning years of history. Where you run an on-premise or privately hosted database, the on-premises data gateway is installed and the refresh schedule configured with you. Where reporting load on the production database is a concern, the views can be pointed at a read replica or a nightly restored copy, and we will say during scoping which of those your volume justifies.

Governance

Row-level security maps Power BI identities to SAP concepts you already maintain: sales employee (OSLP), branch, warehouse, or BP group. A regional sales manager opens the same report as the finance director and sees a different slice of it, without a second copy of the report existing. Drill-through takes a user from a chart down to the underlying document rows and shows the SAP document number, so a query about a number ends in the document rather than in an argument.

Who this is for

SAP Business One customers whose reporting has outgrown Crystal Reports and exported spreadsheets; finance teams that need one agreed definition of margin and ageing; and multi-entity groups consolidating several company databases into one model. It also suits companies that already have Power BI licences and internal analysts, but no trustworthy data layer for them to build on.

How delivery works

1. Scoping call. We agree which modules are in scope, which measures matter, how your fiscal calendar and currencies work, who is allowed to see what, and whether reporting runs against production, a replica or a copy. 2. Fixed quote. A written scope and a fixed price, issued before any build work starts. 3. Build. Typically two to four weeks depending on scope, developed against a copy of your company database. 4. Install in test. Views and the model are deployed against your test company first, and the numbers are reconciled line by line against SAP standard reports for a period you choose. Nothing is signed off until the model and SAP agree. 5. Install in production. Deployment against production or the nominated replica, gateway configuration, refresh scheduling, workspace and row-level security setup, and publication of the starter reports. 6. Support. A defect warranty window plus an optional support plan for schema changes and new measures.

What this is not

This is build-to-order. There is nothing pre-built to download, no free trial, and no template that magically knows your chart of accounts. Power BI licences, workspace capacity and gateway hosting are yours and are not included in the price. We make no certification or partnership claim with SAP or with Microsoft. What you get is a model your own analysts can read, extend and maintain after we leave - including the view definitions, the M code and the DAX.