Idea and Feature introduction
All of you are familiar with the Ideas portal, and in the Supply Chain Management team we do everything we can to include the features requested there into our plans.
One feature in particular has been sitting there in the Warehouse management top 5 for quite a while
The problem described in the idea is that purchase order receiving flows currently require that you scan in the purchase order number and often you do not have that available for scanning. So the only option then is to print out the arrivals expected today, as well as the product receipt lists for all of them, and scan from paper during receiving. But now that I'm on the Microsoft Cloud for Sustainability team, we cannot really have you using so much paper just for this, can we? :)
One of the reasons why we have not implemented this in the product yet is, as many of you are well aware, extending the mobile device flows in X++ is quite complicated and cumbersome.
Now, the last feature that I created before departing for the Sustainability team was the Detours feature. If you've been living under a rock, you can read about it here: [Tutorial] Warehouse management app detours
Working on the detours and having in mind the above item from the Ideas portal inspired me to create the feature that I would like to describe in this post.
Demo of purchase receiving flow enhancements
I have configured three different detours for the PONum step for the Purchase receive menu item. This step in the purchase receiving flow is the one, where the worker needs to scan in the purchase order number, but now, we can now look it up instead.
 |
| Detours to look up POs |
We can look it up by vendor, or see all POs that are arriving today, or we can look up the POs based on the items in them, which can be useful if we can scan the item directly from the package that we just received, for example. Let's explore them one by one.
Lookup POs by vendor
The way I have configured this flow is that I will be asked to enter the vendor name and not the vendor account as the first step, because I wanted to show that wildcards are enabled for the filters. Image that I am expecting a couple packages today from a vendor called Tailspin something, I don't remember the full name, but I can type Tail* to keep it short, and will see all purchase orders based on my filters where the vendor name starts with Tail.
 |
| Lookup POs by vendor name (with wildcard) |
Each card has a number of fields that convey necessary information about the purchase orders. I can see the vendor name is Tailspin Parts. That's the one I couldn't remember fully.
 |
| Results of Lookup by Vendor |
When I select one of cards, it will immediately go back to the main flow and populate the purchase order number for me based on the selection.
 |
| Selected PO is populated back in main flow |
Lookup POs from today
The way I configured the Lookup POs from Today menu item does not require me to enter anything when invoked; just showing some of the pre-configured filters, and I can just proceed.
 |
| No entry needed in Lookup POs from Today |
I can see two purchase orders are arriving today, one from Fabricam Electronics, one from Tailspin Parts with additional information about each of the orders that are expected. The list of fields displayed is different from the previous detour. I can select one of the orders, and it will be populated back into my main flow.
 |
| Resulting view of POs from today |
Lookup POs by item
This one allows to look up POs by order line item. I kept the setup simple here, just asking the user to scan in the item number. You can play around to figure out a way to use GS1 barcodes here too, I guess.
 |
| Filter screen for Lookup POs by item |
When that's done, it will show the purchase orders that have an order line with such an item on it, that are expected for arrival after Jan 1st 2020.
 |
| Results of Lookup POs by Item |
I can see that I have one unit of item A0001 arriving in order 105 and 30 units of that item arriving on order 125. I would then select the corresponding purchase order based on the quantity of the items I see in front of me on the pallet.
Lookup items
Now that I have selected a purchase order, I am shown the next step to scan the item number.
And again, the item number might not be available for scanning, which means I have a look up function for all the items on this purchase order configured as a detour.
 |
| Lookup PO items detour |
When I select this detour, you can see that the purchase order number is pre populated from my main flow on the filter screen.
 |
| Filter screen with pasted in PO number value |
Upon confirmation, I can see the two lines that I have on this purchase order for the different items with some additional information about each line.
 |
| Lookup PO line items results |
I can select one of them, which will bring back the item number into the main flow, and upon confirmation, I can proceed with further receiving steps.
By now, I guess, you're catching on to the pattern of these lookup flows - you have 2 steps: in the first step you enter filters, and in the second step you see the data retrieved based on those filters.
And the wonderful thing is - this is not limited to purchase receiving flow at all - you can configure pretty much whatever flow you like this way, without writing a single line of code.
I don't know about you, but I think this is pretty awesome! :)
Configuring the mobile device menu items
OK, let's now look at how these menu items are configured, one by one, in same order.
Lookup POs by vendor
 |
| Lookup POs by vendor configuration |
You can see it is a new mobile device menu item type, of Mode Indirect, where the Activity code is Data inquiry.
The only property that I need to specify on such a menu item is the Table name. This will be the base table for the query used to retrieve the data. You can use the lookup for it and search by both the table name and human readable label.
Once a table name is selected, the two buttons on the top right light up, Edit query and Field list. This should be familiar for anyone who has at least once configured a Work list menu item.
Query configuration
Edit query will allow you to define a query based on that base table selected, in our case it's the Purchase orders.
 |
| Query configuration for Lookup POs by vendor |
As you can see, I have configured that this particular menu item will be querying out open purchase orders that are expected to arrive anywhere after the 1st of January 2020.
I have also explicitly added a filter based on Vendor name and left its value blank.
I could also configure sorting for the query, for example ordering the data based on the delivery date in a descending order, similar to any other query editing window.
Field list configuration
Apart from the query, I also need to configure the fields that will be displayed on the cards in the inquiry list screen;
 |
| Field list configuration for Lookup POs by vendor |
This looks pretty much the same way it does for the Work list with the only difference being that no field is preconfigured like on the Work list, all of them are just free fields where I can select from the list of fields on that base table. Display field 1 is the one that will be used as the header for each card.
One additional thing that I have added and used a little bit different approach compared to the Work list is that I show the display methods in the same list together with the table fields, where you can tell that they are display methods based on the fact that they have the method syntax with the brackets at the end.
 |
