My programming career began a long time ago. Back then a wise guy gave me a copy of Visual Basic 6 Pro. Since then I have come a long way. Although I want to make clear that I’m neither a hardcore programmer nor a extraordinary talented geek. My goal was always to get the job done.
So after many years of programming in Visual Basic and even VBA I got in touch with Microsoft Dynamics Attain 3.60. My first impression of the C/SIDE programming environment was the feeling of a cutdown version of the Visual Basic IDE. So I felt immediately at home. And C/SIDE was very efficient for my requirements. But of course also a bit boring too. Soon I was playing with com-add-ins again and later there came .net interop. And this felt good. Besides of NAV I invested quite some time into SSIS and there I really liked the script task the most. You had the full power of the .net framework but in a simple and cut down environment. Visual Studio always seemed a bit overwhelming to me. The following years I lost a bit of my coding hunger. I was more interested in things like SQL, Database Design and later the Power Platform rise really got me excited.
Then a few years ago suddenly Microsoft NAV or BC began to change. Suddenly we had a solid three tier architecture. We were confronted with extensions V1 and V2. This got my attention but I was not totally on fire. But this has changed in the last few months.
I did spend some time with Visual Studio Code and my verdict was – Yes, I like it.
I did spend some time with AL and the new concept of extensions and yes again, I like it.
The cloud, Azure functions, the Azure Stack itself, yes once more, I like it.
Now I’m again on fire. I feel excited as there are some many new things to learn.
Sure not all I easy or straightforward. A lot of things feel much harder to achieve now with regard to the new boundaries and Microsoft’s cloud first strategy. Nevertheless I’m willing to follow this path. I like the concept of bringing different pieces of software together. Running an Azure function from NAV BC to create a word or excel file seems pretty crazy but nevertheless I like it. I almost feel young again. Is this a midlife crisis – maybe but for me it feels right and that’s what counts. You should love the work you do. And you should never loose your hunger to learn new things. So yes I’m ready for the challenge. Let the games begin.
I like this explanation very much. Alberto Ferrari is really good at describing complex topics in an entertaining way. I see a lot of potential in this feature and not just for large enterprises. I like the idea of keeping the data in the cloud and only enriching it with new data and measures. And the new concept of chaining datatasets is also very exciting. And this is probably the first time I’ve heard anyone talk about DirectQuery without making a disgusted face.
This looks like a perfect real-world scenario for me. In the last few months I have moved a lot of my personal resources to Azure. Inspired by this article I will try to build an Azure Management Tool with PowerApps
A month end procedure is a regular topic to be covered when implementing finance with D365 BC. Some finance systems throw a user into a defined routine but with D365 BC it’s much more simplistic. To remove the need for users to be experts wouldn’t a defined routine be useful?
Here is the goal: Create a Power Automate flow that will handle the month end procedure in BC with minimal user input. Principal thing here is that month end is routine so why not have something to cater for it. Caveat here being that job knowledge makes up for a big portion of this finance process so not all of it can be catered for. The scope is laid out in the next paragraph.
So what makes up a month end in BC and what is the scope of this procedure?:
Back in August I highlighted the new dataflows PowerShell script repo on GitHub. These scripts provide an accelerated starting point to working with the dataflows REST APIs and to automate common dataflows tasks. This week the dataflows team has released two new REST APIs for managing dataflows transactions (think „refresh“) and a new parameterized PowerShell […]
The idea is basically to copy the entire report (pages, filters, bookmarks,…) between two different Power BI Desktop files (.pbix).
Why this is useful? Imagine you are building a new Power BI Report and you need to reuse the entire layout from another report not only the visuals but also the layout, pages, themes, custom visuals,… Yes the dataset will be different and the report visuals will stay in an error state like this:
Yes it seems broken , but the entire layout is there and is easy to change the field of a visual to a new field of the target dataset by drag & drop a new field
To do this you just need to follow these simple steps:
Unzip the source and target PBIX files using a tool like 7zip