Most of you, if you are a more or less loyal reader of my blog, will remember that last year I blogged about breaking up the base app, how to do that and a call to action for volunteers.Continue reading
When I write a blog, and I should write more I know, it’s most of the time to share a tip or to write my opinion on something.
This blog is more of a question, or a call to share knowledge of a piece of technology that is not used by many.Continue reading
A new version of Business Central is around the corner. The codename is BC16 or 2020 Wave I. Both are the same thing.
I think it is safe to say that Business Central is a great succes. In the competing world of Cloud Business Solutions it is the most flexible product and the customer base is growing rapidly.
Business Central has a fantastic user interface and the extensibility model is next to nothing else out there.
Last week I was talking to a reseller of Business Central on the west coast of the US. He said he was small reseller since he only sold 10 installations in 2 years. Yes, he was new to BC and had no prior NAV experience.
Knowing that in the old world NAV resellers often only sold 3 licenses or less per calendar year I had to laugh a bit.
Cloud brings both challenges and opportunities that are beyond anything we have ever seen in our ecosystem.
I can see the opportunities from my perspective as a freelance developer. The demand for AL developers is insane. In Europe it seems to be doing ok, but in the US they are screaming for resources.
As for the reasons I can only guess, but it seams that growth of Business Central is happening most from outside the traditional NAV world. New partners are jumping on the opportunity to then find out that implementing BC almost always means implementing a few changes that require per-tenant extensions.
Many traditional NAV resellers still struggle with Business Central because of two reasons.
- Their IP is a big mess
- Their COGS is too high
Also, almost always they know nothing about the Azure stack and integration with Office 365.
In my opinion it’s time to change but this seems very difficult. NAV partners have a very expensive (pre) sales department that is funded with large license revenues. Their Developers have been rewarded for 20 years to deliver crappy hacks in C/Side that only had to work as quickly as possible to then start on the next hack.
I’ve seen situations where it was considered “normal” that the service desk employees of a partner logged into a customers system almost on a weekly bases to fix data with reports and customers actually pay premium service for this.
Grim Reaper in the NAV ecosystem
It seems so hard to change, that many owners of traditional NAV resellers choose the easy way out. They sell their company to investment companies.
This is probably also due to the current economy where interest is at an all time low, stock markets are way overpriced (although “Corona” settled that last week) and money is looking to be spent.
Titanic or Oil Tanker
It’s not the first time that the faith of our ecosystem is influenced by global economy. When the Three Tier concept was presented the world decided to have one of the biggest recessions in history.
If you had asked me two or three years ago I would have compared Microsoft to Titanic. In all their glory they wanted to go so fast that they ignored all the rules and headed straight for an iceberg.
Now that Business Central is being picked up by new partners and a (small) subset of the existing NAV ecosystem I am a bit more positive. Actually a lot more possitive.
Today I would compare Microsoft more with an Oil Tanker that is trying to change course but it is going insanely slow. People at the bridge are giving orders to change direction but by the time this is happening it’s (almost) too late.
Now is the time!
It’s easy to say to existing NAV partners that they are too late, but that is unfair and not true. The ERP world is moving a lot slower than Microsoft wants. ERP is not implemented at startups but at companies that have been in business for a longer period of time.
Business Central 2020 Wave I contains a few changes that are important for the old NAV ecosystem. The most important ones are the actual implementation of Enum’s, the introduction of flexibility of the sales pricing module and integration with Common Data Services.
Microsoft is listening but change is slow, but slow sometimes is good.
Oops, they did it again
The previous release of Business Central caused a massive riot because Microsoft broke the majority of Apps published by their partners on the AppSource. This resulted in a lack of trust and the compeition even started to use this as selling against Business Central.
Microsoft made a drastic, but important executive decision to promise not to make breaking changes anymore.
Unfortunately this seems to be an impossible promise since the enum implementation again breaks existing extensions, although I think it will be a minority this time. I haven’t checked this however.
Since Wave I 2020 is not officially released Microsoft might actually decide to fix this. Let’s see what will happen.
Small NAV Partners, now is the time!
A few things need to happen.
- Stop paying sales people that cannot even do a proper demo. They are not needed anymore. Instead you need industry specialists that understand the customer.
- Stop calling everyone who can make a change to C/Side a developer.
- Embrace Azure
What if they don’t?
What we see in the US will happen in Europe too. New partners will start selling Business Central that don’t have the legacy. Legacy in expensive sales people and legacy in bad code. Even legacy in stupid customers who accept crappy solutions.
It’s time to decide which side of the Business Central ecosystem you want to be part of, because Business Central will continue to be the best ERP in the cloud, with or without you.
Developers don’t have to be affraid of the future. If you are willing to let go of writing fast and crappy solutions and invest in repeatable quality apps the future is fantastic.
I have not blogged as much as I want to recently. Not because there is nothing to write about, but because I am so insanely busy.
However, today I ran into a question that required first Google and then Statical Prism to solve.
UTC Calculation in Dynamics NAV (Or Business Central)
This used to be cumbersome and required dirty tricks. Alternatively (and this is how I managed to solve it until today) you can setup a UTC service tier.
But, with the help of Prism I found that Codeunit 358 now has this code
[External] ConvertToUtcDateTime(LocalDateTime : DateTime) : DateTime IF LocalDateTime = CREATEDATETIME(0D,0T) THEN EXIT(CREATEDATETIME(0D,0T)); DotNetDateTimeOffset := DotNetDateTimeOffset.DateTimeOffset(LocalDateTime); DotNetDateTimeOffsetNow := DotNetDateTimeOffset.Now; EXIT(DotNetDateTimeOffset.LocalDateTime - DotNetDateTimeOffsetNow.Offset);
So no more stupid workarounds, just use this instead.
Please hold on for more stuff on my blog. I recently converted one of my customers to SQL Azure with Windows Virtual Desktop, Azure Logic Apps, Blob storage & Azure Functions. So much to blog about. #ServerlessComputing
I’m also starting on a new contract next week that will help me multiply my skills in an efficient way. Very enthousiastic to try that out for the first time.
So hang on and keep coding….
Yesterday at Microsoft I had two meetings, or goals. The first as you know was about our initiative to do a proof of concept to break the BaseApp into smaller extensions.
The second meeting was about revamping the old Design Patterns we had for Dynamics NAV and bringing them up to speed for Business Central.
For those of you who don’t know or to refresh memories; a few years ago there was a joint project between Microsoft and the community to document Design Patterns.
The old patterns wiki still exists but there have not been any updates.
I love a nerdy title and I love learning about cool new smart stuff.
But before you continue reading I want to say thanks to my colleagues at ForNAV, especially Michael Nielsen. Without him pushing me (again) to step out of my comfort zone this would not have been possible.
Yesterday I visited the Microsoft office in Lyngby for the first time in a very, very long time to talk about our project to split up the base app. We also talked about something else, but that will be another blog. (Soon…).
I often wonder how I find myself in situations like this. On my day off I find myself behind my desk doing something which is not my responsibility, nor am I getting paid to do it.
If you say A, you also have to be willing to say B and C. This is what my parents told me when I was young so when I promissed Bugsy and Jesper to look into making the Business Central Base Application smaller I decided I may as well make it into a decent project.
Social media is fantastic and it can be used in many different ways. Where most people are mostly consumers others use it to ask questions. Some share knowledge and experience and gain loyal followers. This is pure awesomeness and mostly rewarded with the Microsoft MVP award for those who don’t give up.
Very few succeed in using social media to drive change. Those who do are known by many such as Elon Musk and Greta Thunberg.
So to continue where we left off yesterday when I did a pull request on the Business Central System App project on GitHub.
After my pull request someone at Microsoft did a code review in order to make sure quality standards are respected. Here are the details:
I have to admit something. First of all, this is not actually my code. It came from my colleague Michael Nielsen. Secondly this blog post is a bit orchestrated since Jesper and I discussed in Antwerp at NAVTechDays how to promote people contributing.
Working with Microsoft is pretty tough since your doing code for millions of users, not just one customer. Business Central should be easy to use and if you call the culture info with for example 0 or 80,943 you’ll get an error explaining that the language does not exist but not in an easy to read way.
I’m tempted to follow the idea to wrap the call in a TryFunction, but that means introducing a readeable error message, which includes translation and I am worried that will delay my pull request.
An alternative is to wrap it into a try function and return the orriginal integer if the call fails.
What do you think? It proves to me that coding for millions is a lot harder than it looks.
With the recent Wave II release of Business Central we also got the first wave of Open Source in our beloved NAV/BC product.
This means that rather than making customization for one specific customer or ISV you can now have this pushed back into the product and stay there forever.
Today I did my first Pull Request and I wanted to share how I did that.
What did I need?
With reports, especially documents that go out, translations are key. In the next release of our ForNAV extension we wanted to add a new feature where you can translate invoices by simply adding captions to a table or import them from an Excel sheet or Azure Blob Container file.
With translations there are rules that allow you to inherrit languages from related languages if they are related. For example Flamish (NLB) can be inherrited from Dutch (NLD).
Especially in Europe this drastically reduces the number of translations and you only have to manage exceptions where terminology is different. (Trust me, this is the case with Flamish and Dutch).
I actually only need one line of DotNET code
Normally you are not allowed to do DotNET, but System App has target set to OnPrem so simple usages of DotNET are actually allowed. (I hope).
Fork & Clone
The first step is to log into GitHub and Fork the Microsoft ALAppExtensions project and clone this to your Visual Studio Code
Branch & Publish
Then you do the change. Remember Microsoft has this two-layer model where your real code is in the implementation.
Pull Request & License
The final step, or at least where I am now, is to do a pull request and sign the license.
After this you need a code review and this is what I am waiting for right now.