When I design the functionality some of the rules I have is that we are guests in the Business Central framework and users should not recognize that now use my solution, not the standard one. What does it mean? If there are any UI/UX patterns or naming conventions I believe we should follow them.
I cannot count the number of conversations that I had that starts from similar words:
It should be named different…
That does not make sense from the user perspective…
I know that it works in standard this way but It should work differently…
The No. field should have 30 chars instead of 20…
I always have one answer:
I fully agree with you. It is should be different. However, this is how it works in Business Central. Ask Microsoft to change it. And if Microsoft would change the behaviour, then I am the first person to change it in the solution.
How to handle the No. field?
Today I checked at least 10 apps on AppSource looking just for one field on the screenshots – the No. field is shown on custom Document or Card Pages. And you know what? Most of them do not follow the standard Business Central pattern.
I noticed two things:
- The field No. missing OnAssistEdit trigger
- No. field is shown even if probably should be hidden
I decided to write why to follow the standard pattern and also how to do it in just a few quick steps.
No. field – show or not to show…
… this is not a question. If you would check Business Central you can see that sometimes the No. field is shown on the documents sometimes not.
What is the rule? It all depends on Number Series used in the setup. If there is a relation between the number series or the number series allows manual numbers, then the field has to be shown. Otherwise, the field on the cards and documents is hidden.
OnAssistEdit – there is a reason why we need it
If the No. field is shown how it should work? It has to have a trigger onAssistEdit. Why? A few reasons are depending on the scenario.
If there are relations between series:
- User should be able to choose the number of series which should be used and we as developers do not need to know if someone set or not the relation between the series
If there is no relation between series but the number series allows manual numbers:
- As a user, you always can check what numbers should be used and what was the last one,
- Imagine the situation: a user put a number manually but later wants to change the number and use the standard No. Series then without Assist Edit it is not possible,
- As a consultant or user you expect that you will see the Assist Edit button – it works for all the cards and documents the same and is also officially described in Microsoft Docs how it works. So not having it is made me think “There is something odd with that page”
The official documentation for the Number Series you can find here: https://docs.microsoft.com/en-us/dynamics365/business-central/ui-create-number-series
How to hide the No. field?
Now let’s see how we can hide the No. field from a technical perspective. In the Business Central standard, the code is added to the OnOpenPage trigger. Here you can check the example from the Item Card page.
The function name is standardized and I would advise using the same name. In the function, you can see that the global variable NoFieldVisible (also you will find this name across the whole system) is set. An example from Item Card looks like below.
Unfortunately, if you would need to use this one on your page, you have to create a new codeunit and copy a few functions from the DocumentNoVisibility codeunit.
The example of the code you can find on my GitHub page here:
The last step is setting that the No. field is visible if the NoFieldVisible variable is true.
How to add Assist Edit?
I would say follow the design pattern – as simple as that. So in short copy to your table the AssistEdit function from any master data table (for example Customer table). Note that you may need to do a small code refactoring to get rid of the “with” statement. And then on Card Page add the trigger OnAssistEdit.
I hope now we will see more solutions on AppSource following the standard design of the No. field.