In Visual Studio there is a wizard to migrate an Excel Power Pivot model to a SSAS model. But this will not bring over the M-queries unfortunately. But there is a workaround to achieve this. It requires SQL Server 2017 or higher:
Import the Excel file in Power BI Desktop, save and close the pbix-file
Open Azure Analysis service, open the Web Designer and create a new model where you import the pbix
Open that model with Visual Studio (this will actually create a download that holds the VS-file)
Open that file in Visual Studio, load the data, build and change the deployment target from Azure to you local SSAS-database before deploying.
See how it goes:
Warning: There are some limitations for the M-functionalities in SSAS (see here for example:General Overview by Microsoft or Use your own SQL… by Chris Webb), so you might want to give it a thorough test before rolling out. There are missing a lot of data sources currently, like web-queries for example who will hopefully soon be added as well.
In finance & accounting, you very rarely report the figures with the signs of their source systems, but switch (certain) signs according to different needs. Instead of using unary operators for it, I’ll present an easy and dynamic way for it in Power BI and Power Pivot using DAX. It will cover the following 3 main scenarios:
1_SwitchAll: All signs are switched (red)
2_SwitchExpLiab: Expenses and liabilities are switched back to their original values (green)
3_BWT_Indiv: Only the main figure for expenses (or liabilities) carries a minus, all following positions specifying the expenses are (principally) reported as positives (blue)
Switching signs in Power BI and Power Pivot without unary operators
I’m using the sample data from this article but changed the source-data to a double-bookkeeping structure. There signs are used and the transaction entries in your ledger table always add up to zero. This is a method that prevents errors when posting and can also be used to prevent errors in reporting. If you keep the signs in your reporting system, all you have to do is add up the relevant figures and the returned (absolute) figures will always be correct. If you have read my previous articles on Easy P&L, you have seen this method in action: No minus-operation there, just a simple stupid adding of all accounts who fall into several (sub-) total categories via the bridge-table.
The Account-table also contains of (sub-) totals and the column “AccountType” shows if the positions are regarded as Turnover (Revenue) or Expenses:
My values on “1_SwitchAll” corresponds to “FinalValue” in the article above. The revenues come from consultancy and coursed provided. But the revenue for courses don’t just consist of attendee rates, but the costs for catering and paid instructors shall be deducted (highlighted in yellow). So the “good” numbers that contribute to cash in your pocket shall be reported without a sign and the “bad” numbers that result in an outflow of cash shall be reported with a minus. Within the expenses category, the costs carry a minus and the travel refunds (highlighted in orange), which are cash positive, are reported as positives.
Another requirement that is often used for balance-sheet-reporting or reports that only report on cost-situations, require that the costs or liabilities are reported without signs. … Principally, because the reimbursements/cost deductions shall be reported with an opposite sign (to show the adverse effect to the cashflow). This is what “2_SwitchExpLiab” shows (not covered in the article).
Last but not least comes a typical “BossWantsThat”-requirement: Basically some strange stuff that you just have to deliver. Here the main categories “Revenues” and “Expenses” shall be shown with the signs that reflect the cash-direction, but all specifications that follow below shall be reported without signs (again: Principally, because positions with opposite cash-effects than the main category shall carry inverted signs).
This DAX-VizArt-Wizard vizualizes dependencies between your DAX measures, shows the definition of all related measures and shows differences between the measures of 2 models/versions. This works for Power Pivot, Power BI and for Analysis Services Tabular (SSAS).
In the Power BI-Version you’ll see them in the Sankey-chart like this:
If select measures/nodes, all direct connections will be highlighted:
In the second version, all indirect connections will be highlighted as well & the selected measure definitions will be shown.
Excel-reports on SSAS cubes (multidimensional and tabular) can have someflaws that now can be overcome by using Power Query for sourcing your cubedata:
filter your cube by complete Excel-tables without loading them to the model/cube
Apply nice number and date formats to non-measure number and date fields in your row- or column section
create fast detailed reports (multiple attributes in your row sections, overcome the slow MDX that the pivots on cubes produce)
As with the recent Power Query update (26) you can now create your own MDXand DAX-statements for retrieving data from a cube, it is also possible to pass individual parameters from your Excel-sheet to the queries. This is a prerequisite for dynamically reducing the number of returned fields to the query, thereby allowing a decent performance of these reports.
Especially in the Finance- & Accounting area you will come across many cubes with detail fields because sometimes you simply need to perform analysis on ledger entry level. But this seems like a loose/loose scenario in my eyes: Not only do these detail reports often perform badly, their biggest negative impact might lie in the fact that they cause the fact tables to be x-times bigger than the next aggregation level, thereby decreasing the overall performance of the cube.
So how about this approach then: Use Power Query for your reports on detail level: Directly connect to your fact table in the DWH and merge to your SSAS-data in order to retrieve the attributes/filters only. Or keep your fact tables in a dedicated DB if your DWH serves other purposes as well and you fear the performance impacts of those queries.
So this would leave the cubes’ fact tables with much less data -> improving performance.
I tried some scenarios that worked fine. But putting the fact tables into a separate tabular model instead of a relational DB performed quite badly.
Does anyone have experience with this approach? If you know someone who might, please forward.
What do you think about this approach, any other obstacles I’ve missed?