Warehouse Mobile Device Portal


The Advanced Warehousing functionality introduced in Microsoft Dynamics AX 2013 R3 includes a brand new Warehouse Mobile Device Portal (WMDP). This portal serves HTML pages which drive the work executed within the warehouse. We have designed the portal to generate HTML that is widely compatible on a variety of devices, and although we do not recommend any specific devices – any device that supports a basic Internet browser or browser emulator will operate with the new warehouse functionality. This is further explained in this blog post: http://blogs.msdn.com/b/dynamicsaxscm/archive/2014/07/18/which-devices-can-you-use-for-warehouse-mobile-device-portal.aspx

The devices we see deployed with the advanced warehousing solution are often rugged industrial equipment, designed to work within the hostile environment of the warehouse. These often support integrated barcode scanning and can survive the occasional accidental drop. With an often significant investment in these devices we wanted to ensure the Microsoft Dynamics warehouse solution works across the widest possible distribution of devices. We also wanted to ensure the workflows and capabilities exposed by the mobile device interface were flexible enough to match the business processes of your warehouse. Thus the entire interface that is built and rendered on the mobile device is extremely flexible – with the entire menu system and workflow exposed and extensible both from within core AX and through partner code.

This blog post is the first in a two part series that will cover customizing the mobile device portal. This post will cover the options exposed in Microsoft Dynamics AX 2012 R3 to build custom mobile workflows for your workforce and how to build different mobile experiences depending on user and device criteria. The next blog post will cover the deeper code underpinnings of the mobile device portal and how it can be extended to expose additional workflow options.

Menu

At the heart of the mobile device portal interface lies the concept of Menus and MenuItems. These are configured in AX by navigating to Warehouse Management -> Setup -> Mobile device. The high level concept of a Menu is simply a flexible container that can contain both MenuItems as well as other Menus (i.e. it is a nestable structure). Thus it is possible to construct an interface for your users that provides exactly the capabilities required for the role they are assigned. For example, it is possible to build a Menu that only exposes the outbound picking operations for a certain segment of warehouse workers, and have a separate menu structure used by the forklift operators for replenishment operations.

The menu item interface can be seen below. Menus can be defined in the top section, and MenuItems can be added to the selected Menu in the lower section from the list of all available MenuItems in the bottom right list.

MenuItem

Defining a MenuItem is done in the Mobile device menu item screen – and there are a lot of options available for configuring the workflow exposed to the end user. A complete description of all fields available on this screen can be found at the following TechNet article: https://technet.microsoft.com/en-us/library/dn553216.aspx. This blog post will try to simply touch on the high-level functionality of MenuItems – please see the TechNet article for more details regarding the options available.

MenuItem – Mode

When creating a new MenuItem, you first must decide the Mode that this activity will be operating under. This can be “Indirect” or “Work.” This defines if the MenuItem will interact and operate on Work in the warehouse (i.e. Work mode), or if it will support some sort of ancillary process in the warehouse not directly related to a Work line (i.e. Indirect mode). Selecting the Indirect mode will cause the UI to display the list of “Activity codes.” This allows the user to select the non-work related workflow that will execute when this MenuItem is selected on the mobile device.

Again – the complete list of activities can be found in the TechNet article, but the following are a sampling of the possible workflows:

Change warehouse

Change the warehouse that a worker is logged on to.

Location enquiry

View information about all items and quantities for a location.

License plate enquiry

View the quantity of items on a license plate, and the location of the license plate.

Start production order

Start a production order.

 

Changing the Mode to “Work” will change the UI significantly. It will now be possible to select the checkbox “Use existing work.” This will configure the MenuItem workflow to either consume an existing Workline (checked) or to generate a new set of Work (unchecked). By leaving the checkbox unchecked (i.e. not to use existing work) the user will be able to define the exact work creation process required to generate new work through this MenuItem. This is often used when receiving items and/or starting putaway work.

There are various options available when defining the work creation process that will get initiated by this MenuItem. These will differ depending on the exact work creation process workflow selected – all of the various options are described in detail in the TechNet article referenced above. All of them are available to allow you to customize the exact business process that is enabled by the mobile device user.