| Lookup for table fields and display methods |
The label that is shown for display methods is the label of the Extended data type returned by these display methods.
Lookup POs from Today
Query configuration
If we look at purchase orders from today, I have configured in a similar way to return only open purchase orders that are expected to arrive today. I'm using the SysQueryRangeUtil syntax here. If you're not familiar with this, you can read more on the official docs site.
 |
| Query configuration for Lookup POs from Today |
You can also notice that I do not have any other unpopulated filters, and if you remember back to the demo, I did not actually need to enter anything on step one on the filter screen, right? I could just proceed to the actual inquiry list step.
Field list configuration
 |
| Field list configuration for Lookup POs from Today |
I have configured a number of PO fields to be displayed, and you can see that the first field is the purchase name, and the second field is the purchase ID. Purchase name will be used as the card header, but I can return any of these fields as information back from the detour. In this case I'm returning the purchase ID back to the main flow.
Lookup POs by item
By now you should be familiar with the process. The difference in Lookup POs by item obviously is that the table is Purchase lines.
Query configuration
 |
| Query configuration for Lookup POs by Item |
I'm looking at the lines from the purchase order, and I have configured an exists join to Purchase orders, because I wanted to still make sure that I'm only looking at open purchase orders that are expected after Jan 1st 2020, similar to the first flow.
I kept the filter on the Item number empty, so it shows up for the worker to enter on the device.
Field list configuration
The field list is pretty much the same as before, just a different set of fields.
This is where some customization might be required if you're lacking some of the information to display.
For example, if you want to show some special info about the purchase order or maybe even the vendor, you could add extensions with display methods to the corresponding table.
Lookup PO items
This flow also uses the Purchase order lines as its base table, as it's used to look up the purchase order lines for a particular purchase order.
In terms of filters I went super simple and just added the PO number as a non-populated filter - the detour will populate this automatically when the detour is invoked.
I could of course make it more complicated and select certain lines only, for example only those that have WHS items on them.
And the field list is pretty much same thing as before.
Lookup inventory
 |
| Lookup inventory flow |
I've also configured an additional flow which is just a look up inventory flow. The base table is Items (InventTable) and the filter is just the Item number and then the field list is a couple of fields from the item.
So it is that easy to configure just a random inquiry screen, if you want the workers to be able to look up some information from the mobile device.
Note
In order for the worker to see the detour, they need to have access to it, which, similar to Work list, requires that he has the detour menu item somewhere in his assigned mobile device menu.
OK, so this is the mobile device menu items, and the only other thing that you need to configure after this is the mobile device menu items steps, to configure the actual detours.
Configuring the detours in mobile app steps
Purchase receive - PONum
I have configured an override for the PONum step for the Purchase receive menu item, which is the step where we enter the purchase order number as part of receiving. I have added the 3 detours that you saw above.
 |
| Mobile device steps - PONum override for Purchase Receive menu item |
And if I open the configuration for the fields to send to and from the detour (Select fields to send button), we can see the typical list of fields that are available in the purchase receiving flow, while for the detour it varies.
Paste In fields for the data inquiry will display all filters from the corresponding query that are not populated.
Copy From fields for the data inquiry will display all fields from the corresponding Field list configuration.
Note
In v1 this does not include display methods. This might be something that we extend in the future.
You can see in the screenshot that for all three flows I have not configured to send anything to the detour, but I have configured to send the purchase order number back.
Purchase receive - ItemId
 |
| Mobile device steps - ItemId override for Purchase receive menu item |
If we look at the other detour that I have configured, which is the Purchase receive for the step Item ID, where I need to scan in the item, you can see that I have one detour, for looking up items, and I configured to send the purchase order number from the receiving flow into the detour, and then to send the Item number back from the detour.
One more thing - Detours that start from data inquiry list
One last thing that I wanted to show is that we now expose the generic data inquiry list step ID so you can configure this for creating detours from that inquiry screen.
 |
| Mobile device steps - GenericDataInquiryList override for Lookup POs by vendor menu item |
You can see above, how I have configured an override for the Lookup POs by vendor inquiry flow.
The detour will invoke the purchase receiving flow and will pass in the selected purchase order number to the detour flow.
Note
You need to remember to regenerate the default setup for the mobile device steps, as well as the mobile app fields, for all of this to show up and work properly.
Demo
Let's see how this looks in the warehouse app.
If I start the Lookup POs by vendors inquiry flow directly from the menu, enter Tailspin Parts vendor name, I'll navigate to the screen showing 3 purchase orders - you can see the same above.
In the list, if I select and long press to invoke available detours, I will get a detour to do purchase receiving for the selected purchase order.
 |
| Available detours for Data Inquiry list |
This is an alternative way of running the receiving flow - instead of doing a look up, you could start from an inquiry flow, and invoke a detour to do the desired flow.
Note
Because this is a detour flow I do not have the ability to invoke more detours from here. So when I get to the item number entry screen I will not have the look up for the items available, as we only support one level of detours today.
The data model does support multi level, but that's not on our priority list right now, as far as I know.
If that is something that you feel is super necessary, create an idea on the ideas portal and team will prioritize that accordingly.
Same for auto-confirmation of the filter step - it would take a bit longer to show the next screen from a user's standpoint, but would look much more smooth. Again, do log it on Ideas portal, if this is important for your workers.
Which version is this available in?
That's a good question. :) I don't know yet.
If all goes well, 10.0.27.
I'll update here, as we make progress on productizing the changes.
Important
You will need to enable feature WHSMobileAppDetourGenericDataInquiryFeature when you do get the right version.
