I retyped the title of this post about a hundred times and I'm still not completely happy with it. But I hope you will understand what the idea is with the case below.
The customer wanted a List with "Purchase Requests". Those requests have exactly the same functionality as "Purchase Orders" but the pages should be more clean; since this will be used by anyone in the company and not just the Purchase Agents. The List page should only contain the Purchase Requests and not the Normal Purchase Orders and vica versa.
For this we are obviously using AL and not C/Side.
I also want the solution to have as little impact on Standard BC as possible and want to make sure that nothing breaks during upgrades. So copying the standard pages is a big no for me. (That's how we did it back in NAV2009 when we were all a bunch of coding cowboys).
Let's start by creating a new field in the Purchase Header table to differentiate between the Purchase Requests and the other orders.
You can add this field to the purchase list so you can easily test the dev.
Next we create a Page Extension of the Purchase Order List so we have a function that we can call to enable the Purchase Request view.
Next we add an OnOpenPage trigger to the same Page Extension.
We use filtergroup 2 for 2 reasons:
1) We don't want the user to remove the filter from the list and have access to the normal purchase orders.
2) More importantly it just doesn't work without filtergroup 2! (You will see why later).
Next we extend the Purchase Order Page with another OnOpenPage trigger:
This is the part where we really need that FilterGroup 2 part. You can try the solution without it and you will see it won't work! Apparently when you enter the OnOpenPage trigger the system does not know the filters from FilterGroup 0 yet but it does know the filters from FilterGroup 2...
Let's finish this page extension by adding to the NewRecord Trigger.
You need this part because the Page Property "PopulateAllFields" is not set to true for Purchase Orders.
Almost there! We have our list and we can open and create Purchase Requests. You can now add a button somewhere to open our new list and the customer is happy.
Wrong! The customer is not happy! He does not want to press a button somewhere; he wants the purchase Requests to be available from the search and from the Navigation Pane.
Even if you are an experienced developer in BC you might not know this trick.
First we will extend the PurchaseCue table with a flowfield that counts the number of Purchase Requests. You can extend another Cue table obviously or create your own Cue for this.
We add our new flowfield to the Purchase Agent Activities which results in it being a tile in our RoleCenter and it being searchable in our search bar.
But as you can see for some reason the system did not add it to our Navigation pane.
Well for this you need just one silly property:
It seems redundant because we have written code in the OnDrillDown trigger; but with this the system knows he needs to add it to the Purchase Order group. #TheMoreYouKnow
That was the hard part. Now that you have your boolean you can modify or add stuff depending on it.
The repo can be found here: https://github.com/BartPermentier/PurchaseRequests