Changing the selection to “Use existing work” will indicate that this MenuItem will process existing Work lines – and thus must be configured define exactly how that work should be processed. Again there are a multitude of options available to configure exactly how the workflow should proceed. In addition, two very important settings must be configured: how this work is directed, and the work classes available to process.  The Work classes section defines the valid work that this MenuItem can process; this can be used to restrict access to certain user roles or to separate processing logic for different types of operations.   

The “Directed by” setting defines exactly how the work will be selected for the mobile device user. This is a very important setting – as this is how the system will know what work to assign to a particular user. All of the options are defined in the TechNet article – these are copied here for convenience:

Option

Description

None

This default value does not process work.

System directed

Microsoft Dynamics AX controls the type of work that is assigned to a worker and the sequence in which to perform it.

When you select this option, you can click System-directed work to open the System-directed sorting order form, where you can set up sorting criteria for the work. The sorting criteria control the order in which the worker will perform the work. You can add as many criteria as needed.

User directed

The worker selects the work to perform and the sequence in which to perform it.

User grouping

The worker manually groups work. For example, this is useful when a worker can pick multiple items at the same time in a location. After the worker has finished picking all of the required items, he or she can put the items away.

System grouping

Microsoft Dynamics AX groups work for the worker based on a specified field. For example, picking work is grouped when a worker scans a shipment ID, load ID, or any value that can link each work unit.

If you select this option, the following fields are required:

  • System grouping field – Select the field that the worker will scan to group the work.
  • System grouping label – Enter text to inform the worker about what to scan to group the work.

Validated user directed

The worker selects the work to perform when work is associated with a larger entity, such as a load or shipment. The worker determines the order in which to pick the items.

If you select this option, you must select the following:

  • Validated User Directed Field – Select the field that the worker will scan to group the work.
  • Validated User Directed Label – Enter the text that will inform the worker about what to scan when picking work is grouped by the system.

For example, this is useful when multiple pallets are staged for a load. If you select the LoadId field, the worker can pick any pallet that is associated with the load. An error message is displayed if a worker scans an item that is not associated with the load.

Cluster picking

The worker groups work into clusters. Clusters enable workers to pick items from a single location for multiple work orders at the same time. For more information, see Set up cluster picking.

Cycle count grouping

The worker selects a zone, work pool, or location, and Microsoft Dynamics AX will assign work based on the selection. For more information, see Set up cycle counting thresholds and plans to perform cycle counting.

If you select this option, you can also click Cycle counting to specify additional information to display, and specify the number of times that the worker must repeat the count if a difference is found.

Work Users

In order to access the WMDP one needs to create at least one warehouse work user, which has a user name, password, default warehouse, and available mobile menu. In order to create a warehouse work user, a worker will first need to be defined within the HRM module. The HRM worker is typically associated with an AX user mapped to an active directory identity (through user associations defined in the administration module).

After creating the HRM worker, one can assign a number of warehouse work users to it through the “Worker” form accessed under Warehouse management -> Setup -> Work users -> Worker. You can think of the warehouse work users as a number of logins for the selected HRM worker – each one which can provide a default warehouse and targeted workflow exposed by the menu. Obviously it is also possible to simple define all your warehouse work users under a single HRM worker, but this is not the recommended pattern.

A warehouse work user is defined very simply with a user ID, user name, default warehouse, and a menu. This menu is loaded when the user logins into the portal, and is how different experiences can be tailored to different logins. For example, in the screenshot below we have created separate menus for the UPS drivers, the Forklift operators, and the primary warehouse workers. Each have a different set of MenuItems available, specifically only the ones required for them to perform their jobs effectively.

Mobile Site Customization

CSS Customization

The site that is created by the configured Menu and MenuItems can be further customized through a variety of options exposed through Microsoft Dynamics AX. These options are available through the work user mobile device display settings form – seen below. This screen allows a CSS file, display settings view, and keyboard shortcut settings to be defined for a set of criteria. This allows different displays to be rendered for different types of devices or browsers.

