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.
Based on the input that we have received from many of our customers and partners, we have improved the packing station experience in Dynamics 365 for Operations version 1611 (November 2016) to make sure that it seamlessly integrates with the rest of the warehouse workflows.
On a high level, we have improved the following areas:
If you are not upgrading from a previous Dynamics AX version where packing processes were used, you can skip this section.
The In packing status has been removed from the shipments and loads as they were not working consistently and resulted in redundant data. Consequently, the list pages for In shipments and Loads in packing have been deprecated. Containers in packing are tracked at a location level.
In previous versions, the packing location was defined as a Location profile ID. In the current version, this is changed so setup of packing location will be defined using location types to align with the process for identifying staging and final shipping locations.
It is possible to continue the operation with the current setting, but we recommend that you update the setting because the legacy packing setting will be deprecated in future versions.
Please note that this process is irreversible. After clearing and saving the Profile ID for packing location field, the field will be disabled and cannot be used anymore. For installations where the legacy has not been used, the legacy setting will always be disabled.
IMPORTANT UPGRADE GUIDELINES
Set up packing location profiles and packing locations in the same way as setting up staging and final shipping locations.
Create a location type that identifies the packing.
Under Set up parameters for Warehouse management, select Pack in the Packing location type.
Create one or more location profiles that use the packing location type.
Notice the setup for the packing location profile:
Set up the locations that operate as packing stations to use the new packing location profile ID.
Overall, the concept of using location directives to bring goods to the packing station is not changed.
The setup for using work to move goods out of the packing station will be described later in this document.
Before the packing station can be used, the Dynamics 365 for Operations user account must be associated with a user and the user must be created as a warehouse worker as shown below.
When navigating to the Pack form, the warehouse worker will be asked to log in the packing station by specifying the location of the packing station and the packing profile.
As it is very common that the same warehouse worker will work at the same packing station for a longer period, it is recommended to set up default values for the worker as shown below.
For the default packing station, it is possible to set up any combination. You can choose site only, site and warehouse, or even site, warehouse and location if the worker is always logging in the same packing station. All the values are the default values, but can be changed after login.
The default profile can be used for the warehouse manager to guide the warehouse worker at the packing station on what process to use when operating at the packing station, or it can be used for the warehouse worker to store favorite packing settings.
When selecting a Packing profile ID that has a Container packing policy associated with it, it is not possible to change the Container packing policy. If selecting a Packing profile ID without a Container packing policy, it will be possible to specify another default Container packing policy.
The Close container profile field has been renamed to Container packing profile because it has a different impact on how containers are processed during packing.
In the previous versions, the Close container profile field was only used when a container was closed waiting for the decision as to which final shipping location the container should go to and what unit of measure should be used as the default value when weighing the container. As no work creation was supported, the container immediately appeared at the final shipping location after the container was closed.
In the current version, the Container packing policy defines how the container should be processed and consequently, it is applied immediately when a new container is created.
On the Overview tab, it is still possible to specify the actions when closing the container, but now it is possible to operate with or without work creation as well as defining when the container should be released from the packing station.
Using this parameter, it is possible to define what should happen when the container is released from the packing station by specifying one of the following options:
A new work order type called Packed container picking is introduced. The work order type is used to describe the work created after a container or container group is released from the packing station.
In most cases, it is recommended to create work for moving the containers as it results in a better representation of the actual manual processes in the warehouse. There might be setups that are very simple or where packing station is located directly in the bay door area where it would be preferable to let the container be available at the final shipping location.
It is not possible to use work breaks, but it is possible to set up different work templates for different warehouses depending on the warehouse or the shipping carrier.
The examples below show templates for moving a container from staging or directly to the bay door.
By using this parameter, it is possible to define what should happen when closing the container by specifying one of the following options:
The setting of this parameter will depend on the nature of the individual customer and packing stations. If the packing station is mainly handling single container shipments directly to customers, it will be most natural to release the containers immediately. If the packing station is handling shipments with multiple containers or even pallets it will probably be optimal to delay the release until the entire shipment or pallet is packed and ready for pick up.
This parameter enables the user to choose a default unit of measure used for container closing and manifesting. Usually this will be the unit of measure of the scale used at the packing station.
The parameter will work for policies with or without work creation.
Manifesting is the process of specifying the weight of a container, container group or shipment as well as a tracking ID provided by the transportation provider.
There is no direct integration with external transportation provider systems. The warehouse worker must print the label from the external provider system and scan the tracking number when completing the manifest procedure.
As manifest requirements vary from customer to customer and even from shipment to shipment, the packing policies allow a lot of flexibility when it comes to the workflow. It is possible to set up manifests for containers, container groups and shipments in any combination.
If using a multiple level manifest procedure, it is a requirement that:
Manifesting will be described in more details when the workflow of the packing station is explained.
Container manifesting should be enabled if it is required to complete a manifest for every single container packed at the packing station.
Manifesting is activated by the parameter Manifest requirement for container. If this is set to Manual, the manifesting will be included as a requirement in the packing workflow. It will not be possible to close and release the container before the manifesting is completed. If the parameter is set to Transportation management, the manifesting will still be performed through the TMS rate engines. Please note that this requires partners to implement a specific engine for the transportation provider and will not work out of the box in the current version.
If activating the Automatic manifest at container close, the warehouse worker must specify the manifest information as part of the Close container dialog to avoid a two-step process. This is usually the preferred setting if the same worker is packing and manifests the containers.
If activating the Print container content parameter, the container content report will automatically be printed as part of the container close. The report can of course also be printed and reprinted on demand.
Container group manifesting should be enabled if it is required to complete a manifest for every single container group packed at the packing station. This will normally be used if containers are packed on a pallet and the entire pallet is manifested.
Manifesting is activated by the parameter Manifest requirement for container group. If this is set to Manual, the manifesting will be included as a requirement in the packing workflow. All containers included in the group must be closed before the group can be manifested.
There’s no transportation management engine support for container groups in the current version.
There’s no manifest report for container groups in the current version.
Shipment manifest should be enabled if it is required to complete a manifest for the entire shipment packed at the packing station. This will normally be used when one consolidated manifest is required even though the shipment consists of multiple containers or container groups.
Manifesting is activated by the parameter Manifest requirement for shipment. If this is set to Manual, the shipment manifest will be included as a requirement in the packing workflow. It will not be possible to release any containers on the shipment before the manifesting is completed. If the parameter is set to Transportation management, the manifesting will still be performed through the TMS rate engines. Please note that this requires partners to implement a specific engine for the transportation provider and will not work out of the box in the current version.
If activating the Print packing slip parameter, the packing slip report will automatically be printed as part of the shipment manifest. The report can of course also be printed and reprinted on demand.
The first step for the warehouse worker is to log in the packing station. In the example below, we will log in the packing station at the location Pack.
Overall, the user interface for the packing station looks like the packing station in previous versions, but has several additions and workflow optimizations.
After the warehouse worker scans the shipment ID or the license plate identifying the shipment, the lines will be displayed and the packing of the shipment can be started.
The new Container packing policy is now applied when containers are created. Normally the same packing policy will be used for a single shipment or even for the entire packing station.
The Container group concept is introduced. This can be used if containers will be packed on a pallet and will be moved out of the packing station in one operation, instead of moving the individual containers.
Usually this field should be set up when starting to pack on a new pallet. The warehouse worker should scan the pallet license plate and it will work as a default container group for all new containers being packed and closed.
Please note that Container groups can only be used for containers that have a Container packing policy with delayed work creation.
It is possible to use an existing license plate, but if scanning a non-existing license plate, it will automatically be created.
License plates for containers that are already shipped should not be reused.
When closing the container, the default value will be used in the Close container dialog and it is possible to change it.
One way to add a container to a container group is through one of the containers forms, for example, Containers for shipment, Open containers at packing station, etc.
Both open and closed containers can be added to a container group. However, there are several restrictions when this can be done. For example: released containers can’t be added to a container group and containers from different shipments or different container packing policies can’t be added to the same container group.
Through the container forms, it is also possible to remove container from a container group by just clearing the Container group license plate ID field.
The shipment can now be packed in one or more containers. The first step is to create a new container with the selected Container packing profile.
The new container will be automatically selected in the Open containers view and packing can now be started. The view will also show the status of the container, for example, how much is packed, is the manifesting requirement met for the container, etc.
When an open container is selected, the warehouse worker will be able to start packing by scanning items using the Item packing section.
A new feature has been added so that it is now possible to pack everything on the selected open line by using the Pack button on the Action Pane. This will allow the warehouse worker to speed up packing shipments where it is not necessary to scan and pack individual items.
If the container is using a policy with manual container manifest requirements, the Manifest container dialog can be opened and the container weight and tracking number can be specified.
When the container is packed and any container manifest requirements are met, the warehouse worker can close the container. As the container is already manifested, it will no longer be possible to change the weight or the container tracking number.
If the container is using a policy with manual container manifest requirements and the policy parameter Automatic manifest at container close is enabled, the worker will be able be scan the container tracking number as part of the closing process.
If the container is not using a packing policy with container manifest requirements, the tracking number will not be displayed in the Close container dialog and the Manifest container button will not be enabled.
After the container is closed, follow the actions specified in the Container packing policy.
Delaying the release of the container can be very helpful in scenarios with or without work creation. In most situations, it would not be optimal to create work every time a container is closed, but rather wait until the entire shipment is packed. It can also be utilized when running without work creation and the containers are kept at the packing station until the truck arrives and the containers can be loaded.
Remember that an even more optimized work creation process can be achieved when using container groups for work creation container policies.
Please note that the old Close container form has been deprecated. In the case where it is needed to support the workflow where packing and closing take place in separate operations, the container closing should be performed on the Containers form.
If the container is not part of a container group and there’s no requirement for shipment manifesting, the container can be released as part of the container close.
Depending on the Container packing policy, one of the following actions will occur when releasing the container:
If the container is still open and manifested, it can be unmanifested from the Pack form. Containers cannot be unmanifested when they are closed or released.
If a Container group license plate is selected, the container group with the selected group license plate can be manifested using the Manifest container group button.
To manifest the container group, all manifest requirements for the containers in the group must be met and the containers must be closed.
When manifesting a container group, the following dialog will be shown and it is possible to specify the total gross weight and tracking number for the container group.
A container group cannot be unmanifested if the containers in the group are already released.
When the unmanifesting process is completed, the tracking number is removed from the container group and a confirmation message is displayed.
If a shipment is selected, the shipment can be manifested using the Manifest shipment button.
To manifest the shipment, all manifest requirements for the containers and the container groups in the shipment must be met and the containers must be closed.
When manifesting a shipment, the following dialog will be shown and it is possible to specify the total gross weight and tracking number for the shipment.
If a shipment is selected, the shipment can be unmanifested using the Unmanifest shipment button.
When the unmanifesting process is completed, the tracking number is removed from the shipment and a confirmation message is displayed.
There are different ways to view containers based on the context. When packing a shipment, it is useful to see containers that are part of the shipment.
The following form shows open, closed and released containers.
From this form, the packer can also perform all operations on containers such as closing, manifesting, reopening and releasing.
It is also possible to see all containers that are physically at the packing station. The Packing station form has buttons that can be used to view all open and closed containers at the packing station. These views will not be restricted to a specific shipment.
The views can be very helpful in the situation where one worker is packing the containers and the other worker is manifesting and releasing the containers.
Furthermore, a consolidated view of all containers is also available. This will mostly be useful for users working outside the context of a single packing station.
If the packing station is operating with a container packing policy with work creation, work will be created when the container is released as shown in the example below, where we are using a work template including staging.
If a container was released by mistake, it is possible to reopen it if the work is not started yet. If the warehouse worker reopens the container, the corresponding work will be cancelled.
If the other worker is cancelling the Packed container picking work, the corresponding container will also be reopened.
In scenarios where the container is already moved out of the packing station it is no longer possible to reopen the container by cancelling work. The container must be manually moved back to the packing station for reprocessing.
The Packed container picking work will be executed through the mobile device using menu items for packed container picking and packed container loading as showed in the example below.
The work that gets created for the container groups is very similar to the one for just one container.
You will notice a couple of differences: Target license plate ID is the same as the Container group license plate ID and not the Container ID. The work quantity is also created from all the containers in the group.
The work execution itself is also similar.
There are some additional possibilities with the container groups that are not available to individual containers. Namely, it is possible to remove a container from a container group if the container group is at a staging location.
To make this possible, there is a new warehouse mobile device menu item called Remove container from group.
By default, when a container is removed from the group, then the related Packed container picking work is updated to consider that the container group now has a different number of containers on it.
It is also possible to turn on the Cancel related work when removing container from group setting. If that is the case, then the related Packed container picking work gets canceled when the container is removed from the group.
This is how the removing container flow looks like.
For example, let’s take the container group from the above work. It has three containers.
If we click the Selected container, we can see which containers are going to be removed. Please notice that none of the containers are removed at this point and that it is possible to get out of the flow by clicking the Cancel button.
When the Remove containers button is selected, the flow ends.
This is how the work looks like now.
The removed containers are now at the staging location and can be moved freely.
In this section, we’ll describe how to set up multiple packing stations and use them for packing the same shipment. Of course, it is possible to use multiple packing stations for multiple shipments.
There are multiple ways to end up in a situation where there are items from the same shipment at different packing stations, for example, overriding the put location and selecting the Full button during sales order picking work, but we’ll describe one way to do it.
First, let’s set up the work template. To guide items to different packing stations, there should be multiple works. To accomplish this, we’ll break work by Item ID (and shipment, but that is not relevant for our case).
Setup of the work template query.
Setup of the work breaks.
Now, we need to set up the location directives.
We need to set up one location directive for the first item.
Location directive query.
Location directive action query.
The one for the other item is similar and it just filters for item A0002 and location Pack2.
If we now have a sales order with these two items and release it to warehouse, it will generate two work headers that will bring items to different packing stations.
The user can now proceed and pack the items at two different packing stations.
Currently, the interaction between the two packing stations is very limited. For example, it is not possible to move items between them even if the items belong to the same shipment. It is also not possible to add containers to container groups that are at different packing stations.
Also, after the container is closed and released, it is not possible to move the container back for repacking at a different packing station.
It’s important to notice that if the items are at the packing station, it is still possible to adjust items, leaving the container in an inconsistent state.