Dynamics NAV / Business Central Developer Digest - Vol 388
ArcherPoint’s Developer Digest focuses on Microsoft Dynamics 365 Business Central development and Dynamics NAV development. In Developer Digest Volume 388, we discuss BC custom table indexes, printing documents from BC SaaS, and the ongoing discussion around saving BC extension design changes.
The Dynamics NAV and Business Central community, including the ArcherPoint technical staff, is made up of developers, project managers, and consultants who are constantly communicating, with the common goal of sharing helpful information with one another to help customers be more successful.
As they run into issues and questions, find the answers, and make new discoveries, they post them on blogs, forums, social media…so everyone can benefit. We in Marketing watch these interactions and never cease to be amazed by the creativity, dedication, and brainpower we’re so fortunate to have in this community—so we thought, wouldn’t it be great to share this great information with everyone who might not have the time to check out the multitude of resources out there?
So, the ArcherPoint Microsoft Dynamics NAV/BC Developer Digest was born. Each week, we present a collection of thoughts and findings from NAV/BC experts and devotees around the world. We hope these insights will benefit you, too.
Exploring Business Central Custom Table Indexes
Steve Endow explores Business Central custom table indexes after looking in SQL to see what custom fields look like in the database for a BC table extension. He found the table index that is automatically created for the extension is a clustered index. Learn how to create multiple keys and more in his post.
Printing Documents from BC SaaS
Tom asks: “Does anyone know if there’s a way to automatically print attachments in BC SaaS? The customer mostly wants to print PDFs, but they’d love to be able to print anything attached to a posted purchase invoice.”
Matt T replies: “I’m starting to be convinced the only reasonable way to do this is with printers that will accept a print job via email…i.e., email the document as an attachment to a printer, and it will print it. Everything else is just way too complicated and not cost effective in comparison in my opinion.”
Kyle agrees: “He’s right. Universal Print, Email to Printers.” He then adds, “Although OnPrem, you do have the DotNet option.”
What’s Your Protocol for Saving Extensions of Design Changes in Business Central?
Elizabeth asks: “When a customer, or even I, make design changes to a page in BC, what should be the best practices for saving the resulting Extension? Specifically, the customer is concerned with making sure that they follow any protocols ArcherPoint uses so changes are still supportable from ArcherPoint’s end. By protocols, I am talking about naming conventions, installation procedures, creation procedures, etc.”
Understand readers, that this has been a hot topic inside the ArcherPoint walls since BC came about…
Kyle Hardin jumps in: “Hooray! Another Matt vs. Kyle slap-fight! This was such a PITA that I disabled that feature. This was a customer with low technical skills, and they didn’t even know they were creating mini extensions. When they’d save the page customization, BC would choose the ‘next available’ page extension object number. Even though I asked the customer to notify me when they made these changes, that never happened. I’d use that same PE object ID, and then code deployment would start failing. For a while, I was trying to be flexible, and I would take apart their extension, do the same change in our actual app, and then delete their extension. As I said, very time consuming. So, I shut it off, and now all page customizations happen as change requests, and we do the development. If you have a highly-skilled customer, one who knows about Git repos and DevOps and how to co-develop with partner developers, then go for it.”
Matt adds: “Agreed it’s a PITA. If we’re not going to get rid of object IDs, I wish Microsoft would just put all these in a range that normal development can’t be done in. Turning the feature off in consultation with the customer is certainly fine by me, but I wouldn’t just do it without informing them. The flip side is that they have been able to do this…for forever, even on C/AL. But now, it’s easier and affects us…. usually late at night when we just want to go to bed. I don’t have a better solution than to just deal with it.”
Tom chimes in: “Microsoft’s implementation of the BC Design functionality is the worst feature in Business Central. It is designed to be used by a customer where there are no customizations being done by a Partner like us. I tell customers they shouldn’t use it but should instead go through us for these design changes, because anything they do to ‘save money’ will wind up creating such a mess for us that we’ll have to spend more time fixing it than it would have taken to just have us add/move the field in the first place. I believe there is a way to create some layout changes in universal profiles, and that’s probably worth consideration.”
Kyle quips: “Disable it prior to putting the first BC demo/test database in front of them, and they will never know the feature is there.”
Matt retorts: “Yeah, that’ll never come up in a Google search :).”
Elizabeth wraps it up: “Thank you so much for your input. I will be sure to strongly urge users who are aware of this feature to have us make changes for them or use this feature as sparingly as possible. If a customer does decide to make design changes to a page extension, would it be a good practice on our end to check the Extension Management to see if any new page extensions exist? And if so, what documentation would you like to see, like in the Publisher field, for instance?”
Interested in Dynamics NAV and/or Business Central development? Be sure to see our collection of NAV/BC Development Blogs.
Read “How To” blogs from ArcherPoint for practical advice on using Microsoft Dynamics NAV and Dynamics 365 Business Central.