In this episode, Jeremy talks through the challenging world of digging into what is needed and how to set expectations. he then stops by BC to look at Recurring and Standard functionality to have ‘templates’ for data. A quick run-through of setting up CRS in VSC for the devs.
- Pre-Intro Talk:
- Intro section: Needs & Expectations
- Consulting Section: Efficiency Gains in BC
- Dev Section: Efficiency Gains in VSC
Good morning and good day everyone. For those of you who are not in Europe or not Europe-centric, we had the exciting Eurovision last night. So, I am running a little bit behind myself today. But today we are going to be talking about means, needs, and expectations. And we will see how much we can cover in that. And in our visit to Business Central, we are going to be talking about efficiencies, some of the things that we can do to work with the system a little bit smarter and faster, using templates and defaults and standards and things like that, as well as looking at similar sort of concepts over in Visual Studio code. As such, today is about working smarter, not harder. And we will see how it goes.
Intro section: Needs & Expectations
You know, everything I have looked at in OBS has gotten rid of the swooshy effect slider, and yet it sticks around. I am haunted by my own early decision-making, which is a fantastic segue for today. So, one of the things that I have seen a lot of partners struggle with, and this affects every aspect of working with customers and just life in general, is making sure that you understand what people need from you, and what they are expecting you to deliver. The obvious industry way I can speak of that this comes to the forefront is in development requests where customization needs to be done. And very quickly, we go from the customer has a request, the consultative or project management team agrees and hands that off to a developer who asks what they are making, and they bring some solution to the customer or a long list of questions. And the customer is baffled as they think they have explained what they want.
One of the easy things that we do a lot in the industry, or at least I have seen a lot of partners do, is they become so busy that one of the first things that seem to disappear is keeping track of what is wanted. And if people do not write that down, it is a big problem. Additionally, a lot of people do not put the time and effort into asking better questions and thinking through what is expected. One of the areas that I appreciate about Luc Van Vugt pushing test-driven development is that pushes some of the requirements explored much earlier in the process. And that’s a good thing. Because it gets people asking questions of “what if?”, “What is your expectation?” and “When you do this, what do you think is going to happen?”
There are a lot of great quotes about expectations not being met, but in the heart of things, if someone expects something of you, and you do not meet that expectation, it is a disappointment. If that expectation is around functionality, then they were expecting it to work a certain way and they are going to be disappointed if it does not. If you are an engineer and you build too much, they were expecting a lower budget or price point on that, they might have been expecting it faster. Expectations setting is pretty core to human existence and just working with other people.
In my household, we are fairly spectrum people and different types of autistic mindsets are in play. And one of the things that we do to help manage expectations and keep the household in a harmony is we have whiteboards up in a central place for all of us on things that we are going to be doing soon, and things that we are going to be doing today. That includes using little white whiteboard magnets on those whiteboards that indicate a bunch of the common tasks that always need to be redone. Because like Sisyphus, we are always pushing, doing the dishes and various other things like that. So, it is very easy.
In a household where you are sharing work effort with people to think that you intend to vacuum tomorrow in your head, and maybe someone is looking at the floor going cheese, why isn’t this guy vacuuming? Well, by having the expectation set by setting that up on the wall saying that tomorrow or in the soon bucket or whatever, you are vacuuming, it means they do not need to ask you about that. I can see it moves over into today. And then it is done. And by repeating that over and over as a household, you develop the skill set to communicate effectively what the expectations are. And you do not have to have conversations about the chores you need to do around the house.
We have a teenager who helps out with chores, not because we had some big elaborate chat about how he needs to cooperate as part of the household, we do not have fights about it or anything like that. It is just a couple of the to-do chores around the house that we need him to participate in doing. They can move to his today bucket, that is, all and he then does them. And that is that. Very straightforward. It is just expectations and meeting those expectations over and over again builds trust.
Consulting section: Efficiency Gains in BC
That same principle applies to customers because it is just people’s stuff. Everyone lives this way. So, the more explicitly you can explore what people are expecting, record it, and meet it, the better off you are going to be. And since projects for our industry and Business Central are never just you, you need to be able to communicate those expectations effectively. But bringing that back around to requirements, just in the past 30 days, I have done a loose little requirements document of “you want this, it should work this way” when these things happen. We will do X, Y, and Z as an email sent to a customer. They said yes, that is correct. Two weeks later, when those deliverables went to the customer, they are asked basically “What is that all about?” That is backward from what I was expecting. And it was impressive to me because if they had only just scrolled down in their reply window, they would see that they had agreed exactly.
So, it happens, and people forget others are busy. Most of the time when we are working with customers in the Business Central space, the person on the other side of the desk has a million other responsibilities outside of Business Central, it is important to the world, and it is vital that it works for them. But like electricity, as long as it is on, they do not want to think about it, they do not need to consider the wiring in the walls doing what it is supposed to be doing. It is not their thing.
So, at the very minimum, just capturing what the client expects in an email is step one. And I am astonished at the number of people who do not do that. Some nice step two can be making a Word document instead of just an email, and we save it into a OneDrive somewhere where the client can even access it. What a concept.
So how do you think about the things to ask in expectation setting? Well, there is an entire profession around exploring what someone wants and what someone needs. It is called Requirements Engineering. I am astonished at the number of people in the BC space that I have talked to here and there about requirements that do not have people whose sole responsibility is the requirements engineering, that role typically follows on to consultative people or project management people or even salespeople to do this pretty elaborate and technical process of extracting from people what they are thinking, they want to do, and what they expect.
But there are great books, articles, and blogs about requirements engineering. As such, you can very quickly and easily deep dive into whatever level of learning about this that you are comfortable with. And it is worth every bit of time you will spend on it because you will save yourself hours and hours of frustration and unmet expectations just by reading one or two blogs about requirements engineering because it structures your thinking to go to what you expect.
One of the great authors out there that writes requirements engineering books, is Carl Uighur. When it comes to requirements, Carl has three levels to think of the different requirements. First, is the business requirements; these are generally high-level objectives. For example, we want to be able to ship more units on a monthly basis, and because one of the areas where we are stuck is that the picking process is not structured in a good way for our picking team to go through the warehouse and get things in the right order. They have to shuffle through papers and lose time, or any number of other things. Just what problem are we trying to solve? Define it and have that overview. And basically, just how we will be doing this project, make my world better? For starters, if you aren’t doing those high-level business requirements, how will this thing that we are about to undertake to make my world better, it is a lot harder to talk about the value that someone is getting. Something like a warehouse picking process being improved means that you can potentially ship more units every day. And for business, that logistics is key. That is potentially huge cost savings and a great massive ability to expand their operations. There is a lot easier ROI to talk about when someone is deciding whether this project is worth it. So that helps.
Second, you can go to the next level down, which is the user requirements. And this is where, in order to achieve that objective that has just been outlined, you ask the questions “What is the system going to let this person or this group of people do that they cannot do today?” and “What are the steps that they are going through and develop those into use cases?” I know some people listening to this have heard plenty of these terms thrown around. That is kind of what we are going for. For instance, build some sort of story – this is where user stories come from – describe the process, when our logistics manager comes in the morning, and he is creating pick documents, what should that process look like? What information do they need in? What actions should they be able to take? What should result from their actions? It is not a big thing, but we do not slow down and do it. We do not always see the value in it. And that is a little terrifying.
And you also have to start to practice your edge case or the “What-if thinking”. For example, what if my warehousing guy comes in the morning and preps all the picks for the morning? What if our biggest customer has a truck coming at lunchtime, and they call up at 9 am and want to add a few things to it? The warehousing team already did their prep work at 6 am. Is there a business process that reflects how that emergency shipment would be handled? And based on that business process, do we have to do anything in the system to support that business process?
You can explore those what-if questions, and then eventually, out of all those different use cases, you start getting your functional requirements. At the moment, I am prepping and teaching some people to do this exact exploration, you have to have your high-level goal, you have to develop your story about what people need to be able to do, and then turn that into the sequence of things that happen. And that is a fantastic sequence of events; it adds a huge value, removes huge uncertainty, and removes all sorts of risks from your project – the risk is not zero, but at least then you have the ability to ask if this is what the customer wants at each of these steps along the way.
I cannot describe how many projects went off the rails because, at those different stages, there was not anything to ask the people involved. Is this what you mean? So, spend the time to write all that down, it will save you, if you do not do that in the beginning, you will still spend that time. But you will spend that time going, this is not what I wanted. And now you have to fix it. And you have not created a positive trust-free reaction out of somebody, you have created doubt. You have created unmet expectations. It is a very negative experience. Now you have to react to what they wanted in a retroactive way, which is really hard to schedule and make sure that you have the right resources available for those things. So, just explore what expectations are, write them down, communicate them back to the customer for verification, and share those requirements internally. I do not think it is a complicated concept.
I am hoping that most people who are watching or listening to this are shocked that some people do not do that. But unfortunately, there are plenty of people who do not do that. I have run into a number of customers who needed projects to be recovered. Because the team involved did not do that. One of the things that I am keenly aware of is there are more and more partners every day working with Business Central that have not worked with an ERP system before. As terrifying as that might be for plenty of us.
However, if you are just rolling out office 365, which has requirements and expectations, too. But if you are having a smaller product stack, or one that does not involve as much fine-tuning and careful tailoring to be done upfront to be usable, it can be very easy to sign up with your credit card and get an ERP system. And they are not practiced at that expectation exploration, particularly around Business Central.
One of the things that I have done in the past, for example, in exploring customizations – and if you are a developer listening to this – is one of the structures that are really helpful for developers who just start thinking about asking these what-if questions. You can use the crud, create, read, update, and delete questions, which are great what-if questions; you know, where should users be able to create the data? Is it created automatically? Are there any imports we need? Are there any security or GDPR considerations to the data? For reading? Who should be able to access this? Who should be able to share that data with external organizations? When does reading this data? When is this info going to provide benefit to the organization? And does the data come out anywhere in exports or reports? Does it need to be copied anywhere? For updates? Who is responsible for updating the data? If the system should update it like calculation. Some things like that, when every time the user opens a screen, should there be any audit trail when someone updates a record, though? Do you need to know that that happened? What other places should be affected when someone makes a change? For deletion? Should it be possible to delete data? Should there be any audit trail to it? Should it be automatic?
So, there are so many great what-if questions to explore to change the nature of a project or at least scope things out a little bit. And that is one of the big advantages to this for everybody; it becomes much easier to say, that sounds like a great idea. But it is out of scope, out of scope is your friend. It does not mean “No”, it just means it is not what we agreed to.
One of the other things to do to level up on requirements, to move on beyond just exploring these basics, is to prioritize the different use cases when you have an agreement. The high/medium/low would be a fine start. So that way we might be able to get all of the high-level functional requirements done first. Thus, if there is any scheduled shortfall, any complexity, or any change requests that are potentially going to affect the schedule, we know that we have met all the high-priority objectives of this project first. And then when it comes to change requests, people are scared by change requests a lot of the time. I do not know why; it is just a way of writing down.
For example, here were our 10 requirements, you sorted them or agreed to them. This was the schedule, this was the budget, these are the priorities of all those different things. You have asked for a new thing. Do you want that to affect the budget? Or the schedule? Or the priorities of the existing 10 items? The answer can be yes, that is okay. But the answer can also be No, and that is to the client to decide most of the time it is not always, but most of the time. You can ask the client if they want to change your priorities, but at least then you are having constructive dialogues.
Another thing that comes up in those spaces all the time is projects are not simply working from beginning to end and that is that you are done. It is very rare that this is the case. As such, what I often encourage people to do during the business process of the use case modeling, or even in the change request process, is to always have a follow-up phase. It is similar to having undiscovered elements, building a new solution, or building new processes. There are always going to be things that you did not think of, no matter how fantastically your team is at requirement engineering, you are always going to have more stuff, you are always going to have more features, and your developers might have a great idea that sounds fantastic, or your consultative people might have a brilliant notion of what you could do with some power platform or Power BI stuff. Those are great ideas. But in this case, you have a process of a new idea that is not in scope.
However, if you always structure bigger projects with the mindset that you are going to have a post-project, or a follow-up phase, where at the end of the project you take into consideration the new cool ideas that surfaced during this process, you will be able to give yourself time to go through them and turn them into the follow-up project. You give a proper structure and space for any brilliant new ideas that do not fit well enough to change the existing plan and project. But it is not a no, it is a situation where you have a great idea. And you can do it at a later time, maybe next week. That is all, and I wish I could say that this stuff is obvious, but there are plenty of people who I have worked with who just get too busy. And these follow-up projects do not happen. It is just the way of it even if people know to do some of these things.
Sometimes you are just too busy to do things the right way. You just need it done. This comes up a lot for people who are working with converting or bringing over people to Business Central from other systems, or from no systems, which are the scary ones. As a long-time developer, “in the old system, we could…” is one of the phrases that just drives me crazy. If the old system was good enough, you would not be moving to a new system. I have a small little amusement on that one way back in, I want to say, division 4.0, maybe even five, I was hoping your customer moved from an old system that all it did was the financials, it just did invoices and payments and inventory, it was managed in Excel. And it was a mess; And it was well enough to develop the business, it got things done, and it just did not scale.
However, we had a particular salesperson in that organization who kept repeating that he needed the starting screen, of which, if you recall, there were a number of versions of division, where there was no starting screen, you opened it up, and it was just a menu off to the side. And that was it, it was just grey. The salesperson kept repeating that he needs the starting screen to work just like the old system, and he would not let that sentence go. The IT manager/project manager for the client had enough sass in his organization internally that this would not be taken too badly. We created a form in the old division environment, and all it had was a picture of the Start screen of the old system. And we set it for that particular user to open automatically. All it did was just open a picture of the starting screen of the old system for this guy. The funny thing is that he left it like that for a year because he thought that worked just fine for him. That was it. He just wanted to see the starting screen. We thought it was going to be a joke, that he would be annoyed with us and that it would be a hilarious prank. But it actually made him happy.
Sometimes things are strange, so do not be afraid to ask early on about the client’s goal, about the processing they expect to happen. And write everything down. Ask each step along the way if you got things right. You need to be able to share that information with your team, be able to explore when you say the old system could do this, and what is your expectation. And be able to confidently say “I think that is a great idea, but it is out of scope. So, do you want to change the schedule or the plan?” to ask what to do instead. It should not be scary. It should not be hard. And all of these things are part of billables.
So, if you are working in an organization and you find that you cannot do this or cannot spend the time on this. You will spend the time on this. It is just whether or not you spend the time upfront to make the customer happy, or if you will spend that time later to fix a customer that is upset. I think that is going to be the quote of the podcasts there.
Dev Section: Efficiency Gains in VSC
Let us talk a little bit about some system pieces here around Business Central. A lot of people tune in for the BC stuff. And let us talk today about what we can do to work more efficiently with the system. I do not want to start needing to keep dungeon master-style notes about what we talked about in our previous sessions, but it seems I am going to have to start doing that. Because I know oddly enough, we are only a half dozen episodes in, so mostly I knew.
So, we have talked a little bit about some of the template parts of the system. But there are a handful of different areas of the system where you can create standard transactions that you want to be able to access on a regular basis and be able to reuse quickly and easily. And I am often surprised by the number of people who do not know about them. Some of them are very obvious, while some are not. So, if we were to spend some time in the general journal, as a business manager type person, and we are creating different journals for entering information on a regular basis, first of all, most people are aware of the fact that General journals are just a bunch of journal lines. And you can post them. That is pretty standard stuff.
A lot of people are aware that there are what we call recurring journals. But I find it interesting that a fair number of people have not even seen the recurring journals in the system, I find that a little surprising sometimes. But I have flipped through some of the different role centers, and they are not really exposed in the UI. Consequently, what is a recurring journal compared to a regular journal?
There are recurring journals for a lot of the other different areas of the system, but I do not see many people using sales or purchase journals. As such, recurring general journals have the same general functionality as the general journal, except they have two extra little columns. They have got a recurring method and a recurring frequency. And these are cool stuff. I find it surprising the number of people who do not use them.
So, the first option here; is the recurring method. I am not going to go into all of the different details, but they are so much fun. They give people the most benefit right away in the list of options, we have fixed variable imbalance, then we have to reverse, fixed reversing, and variable reversing balance. We also have balanced by dimension and reversing balance by dimension. As you can imagine, there is a lot of power and logic hiding behind that long list of options. But the immediate get benefit right away that I can speak of is fixed and variable. Fixed recurring method, we will keep all of the different fields that you set up for this general journal batch and keep the amounts.
For example, if your organization pays a monthly rent, insurance on that property, and a variety of different things, you can set up all of those different expense recordings. If you are just going to enter them as a general journal transaction, you can set up all of those different recorded expenses in your expense account and balance it against your bank account, if you want. If you set them up as fixed, those amounts keep and when you hit the post, the lines are not deleted, like a regular old general journal, they stay put. The difference is the posting date updates based on the recurring frequency field. the variable works the exact same way except for the amount of changes.
Inasmuch, for example, if you have regular monthly expenses that are a little more variable in nature, if maybe the payroll varies based on hourly usage, or maybe you have utilities, like electricity and various things that fluctuate, you set them to the variable, set up all the different lines because after all, it is a general so you can put them against the GL account for your expenses of rent or utilities or whatever have you. And you can balance those against your bank account setting your recurring frequency, which can be things like one month.
Recurring frequency is a date formula. Thus, it takes a variety of different structures. There is a couple of good blog posts about date formulas, I advise you to look that up if you have not used them. It is the same logic that is used for payment terms, where basically it takes a given date, and then adds whatever you want. So, you could do CM for close a month, and then when you post it, it will be the end of the next month, I think in the recurring system it will be the next month.
But the general idea here is that this is a set of general journal lines, you are going to create repeatedly on a recurring frequency. And you know what that recurring frequency is, and you just want to be able to make sure the posting dates are right. And maybe you might want to make sure the amounts are right, hit the post, and move on with your day. It is a brilliant little system. I remain surprised at how many customers are not aware of it.
Many customers do not know that you have a separate option that is a little tiny bit more obvious in the general journals themselves. And this overlaps a little with recurring functionality. If you set up a whole batch of general journal transactions that are not necessarily things that you need to post every two weeks, or every month, for instance. But there is something that you are going to do on a regular basis. For example, your organization does conferences or events, or your people travel on a regular basis, and you want to record all of those different expenses in journal lines. Maybe there are 10 or 12 of those that you need to create with all the balancing entries, etc., but you do not know what you are going to need every month. Then, once you have set up all of those different lines with your GL accounts, your account numbers, descriptions, and balancing all those different pieces, there is a wonderful little option in the double check here. In the Action bar in the action’s functions, you can save it as a standard journal.
So, a standard journal is just a mechanism by which you can save all of these lines to a template. And then in the same sequence of things promoted, under the action bar process, there is an option to get standard journals. And you can select from your list of “standard general journals”. And when you select from that list, it generates all of those lines in your journal. So, it is a really nice, easy template system for things that you do not want to have to key in every single time, every little piece of that transaction. But it is not regular enough for a recurring transaction. That is really easy. Both of those things can save enormous amounts of time.
If, for example, you are doing financial consolidations or any variety of different transactions, they can get to be hundreds of lines. Some people record payroll expenses, it is going to be a monster of a thing, especially if you are doing dimensional reallocation based on departments. So that is one area of the system where you can have a huge benefit to making use of what is there; just to be able to use templates out the other area that I find people do not use as often as they should. And we will start on the purchasing side.
There is a whole system here called recurring purchase lines and recurring sales lines. This is the same concept in that you can create a template of lines. So, if I hit new, I will get a card, I get a code, I get a description, a currency code, and then I get a whole bunch of lines. And you look at this and you might not see the benefit here.
Let us say, for example, you are doing a mailing of some sort and you know that every time your organization sends out a catalog, you are going to send out a GL account, there is going to be an expense of maybe a 100 postage. And you can set up a GL account for your advertising account, we are not going to go through and fill out everything on this. But this allows you to pre-create a whole bunch of standard transactions that you might want to use on a purchase order. If we go to our purchase invoice, for example, and created a new purchase invoice, we pick whatever vendor makes sense for us. So, we will go with our publisher here. And let me see if I can make sure to find it here. Under the action bar, under more options, we have got actions functions, and we can get recurring purchase lines, recurring purchase lines, once again, it is not named template, but that is the idea.
However, if you do that, you will see that this recurring purchase lines a window that pops up is specific to the vendor that we are working with. So, it is empty on this particular list. As such, even though we just set up a mailing standard template, that is not configured for this vendor. So where do you do that? If we go to our vendor, we go to our publisher. And we look at the Action Bar in related purchases, there is a recurring purchase line and here, we are able to define what some of the standard purchases are for this vendor. The recurring purchase document type things that we have just defined, we can say we want this for this vendor.
And what is neat about this, too, is that on this screen for the vendor-specific recurring purchase lines, you also get the option to choose on, for example, invoices. If you want to insert the record lines manually, which is the default, or automatically, or ask, you can do that for quotes, orders, invoices, and memos, all of this is the same over on the customer side. You can do this for standard orders on the sales side for customers.
I utilize this functionality internally. For example, there are a variety of different organizations and services that we have monthly expenses for those particular vendors. And there is just one thing that we pay them for. For example, I am streaming right now to you via restream. That is one more small monthly fee. I like to have it as proper purchase invoices in my system. So, I set up a recurring purchase line for restream with which GL account to charge that too. And I have that for my restream vendor set up as a recurring purchase line. And it inserts automatically on any new invoice I create for this vendor. So, now if I go to an invoice and create the invoice for that vendor, I automatically get the GL account at 240 postages, and I have my quantity number. And now you will notice that it did not give us the option to define the amount. So that is something that you do not get to default. I am not sure why we are allowed to default the quantity and not the amount.
Oddly enough, I have not been asked by any customers to change that yet. But it seems like it would be an easy wish/want/ask etc… But then you potentially get multiple different lines that can be all sorts of different stuff that can be standard items that can be standard GL accounts, that can be all different things. This is fantastic for your salespeople if you have customers that frequently order the same stuff repeatedly, but they may vary in quantity a little bit. They do not have to rekey in those item numbers every single time ever. You can just go ahead and create a sales order.
If you create a sales order for a customer and this is going to be something that they are going to order like this on a regular basis. You can save this as recurring lines. I think there is an option to do that. Or if it is buried beyond my ability to find quickly on stream, you can create a standard order for customers, and then just set the different quantities, this is a massive time improvement for people who use the system. This is to make use of standard journals, make use of the recurring journals that make sense, make use of standard purchase lines and the standard sales lines, recurring sales lines recurring purchase lines, they are so so helpful.
A lot of people do not know they are there, and they are fantastic. It is common to have an invoice that you are punching in a month after month or scanning in and typing in all the info or whatever have you just just do this, this saves you a lot of time. It also takes care of some of the things I wanted to talk about and some of the efficiencies. There are always more ways to use a system better. So hopefully we will explore some of those in future episodes. That said, let us head over to our Visual Studio Code environment because the same is absolutely true.
For programmers who are working with the system, there are always faster ways to do things. And one of the biggest challenges for developers is finding the time to incorporate those into typology. One of the challenges is finding the time to incorporate those into your habits and your workflow. Especially if you are the sort of person who, like me, will absolutely make use of standard packs in the extensions in Visual Studio code. Waldo has a pack for extensions, I have got a pack for extensions; the spare brain pack that installs a million little helpers. And each and every one of these extensions in Visual Studio Code adds extra functionality. If we look at the Al toolbox from BART, for example, we can see in the feature contributions list, it adds a lot of things and adds a lot of commands. We can open relate tables, we can do some change renumbering objects, we have great functionality around regions, all that sort of stuff. And all of these things come with settings, lots and lots of settings.
One of my favorites, for example, in the PC space is Waldo’s extension. So, we can see here Waldos got a tremendous amount of settings. And I use this extension for every single project because of some of the things that it gives me. Why? If you have not seen it yet, there is a fantastic series. Pardon any of the people watching on the channel here, I am going to just look up the series. There is a fantastic series on the Areopa webinar channel that they did aerial videos with Visual Studio Code extensions last year. It is almost a year since those were done. This was a four-part series. I eventually did the fifth part. But this was a four-part series talking about what the extensions are, what the goals were, and how to make use of them in an efficient way. So, if you are wondering, for example, how to make use of some of these different extensions, you can find out by watching these 20-minute videos.
jump right to the AZ all Dev Tools section and see that 20 minutes of the author explaining what I can do with this extension. So, the advantages to that are some of the different efficiencies that you can gain. So, in our example, the extension that we have been building for just demonstrating some table basics, and some page basics, we have got a variety of objects cluttering up our root folder here. And they should, first of all, go off into a source folder. There are some naming best practices, do not ask me again.
So, I am just going to move all of my objects into the source folder. One of the best practices that you should be doing is that anytime you are creating new objects, they should have some affix, a prefix or a suffix. That should be at the beginning or end of the name that guarantees uniqueness. This is utilized heavily in app sources; you can actually register by asking Microsoft for a specific prefix or suffix that belongs to your organization to guarantee that your organization objects never have a name collision with anyone else’s objects. I find that many people who are developing per tenant extensions, for example, will either prefix their object names with PTE, to make sure it is per tenant extension, or potentially even just use the customer’s name.
Thus, if this was Cronus Corporation, they might do CC sample text or something like that. Just the reason for this is if Microsoft ever added an object named sample text to your system, and they roll out that update, and when you have got sample text installed, but you cannot rename tables in the cloud environment you are going to have a real rough time. So, it is common practice to always make sure to name your objects with a prefix or a suffix. And the same is also true for when you are doing extensions to tables.
For example, we are extending customers with some new fields. First of all, this object name is just a customer, which is allowed because this table extension type customer is not going to collide with a table type customer. But we absolutely should have it be called like PTE customer. And when you are creating new fields on existing tables, the same rules apply. If Microsoft ever added a field called some new field, we would be in trouble because you cannot rename fields. So, it is a very, very good idea when you’re doing table extensions to include your prefix and affix to those. Obviously typing those all the time is going to take a fair bit of effort. To that end, there are settings in the CRS AL extension that Waldo made, that help you manage this process. And it also helps you follow the standard naming practice.
You will notice that in my source folder, this table extension for customers is named customer dot table xt.al. That is a standard naming convention utilized by a variety of different rules. And it is considered a best practice in the AL world to have object name.type.al. So, how do we adhere to some of these good practices? One of the things I like to do with CRS, if we hit f1, to open up the action Browser here, we can hit this little option for CRS called configure best, best practice file naming. I do this every time for every project. And I put this if I am working with multiple extensions, that is another topic, but we are working with just a single extension.
So, we are going to save the settings. Where would you like to configure the best practice naming given configuration? We are going to save that into this workspace. That creates a setting. JSON folder file. Here we have file name pattern extension, pattern page customizations, and all that fun stuff. In the CRS settings here, which I like to work with just in the JSON, we can see that there is an option here on Save AL file action. Default is to do nothing. But we can also say Rename. I love this option, there is a reorg. But there are some pros and cons to that.
If we come into CRS, and we give an object prefix to this, of PT E, including space, and we save this now, we have now configured this Visual Studio Code extension to have a naming pattern, and we want to rename the files and we want to add PT. So this is pretty cool. If we come to our customer table extension, and just resave this, the extension is going to do two things automatically for us. It will add the PT II to the object name. And it also detected that we have custom fields that we are adding to a standard table. So, it adds PTE to all the field names. It also renamed the file to match that.
That is probably going to need to be where we are going to wrap things up for today. I am looking at the time, we have already gotten our babbled fair bit about requirements and setting things. So, I will spend a little bit more time over in Visual Studio Code next episode. I strongly encourage people to go watch those Areopa videos, the webinars from last year, each of the extension authors explains a lot about how to get the best out of each other extensions, and what you gain for efficiencies in them. I strongly encourage that.
That pretty much wraps things up for today. I hope this provided some good food for thought around exploring what’s scope, how do you manage that how those different expectations work. And I am looking greatly forward to doing the rare thing. I actually know what I want to talk about next week as well. So, I hope people are sticking around. This is available on YouTube; you can subscribe and get notified when there are new versions of this out. It is also an audio podcast if people want to just listen to the first half and just hear the jibber jabber section of things. You will find it on all sorts of podcasting platforms, including Spotify, in anything in the Apple Apple ecosystem. So with that, I hope you guys all have gotten some good ideas, and food for thought. And we will see you next week. Take care everybody
[MK1]Not sure how the name is written but this is what I found through research
[MK2]Also check the name, please.