Another NAV TechDays is over, and again, needless to say, it was a splendid conference. Thanks to everybody who attended one of my sessions about .NET Interoperability: the pre-conference workshop for beginners, the session for beginners, and the advanced, or as I like to call it, the “Black Belt” session.
As I promised, I’m making all materials available for download here on my blog, and Luc will also make the recordings available from Mibuso.
If there wasn’t one already, someone should have invented Belgium. There are two things in this world that I love, and probably shouldn’t (and an oversized red speaker’s shirt I got from Luc today did a darned god job at concealing the unlucky consequences of overly indulging in both of them): beer and chocolate. Boy, do Belgians know their beer and chocolate!But they know their NAV, too, and after NAV TechDays 2011, which have just ended in Antwerp, and two days of top NAV content, I can only say – great job, Luc and the team, and please make it a tradition.
If you attended my presentation about .NET interoperability, then there are a couple of demos I couldn’t deliver due to time constraints, and I promised to blog it. So, here we go.
It’s about streams. You already know that in NAV there are two data types, InStream and OutStream, that allow you to stream data in and out of generic sources or destinations. They are a fantastic tool, because they require you to know nothing about the type of source or destination, and you can store and retrieve data without having to care if the data comes from Internet, or a BLOB field, or is it written to a file, or transported over an XMLport. Stream makes it abstract and allows you to simply handle the data, and make the object itself care about the specifics.
If you try exposing Page 5 Currencies as a Web service in Microsoft Dynamics NAV 2009, and then consuming this web service through a .NET application, you are almost guaranteed to encounter some unhelpful and generic XML errors that give you absolutely no clue about what exactly, where and why, went wrong.
Here’s an example of the error:
There is an error in XML document (1, 3634).
The error took me a while to debug and pinpoint the source, but in the end I managed to find a neat solution which I find worth sharing here, just in case somebody out there is scratching their had over it.
A year ago I used to run a monthly roundup of NAV blogs and give you a short gist of who said what. Then I got lazy and stopped blogging on the weekly basis, and boy what a mistake I did – because some nice new blogs appeared in the meantime. I am somewhat ashamed that I learned about this blog only recently, but there is a gem out there you shouldn’t miss: Van Vugt’s dynamiXs.
Often you don’t even notice how quickly time goes by, except for a few milestones, which happen once a year and remind you that another one’s over.
WinDays conference is one of such milestones, and I’ve barely published a handful of posts here since the last time it was the most discussed topic in Croatian IT community. So, an incredibly short year later, here’s another one: WinDays9.
Agile has been gaining momentum among software development methodologies for past decade or so. Various researches and surveys consistently show that software developed under an agile approach is generally better than the software developed under waterfall approaches.
At the core of any agile approach is an assumption that whatever the requirements might be at the beginning of a project, they won’t be the same at the end of the project. The longer the project, the more truth there is in this assumption. To mitigate this situation, agile methodologies start with smaller sets of requirements, they start small and deliver functionality incrementally in a series of releases. No single release covers all requirements, but every release delivers more than the previous one.
With ERP implementations, we generally don’t subscribe to this idea. And at that, we might be wrong.
Last week I delivered the C/SIDE Development course for partner community in Zagreb. As always, questions abound afterwards. Today, I’ve got a question from an attendee: “What’s the best way to print a report in multiple languages?”.
Up front: this is NOT a technical post. It IS about technical solution, but it is primarily about design, usability, standards and best practices. I’ll plain ignore the fact that it does use a few C/SIDE or C/AL references, so please, do likewise 😉
(I said this because I kind of swore not to C/AL around this blog anymore, but again – sometimes I just have to do it.)
For a long time, the ruler of project reports was Standish Group’s (in)famous Chaos report, which analyzed IT project success/failure factors. While many of the Chaos report’s findings applied to ERP implementation, the report as a whole was primarily about software development projects. And as we all know, implementing ERP is not the same thing as software development. Hopefully.
Panorama Consulting Group, an independent ERP consulting firm from Denver, Colorado, has conducted a market research in 2008, that explains ERP implementation project success factors and reveals some interesting metrics about real ERP costs, duration and benefits. Finally, we have a decent ERP project report, which reveals some important facts about Microsoft Dynamics.
A short story about maritime trading, steamboats and Microsoft’s Azure Services Platform in short to mid-term ERP and Microsoft Dynamics NAV perspective
This is a story of a business which failed, and it didn’t have to. It had all the capital and resources it needed to grow, it held a solid share in an expanding market. And yet, they failed.
Associazione Marittima di Sabioncello (AMS), or Maritime Society of Pelješac, was a shipping company founded in 1865 in Orebić, a small coastal town of southern Croatia. They grew to a fleet of 33 sailing ships, they shipped worldwide, their business expanded so much that eventually they built their own shipyard. Allegedly, they were one of the biggest and most prosperous maritime merchant companies in the Mediterranean.
And then an innovation came along, which ruined them.
Implementation is like marriage. For better or worse, you choose a piece of software, take it under your roof and commit to it for a long term, so help you God.
And as in marriage, if you want to live happily ever after with your new software, the my way or the highway attitude doesn’t help much—you must be open to compromise.
Last Monday, I argued for avoiding customizations if at all possible, an argument I stand by firmly. It’s like forcing your wife to color her hair pink. I don’t know about your wife, but mine doesn’t color her hair pink. If you like it pink, it’s probably something to think about before turning your yes in.
But NAV is NAV, isn’t it? It has what it has, and if I need it different, I have to customize it, right?
Wrong. You can compromise.