This blog may seem very narrow-focused, but here we will use tricks that could be widely used.
Assume you want to add a new option to the Sales or Purchase Line Type. This approach will work the same for both, so let’s say Purchase Line Type.
You are building the Fishing app. You created a new table – Fish, and want to add some logic when you catch a fish. To do so, you decide to add a new option to the Purchase Line Type.
The standard list of purchase line types consist of
I guess at this point you ask yourself, what could be complicated here? Just create an Enum extension and that’s it. Well, let’s give a try.
Publishing the app, going into the purchase order and…
… nothing. Hm. Well, if this was so easy I will not decide to write this blog, right?
Let’s have a closer look at how Type drill-down is organised. The code is hidden in the “Purchase Order Subform” page.
If your Application mode is Advanced – you can close this blog at this point.
Just because in the Advanced Application mode – the drill-down type screen will have your Fish option, coming from the enum Extention automatically.
But, if Application mode is Basic or Suite, then what you see is not a standard options-choice screen, it’s a separate page.
Show your option
As it’s a page with a separate “Option Lookup Buffer” table, to show your option we need to add a new record.
But before let’s investigate how and when this buffer table is filling with the standard values. The answer – when you open purchase document
and it’s our chance – event “OnBeforeIncludeOption”
Actually, if you look closer, you will see that this function IncludeOption – does not add an option to the table as a record, but only tells the system if this option should be added.
Let’s subscribe and tell the system that – yes, we want our new option to be added to the table.
The trick here is that at the input we get the current OptionIndex, starting from 0. And we need to check if the current option is our Fish.
So, our Fish option will have an OptionIndex = 6 (0-5 standard values, and 1 extension value).
To check if the current OptionIndex is our fish we need to calculate the Index of our Fish value.
PurchLine.Type.Ordinals- will give a list of option values. The list in AL starts from 1, not from 0.
PurchLine.Type.Ordinals.IndexOf – will give us the index of the option in a list.
PurchLine.Type.Ordinals.IndexOf(PurchLine.Type::”AIR Fish”.AsInteger()) – will give us the index of the option in a list, where option value is Fish. AsInteger will give us the id of the option.
There is a good blog describing these definitions https://www.kauffmann.nl/2020/07/16/converting-enum-values-in-al/. Also at the end of current blog, there will be a link to my youtube video, describing these things.
PurchLine.Type.Ordinals.IndexOf(PurchLine.Type::”AIR Fish”.AsInteger()) – 1 : will convert the index from the list to the OptionIndex.
Let’s publish and have a look at the result
Great, now our new value is in the list. But why it’s without a name, just an index?
The reason is that FieldRef tries to get value from the Index. And Index, in this case, should match Enum Id.
In our case, the OptionIndex is 6, but the custom Enum Value has the Id of 50100 (the id we assigned in enumextension).
And when in the next function CreateNew, the logic executes FormatOption – it just cannot find a name for the 6 enum value, because it just does not exist.
Well, I thought that it’s the end, but I got an idea.
Have a look, that’s the standard code
and here is mine
When standard insert an option value to the drill-down table, I discover MY option value there by the index and replace it with the real Id and Name.
From now you can extend other logic, based on the new Purchase Line Type
The code is available here https://github.com/dkatson/Blog-How-to-extend-Purchase-Sales-Line-Type-in-Business-Central