Thursday, January 19, 2017

Warehouse Mobile Devices Portal - Now as an App for your mobile device

Our team has been working on an application that would eventually replace the existing web-site based Warehouse Mobile Devices Portal (WMDP), as we see the trend of warehouses relying more and more on phone-based devices with added scanner capabilities (Honeywell Dolphin 75e, for example).

We are happy to announce that the app is now publicly available.
Installation and configuration instructions,  as well as download links, can be found on the Dynamics 365 for Operations wiki website:

The app works on Windows 10 devices, as well as Android devices. iOS is not supported, since such devices are generally not used in warehouses due to high cost and some technical limitations.

The app only works with Dynamics 365 for Operations, so older releases like AX 2012 R3 can only use the old WMDP web site.

The app is an alternative front-end to all the business logic and screen generation logic in X++, so does not contain any business logic inside, similar to the old WMDP.

As you will see, we have re-worked the user interface, focusing on showing as few controls as possible at once, adding cards for showing grouped data like on-hand info, work list, etc. A special keyboard to entering quantities, support for scanning, etc.

Here is how the app looks on a Windows Phone:

Log in screen for new WMDP app

We are very excited to get this out into your hands and are looking for feedback. So don't be shy :)

Update 2017-01-20: Read a much more detailed description from Markus on the SCM blog:

Wednesday, December 28, 2016

Configuration tip: Warehouse mobile devices portal Native application in Azure Active Directory

Setting up the Warehouse mobile devices portal is a relatively simple process, and is described in detail on the corresponding wiki:

However, now and again I would get complaints around the authorization process not working properly, or asking for interactive login, both of which shouldn't be necessary for the authorization method used by WMDP.

So in this post I would like to give a small configuration tip that prevents the below error message:

Error: "The user or administrator has not consented to use the application with ID ''. Send an interactive authorization request for this user and resource.

The reason this error is shown is because the Native application setup in Azure for WMDP has access to resources that require the Azure admin to consent to that first.

WMDP app is configured to allow access to AAD resources
As you can see, some of the resources WMDP app has access to require prior Admin consent.


When configuring the Native application for WMDP in Azure, only give it permissions for the Microsoft Dynamics ERP resources.

This will ensure you don't get unexpected errors when trying to connect to WMDP.

Happy Holidays to all of you!

Stay tuned for more posts next year and subscribe if you haven't already to get updates on the latest tips and tutorials for Dynamics 365 for Operations aka Dynamics AX aka Axapta :)

Thursday, November 24, 2016

Tutorial Link: Handling exceptions the right way in X++

Michael and I have been working the last couple of weeks to uncover some of the difficult to repro bugs in Warehouse management code, and one of the things we discovered is a pattern which can lead to very unpredictable behavior when used incorrectly.

I encourage all of you to read it and make sure all of your code is up to standard.


Monday, November 14, 2016

Tutorial: Location directive failures - Common mistake #2 - Batch enabled

This is a blog in a series about Location directive failures.
You can find the original blog post here:
Tutorial: Location directive failures - Common mistake #1 - Multi SKU

Common mistake #2 - Batch enabled location directive line

Very often when new people start working with the Advanced warehousing solution, they struggle to notice the little check-box on the location directive lines called Batch enabled. However, it is very important when dealing with batch-tracked items in outbound flows like Sales order processing.
Here's the typical scenario when users try to set up the location directives for the first time:

They created all the necessary Pick and Put directives, decided how they want to go about the lines and different units of measure, and now they are defining the actions, which in turn means defining the query for locations to consider for pick-up/put-down.

Here's a typical and valid location directive configuration:

Valid location directive setup without Batch enabled set
After that they create a sales order, reserve the inventory, release the order to warehouse and are surprised to get the following warnings:

Release to warehouse failed for batch-tracked item P0004
Sadly, there is no indication in the work creation log that would explain why the release failed apart from the fact it could not allocate the item.

But the reason is - the location directive action was not considered a match, because only ones with Batch enabled were considered for this item.
So let's change that and try again.

Valid location directive setup with Batch enabled set
Note, that this modifies the query you can use for selecting which locations should be considered, adding the Batches table to the query, so you can, for example, select to only consider locations, where there is on-hand for a batch that is to expire more than 20 days from now.

Defining the location directive action query for batch enabled action line
Once the setup is changed, let's re-release the sales order (to show the exact same flow as before, I deleted the load line / shipment that were created before):

Release to warehouse succeeded for batch-tracked item P0004
As you can see, now all is great, and the created work looks like below, correctly picking up the items from a Picking location we defined in the location directives:

Work created for picking sales order 000785

What this means for your configuration

What this virtually means is:
  • If you do not track batches on your items in the selected warehouse, you can ignore this setting completely
  • However, if you do track batch numbers, you will most probably want to have 2 action lines for the same location directive line every single time, one for batch-tracked and one for non-batch tracked. 
    • That might be exactly what you want if you want to keep track of your batch-tracked items (perishable goods) separately from non-perishables.
    • If not, however, then it gets pretty inconvenient, and I have no knowledge of why the original implementation was done this way (Maybe somebody from BHS can answer in the comments), but we do not have any plans to change this in the near future.
Note, that for inbound flows this check-box is not considered and is not even enabled in setup. 

What's next

In the next blog post of this series we'll talk about Disposition code and how that impacts the receipt flow

Friday, November 04, 2016

Tutorial Link: Executing outbound work with pending demand replenishment work


In Dynamics 365 for Operations we solved one of the long-standing complaints, where large work orders could not be started because of pending replenishment. A typical workaround then would be to artificially broke down the replenishment lines into a separate work order, so workers can do the picking for the majority of stuff. Then of course you'd get into problems with merging the two (or more) Target LPs onto one (which we now also support - see my previous blog post).

Read the feature description and and walk through a sample flow on our SCM blog:

For those on AX 2012 R3

We have not back-ported this feature to AX 2012 R3 yet. We have it in the backlog, but no ETA for when that will happen.


We'd love to hear your feedback on this feature if you are going to use it in your production environments.