Microsoft Dynamics 365 Business Central can import CSV files. It’s done with the wrongly named XMLPort (at least for this purpose) objects. The challenge is to get the indentions right, so here is a barebone XMLPort object that will read a CSV file.
The important parts are the setting Format that uses the VariableText type and getting the initial indentation right. Copy this into Visual Studio Code, and you’re up and running with CSV files and Business Central in no time.
I have been sitting in on a few meetings with potential clients for Microsoft Dynamics 365 Business Central and a pattern has become clear. “We”, as the people in the NAV channel, were used to have a handful of go-to-answers, handling the usual customer requests. Most of these answers are rooted in modifying standard objects or selecting certain 3rd party ISV solutions. And a great deal of these answers needs updating.
Sure now we have all the *extension style objects and many changes can easily be made with those. But a lot of the changes we were used to making without much effort cannot be made easily with Extension V2.
And sure, there’s a lot of 3rd party ISV solutions in AppSource, but many of the existing NAV 3rd party solutions does not exist for the cloud yet, and even if the same ISV exist both for NAV and in AppSource it might not be the same product with the same capabilities.
So what’s the rambling all about? Well, it’s about educating our surrounding about the possibilities with BC in the cloud, the limitations, and the differences compared to NAV.
For the non-technical NAV and BC folks out there, this is what we can do on standard objects (tables and pages for now):
Add fields to tables
Add fields to (* most) pages
Add actions to pages
Add code to objects, but only access new fields, Rec and global functions that has been tagged to be exposed to us (*)
Hide fields or actions on pages (Set visible = false)
Move existing controls around
Change some properties on existing fields and actions
(*) Code on existing objects is complicated. Some objects, like matrix pages, relies heavily on global variables and local functions making it impossible to extend them in any meaningful way.
In many cases there are workarounds available to make most requirements work, but something that would be a one liner in NAV might be a much bigger effort in BC.
One option is to duplicate standard pages and replace actions to invoke our own versions. That’s a cheap way to get it to work, but it does add technical debt to the solution since you’ll have to keep your duplicated pages updated with the monthly updates from Microsoft.
So, to all of you non-technical people in our channel, be aware, that even though Business Central is just the next version of NAV, as soon as you enter the cloud or in a 100% extension based model on-premise, the rules have changed.
Reach out to me on Twitter @eHougaard and lets talk about the new challenges and solutions.
Just had a funny little mixup that threw me off for a few seconds…
Let me explain. I’m working on a Business Central customer, in the cloud. I have connected Visual Studio Code to the sandbox instance with the standard launch.json setting:
I wrote some brilliant code and hit F5 to start debugging. Strange, the language has changed in BC, debugging should not do that?
Suddenly I realized, that I’m connected to a different BC instance, a session I was logged into before. BC does not complain about the extension I’m trying debug is missing from this instance or anything.
So beware, remember to log out and don’t get the streams crossed, because that’s bad according to Egon Spengler 🙂
If it seems that you cannot log out, make sure to remove all cookies stored for businesscentral.dynamics.com
An adventure in Microsoft Dynamics NAV, .NET and other technologies