Reconciling the Dynamics NAV inventory against the G/L can prove to be quite complicated. The number of elements influencing the inventory span across most of the application, and include:
Some time ago, Mark blogged an interesting article about running objects from extensions. You can read it here: https://markbrummel.blog/2017/05/20/tip-58-run-extension-objects/
It made me wonder .. how would I solve this? And one of the problems of asking myself these kind of questions is .. the answer is always the same :-/:
Well, actually, Jan, everything you always wanted to know about automated testing in NAV and did ask me about. 😉
Thanx for starting this creative little experiment, allowing to elaborate somewhat more on some aspects of automated testing. Maybe needless to mention that my answers reflect my knowledge and experience and are in no way the one-and-only truth.
This is the first part of Automated testing with Permissions, in this post I’ll visualize and explain the way it’s described on msdn and in part two I’ll go for a more practical approach which will support permissions per test function and partially executing code with a permission set.
I said a word or two about progress last week. Apparently, VS Code is not the only place where we take a small step back to be able to make a huge leap forward; .NET might seem like another one.
You know it, right? You know that if you want to run your .NET code in D365 for Financials, you are out of luck, and you do know that this applies to as much to Microsoft .NET Framework out-of-the-box types as it does to your own, custom-built .NET assemblies.
One elegant way of replacing your .NET interoperability code with something else is by using Azure Functions. Sounds good in theory, but what does it take in practice? And what are Azure Functions, anyway?
Let me not take too much latitude, and let me just say that Azure Functions are a way of running simple pieces of code as a service that you can invoke like any other RESTful web services.