The most obvious way to customize the mobile site is through CSS customization. The default css file shipped with the mobile device portal (defaultrf.css) can be found at <AX Installation directory> \6.3\Warehouse Mobile Devices Portal\<WMDP Instance folder>\Content\CSS\RFCSS. This file defines the basic look and feel of the UI and includes things like the background color, text font and size, and the width and behavior of the rendered buttons. The default login screen is rendered in the following manner:

The overall look of the interface is defined by the default css file, which includes the following settings:

 

Note the background color and button colors have been customized, as well as the layout (100%) of the button and the hover behavior of the buttons. By removing all of the default css and replacing it with the following simple css, we can dramatically change the look of the UI:

This is achieved with the following css file:

body
{
    background: #777777;
    text-align: center;
}

.whsLabel
{
    font-size: 15pt;
    color: #FFFFFF!important;
}

.whsTextLabel
{
    color: #FFFFFF;
}

.whsPasswordLabel
{
    color: #FFFFFF;
}

 

Note the requirement for the important keyword in the .whsLabel class definition. This is because all whsLabels are generated with an embedded color component defined in the “mobile device text colors” form (or defaulting to black). This form can be found at Warehouse management -> Setup -> Mobile device -> Mobile device text colors. Unfortunately this form does not allow criteria based filtering or customizing on the generated colors, so utilizing the css styling is the recommended way for updating the text colors.

The ability to change the look and feel of the generated HTML is more important than simply wanting a different background color or text color may initially appear. Different devices used in the warehouse may impose strict limits on what can or should be displayed for optimal visibility and usability. The need to specify a specific width or a specific format for buttons may be a requirement for the specific device utilized in the warehouse, in which case the css styling is a must for enabling the workflow.

Keyboard shortcuts

Another facility exposed in the “Work user mobile device display settings” form are keyboard shortcut definitions. These allow you to customize what hardware keys trigger different MenuItems. It is possible to map specific buttons to MenuItems such that when the MenuItem is visible users can press the hardware button to trigger the functionality on the device. This is often useful for warehouses when devices are used that have obvious keyboard mappings to specific functionality in the portal.

The format for setting up keyboard shortcuts is very specific, and the entered string must match the required format exactly so as to be registered into the client-side JavaScript correctly. The required format string for each shortcut is (note they can be appended together with a semi-colon):

<control name>(<key name>)=<javascript key code>;

The control name is the value of the “id” attribute in the generated HTML. This can be easily found by examining the generated HTML in a browser or developer tool. The key name is a string value displayed to the user in the button text – this is designed to help the user understand the available hardware button options. The JavaScript keycode is the value exposed from the JavaScript onKeyDown/onKeyUp methods.

An example keyboard shortcut string is:

Login(L)=76; Full(F2)=113

This would cause the “L” hardware button to execute the Login button automatically, and the “F2” hardware button execute the Full button. The generated HTML would inject the key name values into the button text, so the above string would result in the following pages:

Display Settings View

The last option available on this form is the “Mobile device display settings view.” This describes the name of the ASP.NET view file used to render the mobile site in the server-side ASP.NET application. This file controls how the overall structure of the HTML is laid out and customizing this functionality is only recommended if you have serious structural issues with the HTML and JavaScript that need to be changed for your specific devices. Note that, like the CSS files, there is a specific directory where these files need to be located so the IIS application can load them – <AX Installation directory>\6.3\Warehouse Mobile Devices Portal\<WMDP instance folder>\Views\Execute.

Criteria

All of the above settings (CSS file, Keyboard shortcuts, and Mobile device display settings view) can be customized in order to render a different mobile experience to different devices and/or users. The system uses the criteria column to determine exactly which settings to load. The criteria column allows the following attributes of the incoming request to be used to qualify the different settings rows:

  • Requestor IP address
  • Requestor Host name
  • Request User Agent string

Each of these values can be examined using a regular expression – any successful match will cause the specific display settings row to be loaded for that particular user session. The criteria string must match a specific format, and must include all three of the criteria options, even if you are only examining one of these values (wildcards must be specified for the others). The format of the criteria string must be:

