Skip to main content

Exploring Analytical Options with Dynamics 365 Finance and Operations: Link to Fabric

I’ve recently been exploring various analytical options within Dynamics 365 Finance and Operations, and one that I’ve delved deeply into is Link to Fabric.

There is a walkthrough guide available on the Microsoft Fasttrack Github repo. See Hands-on Lab: Link to Fabric from Dynamics 365 finance and operations apps

This guide is an excellent starting point and should be one of the first things you try out. However, it’s important to understand that there are limitations to this approach that may not be suitable for all real-world scenarios. Lets discuss these items and what I have been exploring ...

Background

I want to join multiple tables to create my denormalised views that I can report on. My goal is to use Direct Lake mode in the semantic model. Specifically, I wanted to avoid the need to reimport data into Power BI for reporting. 

Key Limitations

The first limitation you’ll encounter is:

By design, only tables in the semantic model derived from tables in a Lakehouse or Warehouse support Direct Lake mode. Although tables in the model can be derived from SQL views in the Lakehouse or Warehouse, queries using those tables will fall back to DirectQuery mode.

FinOps is highly normalised and following the Microsoft lab which uses views would not work for me. 

Solutions

A solution to this problem is to create a delta table that I could load from the query/view.

Here are several ways to to do this:

1. Import Data Using a Data Pipeline: This method is easy to configure but can be slow and is not ideal for large volumes of data. Only works within the same workspace.

2. Import Data Using Dataflow Gen2: Also easy to configure, but the limitation is that the copy only works within the same workspace.

3. Import Using a Stored Procedure: Simple to set up but shares the same limitation as Dataflow Gen2, working only at the SQL analytics endpoint level and not across workspaces.

4. Import Using a Notebook: This method has a higher learning curve but offers the best performance and flexibility.


Scenarios

For me, I would lean towards using Notebooks. I have explored Spark SQL option as that was the lowest learning curve for the different languages you can use in a Notebook.

Below is a simple query to get you started. It assumes you have the tables already exporting in fabric.

Select statement with a join

A simple select query to get you started with your first notebook.
%%sql
SELECT 
    party.recid AS PartyId
    ,party.name AS Name
    ,COALESCE(party.namealias, '') AS ShortName
    ,COALESCE(postal.countryregionid, '') AS Country
    ,COALESCE(postal.state, '') AS State
    ,COALESCE(postal.city, '') AS City
    ,COALESCE(postal.street, '') AS Street
    ,COALESCE(postal.zipcode, '') AS PostCode
    ,COALESCE(phone.locator, '') AS PhoneNumber
    ,COALESCE(email.locator, '') AS Email
FROM dirpartytable party 
LEFT OUTER JOIN logisticspostaladdress postal ON postal.location = party.primaryaddresslocation
AND postal.validto > current_date() -- filters only valid(effective) addresses
LEFT OUTER JOIN logisticselectronicaddress phone ON phone.recid = party.primarycontactphone
LEFT OUTER JOIN logisticselectronicaddress email ON email.recid = party.primarycontactemail

You should see a table result showing below your query.




Create table if not exists

Next level is to create a new delta table and copy your selection into it.
%%sql
CREATE TABLE IF NOT EXISTS fact_dirpartytable 
USING DELTA AS 
SELECT 
    party.recid AS PartyId
    ,party.name AS Name
    ,COALESCE(party.namealias, '') AS ShortName
    ,COALESCE(postal.countryregionid, '') AS Country
    ,COALESCE(postal.state, '') AS State
    ,COALESCE(postal.city, '') AS City
    ,COALESCE(postal.street, '') AS Street
    ,COALESCE(postal.zipcode, '') AS PostCode
    ,COALESCE(phone.locator, '') AS PhoneNumber
    ,COALESCE(email.locator, '') AS Email
FROM dirpartytable party 
LEFT OUTER JOIN logisticspostaladdress postal ON postal.location = party.primaryaddresslocation
AND postal.validto > current_date() -- filters only valid(effective) addresses
LEFT OUTER JOIN logisticselectronicaddress phone ON phone.recid = party.primarycontactphone
LEFT OUTER JOIN logisticselectronicaddress email ON email.recid = party.primarycontactemail

This is a one of copy and will not copy data if the table exists already.

Next blog post, I will cover a few different scenarios.







Labels:

Popular posts from this blog

Approve Workflow via email using template placeholders #Dyn365FO

Dynamics 365 for Finance and Operations has placeholders which can be inserted into the instructions. Normally you would want this to show up in the email that is sent. One of the most useful ones is the URL link to the exact record that you are approving. In the workflow configurations use the placeholder and build up your message. Towards the end it has workflow specific ones. The URL token is %Workflow.Link to web% . For the technical people the token is replaced in this class WorkflowDocumentField. This is what I inserted into my email template. <BODY> subject: %subject% <BR> message: %message% <BR> company: %company% <BR> for: %for% <BR> </BODY> Should look like this. The final result looks like this. If you debug these are the place holders that are put together.
Read more

Purchase requisition – Price

The price fields on the purchase requisition are non-editable for catalogue items. It is expected that a trade agreement be created. The price fields are only editable for these conditions: Form is opened view AP -> Periodic -> Purchase Requisition -> All purchase requisition, or Line type is “Non-catalogue item”, or User is task owner. Ie. The task is assigned to the user. In other words he/she maybe the purchaser that gets the price. User is approval owner. Ie. The approval is assigned to the user. In other words he/she maybe the manager that approves the final requisition. For catalogue items on the purchase requisition line can only select between the vendor directly associated with the item and the cheapest vendor as found through the purchase price trade agreements. If another vendor is requested the vendor can be blanked and the user can enter a “Proposed vendor” in the proposed vendor field on the general tab page for the purchase requisition line.   NOTE: ...
Read more

Dynamics 365 Invoice Capture Feature

Microsoft recently released the new Invoice Capture for Dynamics 365 Finance. I ran through installing and configuring it.  From that experience, below is my brain dump and hopefully it can help with things that are not so obvious. Three type of invoice captures There are three invoice type paths that can be captured. These drive the screen layout and what kind of information is mandatory. PO invoice Header-only Cost invoice When an invoice comes in, you can select one of the three invoice types. Below are the three screen layouts and differences. PO invoice – Invoices of this type are associated with purchase orders. The purchase order details must be determined on each invoice line. Both the header and the lines must be reviewed in Invoice capture. This will create a pending vendor invoice. Header-only – Invoices of this type are associated with purchase orders. The purchase order field on the invoice header is a mandatory field. If the Automatically create invoice lines featur...
Read more