Almost 2 weeks to Christmas and very busy period, not only for job reasons. I’d like to be ready to share some technical trick or some solution using extensions, but I’m working on a lot of stuff and nothing is completed yet. Anyway, because I have a lot of “things” in my mind, I’ll write something “light”.
OK. I won’t talk about specific NAV / BC bugs or features. So the title can be deviant. But… How many time did you read or listen the answer “This is not a bug. It’s by design!”?. I think not so few times.
I like standard. I like to use the product “as is” as much as possible. Even if I come from development experiences, I realized that the more you don’t “touch”, the more you can easily maintain the environment. Very simple? Not at all. You know better than me, customers want a lot of things, partners produces a lot of solutions adding features, but overall it’s very difficult to find repeatable situations. I know, this is the new “mantra”: repeatability. Is it so easy? Sorry Microsoft, I don’t think so. At least in my Country. I can bet: every customer I meet, says: “We have standard processes. We do as every company do. We think it will be easy to use the standard functions”. And every time, it doesn’t happen. Till now.
In this moment – yes, while we, partners, are moving our IP from NAV to BC – I can meet a “new generation” of customers that is ready to adapt themselves to standard. I’m not completely sure about it, but it’s a good perspective. But.. Are we ready? And… Is this product ready? I don’t really know.
If we think about Business Central, we can consider it as a big container full of a lot of ready features, but not “completely complete”. But I love what it has. As standard. And I like to use it.
Do you really need customizations?
Every time I have to think about a solution, I ask to myself: is a customization really necessary? I don’t know if you remember the “C/SIDE (Solution) Development” Course for the relative exam. I took it twice (on 2009 and 2013 versions) and I’d really like to take it again – Microsoft, please, new certifications are needed! – and even if the exercise was almost the same, it made me think. The course suggested to use standard features for a completely different context (in short: using Resources to manage Courses), but the solution fitted perfectly! Why you have to develop new functions when the system already provides them? This is the point. Very often deploying a solution means modifying the code base in a real deep way, changing structures, create new modules without a complete integration with other ones and other things that are not so good.
In this moment, fortunately, if we want to think about the future, we are obliged to develop using Extensions. This is a very good thing. If you really think about it, you can easily realize that with Extensions you maintain the core, you only add features, in a way that let ensure the system life.
On the other side, you’re completely put yourself in the product’s hands, because you believe that every single process and features work properly. Is it right? Well… Mmm… We love NAV/BC… But… Do we trust in it? I trust in standard code more than in customized code. Even if I find bugs. Or “by design features” (and I’m not talking about the “XXX ByDesign” competitor product!).
Know the limitations
If you know the product, you know its qualities but you should (or must?) know the limitations too. This can help you to prevent problems with customers and to know how to manage critical situations.
Last week I’ve really appreciated this post by Roberto Stefanetti about “Undo subcontracting receipts”. This is a perfect example (with a very good solution!) of a critical situation: if you cannot undo a receipt (and, moreover, as in this case, the page shows you the button menu with the function “Undo receipt”), I bet the customer will say “It’s a bug. Fix it!”. For free, obviously. If you open a support request to Microsoft, they will say: “It’s by design. We didn’t implement that function and we don’t know if we’ll develop it in future”. In this case, you have 3 solutions:
- Create a function that implements what you need: this is a permanent fix and let the user free to use it when needed… follow Roberto!
- Update data (a very easy operation on a cloud solution…) to fix the problem every time it happens: this means the every time customer needs it, you’ll be called!
- Hope customer will never need it… Pray! 🙂
So, I don’t really know if it can be considered as a bug. The following example I think is a “very by design” feature. Always talking about subcontracting, as explained here, “To avoid that the expected output of a production order is posted when subcontract purchases are received, make sure the subcontracted operation is not the last one. Alternatively, insert a new last operation for the final output quantity.”. For me, this is not a bug: it’s the system behavior. And the only way to prevent problems is to know it.
Open support requests!
But how to prevent bugs? For customizations, it’s very simple: avoid them! Of course, if you can. If you can’t, develop strong solutions, external and connected if possibile, not inside the existing structure: think in a “modular” way.
And for product’s bugs? The best way is to prevent them for all our colleagues, so: open a ticket every single time you find a bug! I must say this thing because it’s not so obvious: often happens to find a bug, to know how to fix it, and choice to fix it only there, without sharing. Bad choice! The only way to make NAV and, moreover, Business Central On Cloud loved by users, is to make their standard code base stronger, day by day. Do you want a good product? Make it stable, make it fixed: so, communicate bad behaviors.
Recently we had to open many tickets for different reasons: most of the were easy to fix, but we always decide to share the problem with Microsoft in order to make it fixed for next versions. Although I have been opening support requests for 13 years, a thing I didn’t know was that, if I open a case on a version – and it’s a bug – it will be fixed only starting from that version. So, if you find a bug, please:
- find the time to open a support request;
- try to reproduce the problem in the oldest supported version (or the oldest one that provides that specific feature);
- fix the problem with the solution provided by Microsoft (it could be different from the your one);
- keep updated your NAB/BC as much as you can;
- enjoy the fact that the new versions will be already fixed thanks of other solved requests! 🙂
Some weeks ago we discovered a “by design bug” on Business Central. The “Lot Information” feature, starting from Item Ledger Entries (“Lot No.” field), was working in RTC Client but not working on Web Client, this because the “OnLookUp” trigger is not completely supported in Web Client: so, this feature was working properly On Premises but not On Cloud. Once opened the request, my friend – and super hero ironman – Duilio Tacconi told us how to simply fix it in our environment: move the code and use the “OnDrillDown” trigger (as officially explained here). Very simple. But the most important thing is that Microsoft decided to do the same.
And this is the only way to fix bugs On Cloud.