Request.UserHostAddress=<user host address>|HostName=<user host name>|Request.UserAgent=<user agent>

Here is an example of the criteria used to differentiate between two browsers (Opera and Internet Explorer) based on the UserAgent field. Note the wildcard settings for the other two criteria options.

The above settings will enable us to display a different css file to different browsers – perhaps we are operating with two different classes of machines in the warehouse each with a different browser and different capabilities. We want to be able to target a different UI experience to each to ensure our users can be productive with their specific devices.

Mobile Device Portal Tools

There are two tools included with the mobile device portal that aim to make the processes describe above easier to configure. These tools can be found in the initial screen for the portal (i.e. go to the root URL of the portal).

The “View codes for keyboard shortcuts” will take you to a simple page that will display the JavaScript keycode for the hardware key pressed. This would allow you to test the specific hardware buttons for your devices in order to configure the keyboard shortcuts described above.

The “View server configuration for display settings” will show you the current display settings view selected, as well as the IP address, Host name of the requestor, and the full User agent string. As described above, these three fields are what is available to be queried against in the criteria string – so this page can be used to see exactly what the different values might be for the different devices in use in your warehouse.

Further Information    

For more information about the ways to customize the mobile device interface, please see the following TechNet article: https://technet.microsoft.com/en-us/library/dn553175.aspx.

 

Hopefully this was a useful overview of some of the configuration options available out of the box with the Warehouse Mobile Device Portal. In our next post we will cover customizing the portal in a deeper way, showing how the X++ code builds the portal workflows and how partner code can be injected to build new workflows.

