Faster Tally Reporting. No Complex Keys Required!
We extract on-premises Microsoft Dynamics NAV data over direct SQL into a Power BI star schema - conformed dimensions, multi-company consolidation, nightly refresh.
Dynamics NAV stores its data in SQL Server, but not in a shape anyone can report on directly. Every table is prefixed per company, so a ten-company group carries ten separate copies of Customer, Item and Item Ledger Entry. Field names are mangled by the SQL writer. Global dimensions sit behind a set-ID indirection that almost nobody joins correctly on the first attempt. Core tables like Item Ledger Entry and Value Entry carry ninety-odd columns, of which about a dozen matter for analytics.
Power BI reports built straight on top of that work - until someone renames a dimension, adds a company, or upgrades the database. Then they don't.
Step 1 - NAV database
Read-only access to your on-premises SQL Server. Nothing is installed inside NAV and no NAV objects are modified.
Step 2 - Staging layer
Parameterised stored procedures resolve the per-company table names and land clean, typed columns.
Step 3 - Star schema
Conformed dimensions, fact tables, surrogate keys and load timestamps - a model a report builder can read without knowing NAV.
Step 4 - Power BI
Import-mode datasets your team can extend, share and certify.
Everything is plain SQL Server objects - stored procedures and views your own DBA can open, read and maintain. No black box, no runtime agent, no licence server.
Item Ledger Entry
Value Entry
Sales Invoice Line
Purchase documents
Customer, Item, Vendor
Location, Item Category
Product Group, Manufacturer
Tax Group, Item Discount
Global Dimension 1 and 2
Multi-company parameterisation
Load timestamps on every row
Pre-joined staging views
Inventory movement, valuation, and sales margin by item, location, customer and dimension - the questions NAV cannot answer on its own.
Most NAV reporting stops at one company. Consolidation gets done by hand in Excel, group totals arrive days after month-end, and every new entity means another build.
Because company and database are passed as parameters, all entities land in one conformed model. Leadership gets the group view and the per-entity view from a single dataset, and adding a company is a configuration change rather than a project.
Best fit: a group of two to ten companies inside one NAV database.
A good fit
On-premises NAV 2009 R2 to NAV 2018, with direct SQL Server access
SMB manufacturer, distributor or trading business, 25-250 staff
Classic Company$Table naming (pre-BC14)
Two to ten companies in one database
Nightly refresh is sufficient
Business Central migration deferred two years or more
Not a fit
Business Central cloud, or migrating within twelve months
BC14+ on-premises with GUID-suffixed table names
Hosted NAV with no direct SQL access
Near-real-time or intra-day refresh requirements
Heavy customisation of core table structures
Data volumes where a full nightly reload is impractical
If you fall on the right-hand side, tell us - the extraction approach is different for Business Central, and we would rather say so up front than sell you the wrong thing.
We work through Dynamics VARs as well as directly. Three ways partners use this:
As a bridge. A client staying on NAV another two to three years gets real BI now, without pre-spending the migration budget.
As migration insurance. The dimensional model is built on NAV. When Business Central lands, only the extraction layer is replaced - the reports survive.
As a billable add-on. You own the client relationship, the deployment and the reports. We supply and maintain the extraction layer.
Referral, resale and white-label arrangements are all open.
Tell us your NAV version, how many companies sit in the database, and what reporting question keeps coming back unanswered. We will tell you honestly whether this fits.