Cumulative update 13 for Microsoft Dynamics AX 2012 R3 is now available for download on Lifecycle Services, PartnerSource and Customersource. In this blog post, we will give you an overview of the feature improvements for warehouse and transportation management. If you want more details about the release of CU13, see the Dynamics AX In-Market Engineering blog. The knowledge base article for Cumulative Update 13 is KB4032175.
This is a backporting of an enhancement added to a later version of the product.
The traditional way of using the system is still supported.
For more informatin, see Set up short picking item reallocation.
For more information, see: Product confirmation for cluster picking.
A transfer order that is released to warehouse will generate work of the type Transfer issue and this work can then be picked from the production output location and put to a location that is determined by the Transfer issue location directive for work.
In the latest version of Dynamics 365 for Finance and Operations, Enterprise Edition we put a lot of effort to make it easier to create initial configuration of the Cost Accounting module.
Take a look how simple it is!
We last looked at the Warehouse Mobile Devices Portal (WMDP) in detail in a series of blog posts here, here, and here. The last one covered how to build custom solutions and walked through building a new sample workflow for the WMDP. This post will be updating that sample to cover some of the changes that have occurred with the Advanced Warehousing solution and the Dynamics 365 for Finance and Operations – Enterprise Edition warehousing application.
The Warehouse Mobile Devices Portal (WMDP) interface, which is an IIS-based HTML solution (described in detail here), is being deprecated in the July 2017 release of Dynamics 365 for Finance and Operations (see deprecated features list here). Replacing this is a native mobile application shipping on Android and Windows 10 devices. The mobile app is a complete replacement for the WMDP and contains a superset of capabilities – all existing workflows available in the WMDP will operate in the new mobile app. You can find more detail on the mobile app here and here.
The process for customizing the new mobile app is largely unchanged – you can still utilize the X++ class hierarchy discussed in the previous blog post. However – I want to walk through some of the differences that enable customizations to exist as purely extensions. The previous solution required a small set of overlayered code. Moving forward this practice is being discouraged and we recommend all partners and customers create extensions for any customizations.
As before, we will be focusing on building a new workflow around scanning and weighing a container. The inherent design concept behind the Advanced Warehousing solution is unchanged – you will still need to think and design these screens in terms of a state machine – with clear transitions between the states. The definition of what we will build looks like this:
Just as in the previous blog post – to add a new “indirect work mode” workflow we will need to add values to the two enumerations WHSWorkExecuteMode and WHSWorkActvity. The new enum names need to match exactly as one will be used to instantiate the other deep inside the framework. Note that both should be added as enumeration extensions built in a custom model. Once this has been done it will be possible to create the menu item in the UI – since the WHSWorkActvity enumeration controls the list of available workflows in the UI:
You can see the extension enumeration values in the following screenshots:
The core logic will exist within a new class you will create, which will be derived from the WhsWorkExecuteDisplay base class. This class is largely defined the same way as the WMDP-based example, however there is now a much easier way to introduce the mapping between the Execute Mode defined in the Menu Item and the actual class which performs the workflow logic – we can use attributes to map the two together. This also alleviates the need to overlay the base WHSWorkExecuteDisplay class to add support for new derived classes (as the previous WHSWorkExecuteDisplay “factory method” construct forced us to do).
The new class will be defined like this:
class conWhsWorkExecuteDisplayContainerWeight extends WhsWorkExecuteDisplay
Note that all the new classes I am adding in this example will be prefixed with the “con” prefix (for Contoso). Since there is still no namespace support it is expected partner code will still leverage this naming scheme to minimize naming conflicts moving forward.
The displayForm method is required – and acts as the primary entry point to the state machine based workflow. This is completely unchanged from the previous example:
class conWhsWorkExecuteDisplayContainerWeight extends WhsWorkExecuteDisplay
container displayForm(container _con, str _buttonClicked = '')
container ret = connull();
container&nbsp;&nbsp;&nbsp;&nbsp;con = _con;
pass = WHSRFPassthrough::create(conPeek(_con, #PassthroughInfo));
con = conDel(con, #ControlsStart, 1);
ret = this.getContainerStep(ret);
ret = this.getWeightStep(ret, con);
ret = this.processWeightStep(ret, con);
ret = this.updateModeStepPass(ret, WHSWorkExecuteMode::WeighContainer, step, pass);
A detailed analysis of this code can be found in the previous blog post – we will skip forward to the definition of the getContainerStep method, which is where the first screen is defined. The two methods used to define the first screen are below:
private container getContainerStep(container _ret)
_ret = this.buildGetContainerId(_ret);
step = conWeighContainerStep::EnterWeight;
container buildGetContainerId(container _con)
container&nbsp;&nbsp; ret = _con;
ret += [this.buildControl(#RFLabel, #Scan, 'Scan a container', 1, '', #WHSRFUndefinedDataType, '', 0)];
ret += [this.buildControl(#RFText, conWHSControls::ContainerId, "@WAX1422", 1, pass.lookupStr(conWHSControls::ContainerId), extendedTypeNum(WHSContainerId), '', 0)];
ret += [this.buildControl(#RFButton, #RFOK, "@SYS5473", 1, '', #WHSRFUndefinedDataType, '', 1)];
ret += [this.buildControl(#RFButton, #RFCancel, "@SYS50163", 1, '', #WHSRFUndefinedDataType, '', 0)];
Note that I am using a class to define any custom constants required for the Warehousing logic. This was typically done with macros in the previous version – but these can cause some issues in extension scenarios. So instead we are encouraging partners to define a simple class that can group all their constants together – which can then be referenced as you see in the code above. The only area where this does not work is in attribute definitions – this will still need a Macro or String definition. Here is mine so far for this project:
public static const str ContainerId = "ContainerId";
public static const str Weight = "Weight";
The other important thing to notice in the above code is that I have explicitly defined the data type of the input field (in this case extendedTypeNum(WHSContainerId)). This is important as it tells the framework exactly what type of input field to construct – which brings us to the new classes you need to add to support the new app functionality.
In the previous version of this blog we discussed the fact that since we are adding new fields to the warehousing flows that are not previously handled in the framework we must modify (i.e. overlayer) some code in the WHSRFControlData::processControl method. This allows the framework to understand how to handle the ContainerId and Weight fields when they are processed by the WMDP framework.
In the new model these features are controlled through two new base classes to customize and manage the properties of fields. The WHSField class defines the display properties of the field in the mobile app – and it is where the default input mode and display priorities are extracted when the user configures the system using the process described here. The WhsControl class defines the logic necessary for processing the data into the field values collection. For my sample, we need to add support for the ContainerId field – so I have added the following two new classes:
class conWhsControlContainerId extends WhsControl
public boolean process()
class conWHSFieldContainerId extends WHSField
private const WHSFieldClassName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = "@WAX1422";
private const WHSFieldDisplayPriority Priority = 65;
private const WHSFieldDisplayPriority SubPriority = 10;
private const WHSFieldInputMode&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; InputMode&nbsp;&nbsp; = WHSFieldInputMode::Scanning;
private const WHSFieldInputType&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; InputType&nbsp;&nbsp; = WHSFieldInputType::Alpha;
protected void initValues()
this.defaultName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = Name;
this.defaultPriority&nbsp;&nbsp;&nbsp; = Priority;
this.defaultSubPriority = SubPriority;
this.defaultInputMode&nbsp;&nbsp; = InputMode;
this.defaultInputType&nbsp;&nbsp; = InputType;
Obviously my conWhsControlContainerId class is not doing much – it is just taking the data from the control and placing it into the fieldValues map with the ContainerId name – which is how I will look for the data and utilize it later in the system. If there was more complex validation or mapping logic I could place that here. For example, the following is a snapshot of the process logic in the WhsControlQty class – this manages the logic for entering in quantity values from the mobile app:
public boolean process()
Qty qty = WHSWorkExecuteDisplay::str2numDisplay(data);
if (qty &lt;= 0)
if (mode == WHSWorkExecuteMode::Movement &amp;&amp; WHSRFMenuItemTable::find(pass.lookup(#MenuItem)).RFDisplayStatus)
if (mode == WHSWorkExecuteMode::Movement &amp;&amp; fieldValues.exists(#Qty))
pass.parmQty(qty ? data : '');
fieldValues.parmQty(qty ? data : '');
//When 'Display inventory status' flag is unchecked, need the logic for #FromInventoryStatus and #InventoryStatusId
The buildGetWeight method is very similar to the previous UI method – the only real difference is the Weight input data field. Note that we don’t need to define a custom WHSField class for this field because it already exists in the July Release.
There was another minor change that was necessary before I could get the expected behavior, and it points to a slight change in the framework itself. In the previous version of the code when I reported that the weight was successfully saved I did so with an “addErrorLabel” call and passed in the WHSRFColorText::Error parameter to display the message at the top of the screen. This same code in the new warehousing app will now cause the previous step to be repeated, meaning I will not get the state machine transition I expect. Instead I need to use the WHSRFColorText::Success parameter to indicate that I want to display a status message but it should not be construed as an error condition.
container processWeightStep(container _ret, container _con)
containerTable = WHSContainerTable::findByContainerId(pass.lookupStr(conWHSControls::ContainerId),true);
containerTable.Weight = pass.lookupNum(conWHSControls::Weight);
_ret = conNull();
&lt;strong&gt; _ret = this.addErrorLabel(_ret, 'Weight saved', WHSRFColorText::Success);
_ret = this.getContainerStep(_ret);
_ret = conNull();
_ret = this.addErrorLabel(_ret, 'Invalid ContainerId', WHSRFColorText::Error);
_ret = this.getContainerStep(_ret);
The mobile app as well as the AOS perform a significant amount of caching, which can sometimes make it difficult to add new classes into the framework. This is because the WHS code is heavily leveraging the SysExtension framework. I find that having a runnable class included in the project which simply calls the SysExtensionCache::clearAllScopes() method can help resolve some of these issues.
At this point I have a fully functional custom workflow that will display the new fields correctly in the mobile app. You can see the container input field and weight input below. Note that if you want to have the weight field display the “scanning” interface you can change the “preferred input mode” for the Weight EDT on the “Warehouse app field names” screen within the Dynamics 365 environment itself.
The Dynamics 365 for Operations project for this can be downloaded here. This code is provided “as-is” and is meant only as a teaching sample and not meant to be used in production environments. Note that the extension capabilities described in this blog are only available in the July Release of Dynamics 365 for Operations and Finance or later.
Financial dimensions are available on each requisition line in the lines details. The purpose is to let you update the accounting distribution ledger account on the requisition line. The accounting distribution ledger account consists of a main account and financial dimension values. Accounting distributions are used to define how an amount will be accounted for, such as how the expense, tax, or charges will be accounted for and posted in the ledger.
Updates on the financial dimension values on the requisition line will update the accounting distributions ledger account, not the other way around.
When a purchase requisition line is created, the values of financial dimensions are assigned from various sources that are specific to the purchase requisition line.
This works such that the logic will apply values from what is considered the most important or specific source toward the least important source. The sources are ranked in the following order:
If one of the sources is not on the requisition, e.g. not related to a project or does not include a reference to a specific item from the master data, then the source is ignored.
The financial dimensions are only assigned a value once. This is done by first taking all dimension values available from the project, and then taking the dimension values from Requestor that are used but not already assigned a value. Next, the values from the Vendor for dimensions that were not already assigned a value are used, and so on. In the following example, the default financial dimension values are set up for Vendor 1 and Requester.
Create a requisition line for an item that has the default Vendor1.
As you can see from the table above, the Requestor’s default value for financial dimension is Department (033). This value takes priority over the Vendor’s default value Department (025).
If the requisition is not for a project, then that source will not contribute to the financial dimension values.
The accounting distribution ledger account dimension values will be set according to the final result of the values on the requisition line.
When you update a financial dimension value on the requisition line to a non-blank value, that will update the dimension values on the accounting distributions. If the accounting distribution lines are split, then all lines will be updated with the new value.
For stocked items and fixed assets, the financial dimensions need to be in sync between the financial dimension on the line and the accounting distributions. Note that the accounting distributions cannot be split or edited manually for such cases.
Two of the original sources for setting financial dimension can be changed on the requisition line: project and vendor. Changing one of these on the requisition line will reinitialize the financial dimensions on the requisition line according to the ranking of the sources described above. The new initialization of the financial dimension values will only update the financial dimensions that do not have any value, i.e. are blank. The existing financial dimension values on the purchase requisition line will take priority, and thereby keep their value.
Changing the project or vendor will also mean that the accounting distributions ledger account is reset and updated based on the new project or vendor and the updated set of financial dimensions. If the accounting distributions are spilt, then the split will be removed during the reset.
Note that if you want to ensure that the financial dimensions are reset to how the requisition line was initially created when changing the project or vendor, clear all the financial dimensions on the requisition line that you want to re-default.
Set up the following default values.
Create a requisition line for a non-catalog item.
You can only use a template for non-stocked items and lines not referring to a catalog item. The lines should also not be categorized as a fixed asset item.
When you apply a template on your requisition line it will update the accounting distribution directly with a split distribution on different dimensions. Applying a template will not change the financial dimension values on the requisition line.
However, if you manually change a financial dimension value to a non-blank value on the requisition line, then that dimension will be updated on all split accounting distribution lines. Clearing a financial dimension value on the requisition line will not change the accounting distributions.
If you change a vendor or project the financial distributions from the vendor or project will update the financial dimension on the requisition line as described above; however, using a template will prevent the accounting distribution split from being cleared. Any updated dimension value will update all the split lines in accounting distributions.
If you remove the template from the requisition line, then the accounting distributions will be reset based on the financial dimension values on the requisition line. Any split lines in the accounting distributions will be removed.
We’re very happy to announce that Dynamics 365 for Operations – Warehousing has been made available on Windows Store and Google Play store. This app empowers warehouse workers in your organization to complete tasks in a warehouse by using mobile devices. It enables material handling, receiving, picking, putting, cycle counting, and production processes with your Dynamics 365 for Operations subscription.
The Dynamics 365 for Operations – Warehousing app includes the following features to boost productivity:
This blog post will take you through the prerequisites, how to navigate the app, and the options to configure the app in Dynamics 365 for Operations.
The app is available on Android and Windows operating systems. To use this app, you must have one of the following supported operating systems installed on your devices. You must also have one of the following supported versions of Dynamics 365 for Operations.
Use the information in the following table to evaluate if your hardware and software environment is ready to support the installation.
Microsoft Dynamics Dynamics AX version 7.0/7.0.1 and Microsoft Dynamics AX platform update 2 with hotfix KB 3210014
The app is available for download here:
For detailed steps on how to install and configure the app, refer to this tutorial: Install and configure Dynamics 365 for Operations – Warehousing.
The app comes with a new user experience. In this section I will go through and show different pieces and elements that we have changed in the UI.
Once the app is installed and configured to connect to a Dynamics 365 for Operations instance, you will be presented with a log-in screen. Sign in with the User ID and password of the warehouse worker. Learn how to manage warehouse workers with this tutorial: Manage warehouse workers.
In the below image you can see the log-in experience, as well as the menu structure and navigation.
For our most common flows that follow the same pattern of scanning input fields, we have changed the UI to split all information into two pages, the task or details page. In the task page, the information shown will be the main input field, three rows of additional information, and a previously scanned value. Sometimes there’s more information to any given screen than what can fit in three rows, and therefore we made the Details page, which will contain all overflowing information and input fields, as well as product picture in case that exists for the item. You can control in what order you want information to be prioritized to be shown on the Task page, this is done from the Warehouse app field priorities page in Dynamics 365 for Operations. This will be explained a bit further down in this blog post.
The app comes with a custom numeric keypad, specially designed with rugged environments in mind. It has large buttons that are easy to touch, and a nifty calculator for those occasions where quantities needs to be converted on the fly.
Alternatively, we have added a stepper for quantity input fields, where you can deduct or add to the quantity field without using the numeric keypad. This can be useful when it is not a high amount, and just a quick change is needed.
If there’s multiple input fields in any given screen with values not seen before, the app will recognize this and display a different UI. If there is 3 or less input fields, a carousel will be shown, which will allow the warehouse worker to quickly switch between input fields, without leaving the task page.
If there’s more than 3 input fields filled out and not seen before, a multi-input page with all input fields shown in a list will be displayed. The example below is during a movement of goods, where an existing license plate is scanned for movement, where the app receives information on what item, quantity, unit etc. that is on the license plate. It will then display that content with multiple input fields on the Task page, in order to enable the warehouse worker to quickly review, and move forward to the next step.
As you might have noticed from the previous pictures, there’s not any buttons displayed on any of the screens except for the green OK button. We have deliberately moved all other buttons to an action pane, that is accessible from the hamburger menu in the top right corner.
There are two new pages added in Dynamics 365 for Operations:
I will explain below the use of these pages, and how they relate to the app.
In Operations you can configure how metadata should be shown on a warehouse mobile device on the Warehouse app field names page.
In a new environment or company, you can select Create default setup to generate all field names that exist in any of the warehouse mobile device workflows, and assign them a default preferred input mode and input type.
Once you’ve generated a list of field names, the following options are available:
In the Warehouse app field priority page, it is possible to put field names into different priority groups. This makes it possible to decide what information should be promoted to the main task page when warehouse workers are performing work using the app.
If you click Create default setup, a default set of priority groups will be generated. It is possible to create as many priority groups as needed, but only three priority groups will be shown on the task page of the app at any given time.
When Operations is sending out metadata to the app, it will give each field a relative priority depending on its priority group, and the app will display the first three priority groups contained in the metadata on the task page of the app. The rest of the overflowing metadata will be presented on a secondary details page.
This blog post has provided a brief overview of Dynamics 365 for Operations – Warehousing. As always, we would appreciate any feedback you may have. We hope you enjoy using the app.