Comments (20)

  1. Keith says:

    Great Post! Keeping putting information like this out there.

    With System Grouping, the worker has to know the load id or shipment id first?

    How does the worker know what those ID's will be if they are just performing picks and have situations where orders are being consolidated to a truck?

    I ask this because I don't understand how the shipment id  or load id will be known yet in situations where we have a shipping carrier coming at the end of the day and we're building the load as the day progresses. In my situation we may not fully know what will be on that load or in the shipment until that truck show up at the bay door and we say "Ok this truck is full, lets start picking for tomorrow"

  2. Thanks Keith.

    In the advanced warehousing module, we do not yet support a pick scenario without having a shipment and a load.  It would be possible to consolidate loads at the end of the day based on what fits into the truck – but there is no native functionality in AX for "fluid picking" as you describe.

  3. Tatiana says:

    Great Post! It really help. Quick question: Can we process receiving; put away and picking processes without mobile device using advanced warehousing module? Let say we are in the situation where we dont want to use guns but someone in the office will do all those processes in the system ( print; pick; put away; receiving; etc…)

    Thanks

  4. Hello Tatiana,

    There are two ways to process work from within the rich client.  

    We ship a mobile device emulator within the product that is primarily intended to be used for testing and debugging purposes, but exposes all of the same functionality as the mobile portal.  If necessary you could expose this form through a customization and do some of the mobile work processes from within the AX rich client experience.  This form is WHSWorkExecute.

    The other option is to manually complete the work from the AX client.  In AX you can see a list of work (Warehouse management -> Common -> Work -> All Work).  Selecting one of the work headers gives you the option to manually complete the work (the button at the top of the form).  Note this option is only available for existing work – so it cannot be used for processes that generate work, such as receiving.  In those cases you will need to use the mobile device emulator or the actual mobile portal.

    Hope that helps.

  5. Brandon Nash says:

    I have multiple shipments that are consolidated into a single wave and going to separate customers.  Is  there a way to put the consolidated sales work into separate staging locations? Thank you in advance!

    1. Jeff Watson says:

      Brandon-
      Dock management profile (on the Location profile) allows you to break staging by not allowing mixing (by Shipment ID, Load ID, Order Number, or Work order type) at a staging location.

  6. Anthony Mattos says:

    If anyone needs help with their rugged, mobile bar code readers, printers or labels, we 19 years experience and have worked with other AX users.  

    Anthony Mattos

    RedLine Solutions

    510-418-2326

    amattos@redlinesolutions.com

  7. UM001 says:

    We have to select WaveLink or Velocity for HTML5. HTML5 is more expensive. Does WMDP run HTML5 or less?

  8. Pawel Kruk says:

    WMDP does not require HTML5 compatible browser. HTML4 is good enough.

    Best regards,

    Pawel

  9. Rick Hoss says:

    We need the field names of the screens to be in Chinese.  

    I opened a ticket with MS and says that was not supported out of the box.

    They would not tell me where the code …

    I have no problem changing the field names manually if I can get to the code or html.

    Is this possible.

    I can change the labels of the menus in Ax easy enough but that is just superficial change.

    Thanks.

  10. Rick Hoss says:

    I proved to myself that WMDP is using AX label file by changing the value of one of the labels in en-us and sure enough the label change on the web screen.

    I know there are WHS classes that are running that are looking at language but I don't know how to tell the web to use a different label file other than 'en-us'…. I would find all of the labels that I need on the WMDP screens and change characters to Chinese but that seems silly.

    Why would MS design a global system to only work with language 'en-us;

    What is the setting to tell WMDP to use a different language?

    the WMDP users setup does not allow language to that user to be specified.

    Thanks

    Rick

  11. UM001 says:

    Hi,

    How this  <%= "<link href="" + AppHelper.RFCSSUrl(SessionHelper.CSSOverride) + "" rel="stylesheet" type="text/css" />"%>

    work?

    I want to detect a 290×320 screen size.

    J.

  12. Jason Cuolahan says:

    Hi Zach,

    I have a scenario where I am creating a load for multiple Purchase orders coming onsite and then using the System grouping process to group put the items received into their various locations.  I am having an issue sorting the put locations from start of WH to end or via the location sort.  Currently put always goes to put the last receive work i had completed and works backwards from there, not sorting at all.  Any ideas?  Have you seen this before?

    Cheers,

    Jason

  13. Hi Jason,

    Yes, this is a known limitation of the current design, it is always put away from last to first.

    We have a design change request for this in our backlog, but no ETA at the moment for when it will be fixed.

  14. Vijay Bajaj says:

    I had a query regarding configuration of screen size depending on the mobile device used. Incase a user uses multiple mobile devices for performing transactions (each device having different screen size), can the screen size be dynamic and get bigger/smaller depending on the mobile device used. Is there any customization required or this can be done out of the box.

  15. Rohan says:

    Thanks a lot, Zach. The article was great.

  16. Henning says:

    Great post. Thanks.
    I have a question. When you are running a global ,multi company setup, is it possible to have default Warehouse inbound/outbond manual paper handling in one site and scanning in another in AX2012? I have heard that Microsoft only support one of them as a global setup. Sounds strange to me. Today I am running a setup in AX2009 with a sentral warehouse that is paperless, and multiple IC salescompanies with small, manual handled warehouses.

    1. Claude says:

      Hi Zach,

      Many thanks for this post! Concerning this statement :
      “Obviously it is also possible to simple define all your warehouse work users under a single HRM worker, but this is not the recommended pattern”.

      Can you explain why it’s not recommended? Is it just a functionnal recommendation or a real technical recommendation? I mean, is there any risk of blocking transactions or bugs… if several worker are attached to 1 HRM worker and work at the same time with RF device?

      Many thanks in advance.

      Many than

  17. Rohan says:

    Hi,
    We have created a customization related to creating transfer orders in AX through WMDP.
    The code piece is working perfectly fine when we are testing it in AX using WHSWorkExecute form. But, when we try to access the same in the web browser, nothing works.

    The requirement is to create transfer order lines on a transfer order based on certain validations. The form works fine in AX but while opening in the web browser, it does not take any data and refreshes the same screen again and again.

    Is there any configuration that is missing? I would request if anyone can provide their input on this.

  18. Mike says:

    Do mobile warehousing module entries need to be uploaded to MSDN “non mobile” warehousing? (to the advanced warehouse)

Skip to main content