Tools and tutorials for Microsoft Sustainability Manager, Microsoft Cloud for Sustainability, Microsoft Emission Impact Dashboard, as well as Microsoft Dynamics AX aka Microsoft Dynamics Supply Chain Management (F&O)
Sustainability is not a new topic, but for a lot of companies this has been overlooked or not prioritized in previous years. With all the impact from climate change in recent years however, it is coming more and more into focus, with shareholders demanding to see companies making tangible progress on reducing their overall impact on the environment through reduction of their carbon emissions, better management of their water consumption and generated waste.
With Microsoft Cloud for Sustainability, and Microsoft Sustainability Manager (MSM) in particular, Microsoft has been leading the charge to help companies embrace their ESG journey and enable them to reduce the entry barriers and costs associated with this monumental shift in how they conduct their business sustainably.
Microsoft Sustainability Manager has now been generally available for 1 year, with a vibrant partner community quickly upskilling their staff on selling and supporting MSM, we still get feedback from both partners and customers, that they need more learning material to become available on sustainability in general and Microsoft's vision and approach to it with MSM in particular.
Let's talk Sustainability
That's why we have recently launched a new type of content on Microsoft Learn, called Let's talk Sustainability, where people from the Microsoft Cloud for Sustainability Product Group share their knowledge on the product, answer common questions and have a dialog around how to approach some of the more complex parts of collecting and preparing your data for regulatory reporting.
We're starting off with 3 videos, covering the basics of:
Are there any specific topics about Sustainability, Emissions Impact Dashboard, Microsoft Sustainability Manager, Microsoft Sustainability APIs, project ESG Lake, or anything else, that you would like to learn more about?
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.
Warehouse management app detours is a feature we have shipped recently, available as part of 10.0.23, which enables a warehouse worker to park a task they are currently executing, perform another mobile device operation, and then come back to exactly where they left off, once the detour is complete.
This is feedback we have heard way too often from workers in the warehouse, saying they are afraid to navigate away from their current step for risk of losing their progress, the lock on the work they were performing, etc.
The detours help reduce that fear, and, what is great about the feature, is that pretty much any mobile device menu item can serve as a detour in another mobile app flow.
Enable feature
Feature management
In order to enable the detours feature, you first need to enable the "Warehouse app step instructions" feature, both shown in the image above. This is what really drives the configuration options for detours, so that you can be flexible in where the various detours show up in a mobile flow.
In addition to enabling the feature, you should also make sure to regenerate the default setup / update the Warehouse app field names configuration, as we've significantly expanded the metadata associated with the fields (aka steps in a flow).
Configuring mobile device steps
You configure detours through the Mobile device steps screen.
Mobile device steps
First, you need to identify the step in the flow where you would like to show a new detour menu item, and then add configuration for this step for a selected mobile device menu item.
In my examples today, I have decided to show detours on the "Scan a license plate" step as part of the Sales picking flow, as well as in the Item Inquiry screen from each of the cards.
Adding specific step configuration allows to configure an alternative set of instructions for the user, in case they should be different from the default for the selected menu item, as well as choose (if you enable the corresponding feature) the information that should be prominently shown to the user in the details section, so they don't need to click into the details to view it. And, which is what we are going to do now, it allows to add one or more detours to this step.
Detour configuration for Scan a License Plate step of Sales picking flow
Detour configuration for Item inquiry list screen
Above is how I have configured detours for Sales picking and Item inquiry flows.
Note
It's not just about invoking another flow. You can actually also pass information back and forth between the main flow and the detour. In the examples above, I'm passing in the Location from the main flow into the detours, and in the Location inquiry detour, I'm also passing back the license plate. Which allows me to select the license plate from a list instead of entering it manually, if I for some reason is not able to scan the value in at the location.
The options with detours are almost limitless, especially when you take custom flows into consideration. Some of the examples could be allowing to do an ad hoc movement of inventory from the receiving flow, or even from a picking flow, so that the worker can clean up the aisle to get past some block. You could do ad hoc replenishments, or perform counting on the spot, if you notice something is off while picking goods. I'd love to hear what you come up with in your warehouse!
Sales picking with location inquiry detour demo
To demonstrate how detours behave on the mobile device, I've created a simple sales order picking work order with 1 line, picking 10 pcs of A0001 from FL-001 location, which is license plate controlled.
After scanning in the work ID created above, we arrive at the step, where the worker needs to specify the license plate to pick from in location FL-001.
Detour menu items visible for Scan a license plate step
You can clearly see which menu items are detours because of the additional icon (return arrow) shown above the main icon. This signals to the worker that when they are done with the detour, they will be returned to their current step in the current flow.
If we select Location inquiry, we are directed to the first step in the location inquiry flow, and you can see that Location is already pre-populated for us with the value coming from the sales picking flow. I can of course go and change the value to another location if needed.
First step in Location inquiry detour
After I confirm the location, I am presented with the list of license plates and products in the selected location.
Location inquiry detour - list
Now, because I am in a detour, I can actually select one of the cards displayed, and when clicking back, the selected context is carried back to the main flow, including not only the card header (in this case, Item number), but all/most of the other related information. In this case, I'm interested in the license plate, which is how I have configured the detour above.
Note, also, that when selecting to go back, the first step (for scanning the location) is "skipped", and we go out all the way back to the main flow.
License plate populated from detour
As you can see, the license plate was transferred back and I can simply go ahead and confirm the entry to proceed. Nice!
Item inquiry flow with spot counting detour demo
Now, I'd like to go into an item inquiry flow and view the on hand available for A0001. You can see I have four locations where this product is available. And let's say I actually want to re-count this location, as upon visual inspection something seems off (or maybe I noticed something fell and broke, for example). That is now possible with detours.
All I need to do is long-press the card for the specific location I would like to count, and a list of available actions will pop up.
Detours available for BULK-001 card
Selecting one of the detours will pass the current card context into the detour, thus when the spot counting opens, for example, the location to count will already be pre-populated, as shown below:
Spot Counting detour with pre-populated value and step instructions
Note that the step instructions are also displayed, as this is the first time I open this particular flow. I can dismiss the instructions until next time, or for good by selecting the "Don't show again" check box.
In summary, not only do you have detours available in your typical page by page flows, but also on inquiry screens like location or item inquiry, providing even more flexibility.
And, I guess, it makes sense to explicitly call out that both ProcessGuide-based flows as well as WHSWorkExecuteDisplay-based flows are supported.
Want your feedback
Currently, when a detour is opened, we do not automatically confirm the value, even if it's populated based on the main flow. One of the reasons we discussed was that workers might get confused, expecting a particular and familiar step, but instead getting something else. Another is that it would be slower, as we'd still be going step by step on the backend, so the worker might perceive a longer wait time for the detour screen.
I'd like to ask for feedback on this!
What detours do you find relevant for your business?
Do workers find it convenient?
Is an auto-submit feature necessary?
Leave comments here, in the below Youtube video, or reach out directly!
As you might have read on Yammer or other social media, I have decided to take a step away from Finance and Operations and Warehouse management, and a few months back accepted to lead the Sustainability engineering team in Atlanta, Georgia. The team is working on 2 new exciting and relevant products, Microsoft Cloud for Sustainability, as well as the Microsoft Emissions Impact Dashboard. The latter is now generally available, while the former has just recently been released as a trial (public preview)
As we work towards GA of Microsoft Cloud for Sustainability early next year, we are looking for more engineers to join our team.
Positions at different levels of experience (mid-level to senior) are available, and you can apply through the following link:
So if you meet the requirements and like what you read in the press releases about the Cloud for Sustainability product vision, and want to support Microsoft's path to a carbon negative future, please apply for the job, and/or reach out here or on LinkedIn.
In a recent post, I talked about testing, using the ATL framework to write easy-to-read test automation.
This is a developer activity recommended for ISVs and partners, to ensure their customizations against regressions.
At a customer site, if a developer team is unavailable, or for testing E2E scenarios in the system, Microsoft recommends using the RSAT tool. You can see a quick summary of those recommendations in the below picture:
Test classification pyramid
RSAT is well suited for recording and replaying tests that use the web client of Dynamics 365 SCM.
As such, it was not providing much support when it came to validating scenarios, that required the use of the Warehouse management mobile app.
To fill that gap we had shipped the RSAT for WMA a while back, officially called "Warehouse App Task Validation Framework". If you are not familiar with its capabilities and use cases, please watch the corresponding Tech Talk to familiarize yourselves.
Problem statement
This framework with the initial release was only supporting Tier 1 environments (like, DevBoxes).
This was not ideal, as many customers wanted to run their RSAT validation on Sandbox ("perform") environments to replicate real production performance and behavior more closely.
Also, with more and more customers being moved to Self-Service environments, they lose easy access to free Tier 1 environments.
Announcement
Starting with Dynamics 365 SCM version 10.0.19 the Warehouse App Task Validator is now supported on Tier 2 environments!
Configuration
All you need to do to start capturing of the warehouse mobile device operations as part of RSAT is to enable this under Warehouse management parameters, as shown below:
Enable RSAT support for WMA on Tier 2 environments
You can now navigate to the Warehouse app task validation page (under Warehouse management \ Periodic Tasks) and start creating validation scripts.
Word of caution
As stated in the help text for the configuration flag, do NOT enable this on a PROD environment, as it carries a significant overhead for each operation.
Request for ideas
The current user experience with RSAT for WMA is OK, but not great. A lot of people are timid when presented with the large XMLs.
If you have ideas on how to improve the user experience in RSAT for WMA, let us know!
