Scenarios

There are several usage scenarios in the inbound pick-and-drop process.

Imagine that the aisles in the warehouse that warehouse workers use to get to put-away locations are very narrow because companies want to save floor space and store as many items as possible. This often requires dedicated equipment and warehouse workers who are trained to operate in these aisles for both picking and put-away operations. In this situation, locations outside the aisles are created and served as both inbound and outbound pick-and-drop locations. If the production results in the fact that the produced items need to be put away in the evenings, production workers might move all items to the pick-and-drop location near aisles and leave them for the dedicated warehouse workers to put away.

The process is the same for received purchase orders. A receiving clerk picks the orders at receiving docks and move them to the pick-and-drop location where final put-away will be processed.

We will use the purchase order receiving as an example to show how to work with inbound pick-and-drop.

Next, we show how inbound pick-and-drop can be set up in Microsoft Dynamics 365 for Operations.

Set up inbound pick-and-drop

Setup scenario

Imagine this simple scenario: there are 3 aisles with 1 pick-and-drop location in each aisle. Note: This is a simplified scenario. Normally, there are several pick-and-drop locations in each aisle.

In the front of each aisle, there is a pick-and-drop location acting as the staging location for the aisle. Each staging location and the locations that it serves are defined as the members of the same zone. We will use the Zone ID from the Temporary Work Transaction table to differentiate work templates.

What we want to achieve is that a pick-and-drop location is selected per the selection of the final put-away location. So, we will create 3 zones and 3 fixed item locations for 3 different items, 1 item for each zone, and we will create 3 pick-and-drop staging locations, 1 staging location for each zone.

Note: You can use other filtering than fixed item locations, such as product groups or vendors, to set up items in 3 different zones.

We will create 3 different Location directives as well for put-away and they point to the staging locations that are associated with directive codes.

In total, we will have 3 work templates. Each work template has 1 zone and a dedicated staging pick-and-drop location.

Setup procedures

First, we create 3 locations for put-away in each zone and 3 dedicated staging pick-and-drop locations for each zone. Note: We can have many locations in each zone. This simple example just illustrates the process.

Next, we set up fixed locations for 3 items with 1 item in each location in each zone. This is not mandatory, but this is the way that we use to have items to be allocated to 3 different final locations in 3 different zones where we want to stage pick-and-drop locations prior to final put-away.

Next, we create 3 Location profiles that will be used in Location directives, but this is not mandatory. If the properties are the same, you can use 1 Location profile for all Location directives

Next, we create 3 different Directive codes that will be used to associate Work template and Location directives with dedicated staging pick-and-drop locations for each zone.

Next, we create 3 different zones to which we allocate the locations that we have created in the previous procedure.

Next, we create Location directives for each zone. We use Fixed location because we have fixed locations.

Next, we create 3 Location directives, 1 for each staging pick-and-drop location associated with a dedicated zone.

Next, we create 3 Work templates. Each template includes 2 pick-and-put steps. The Work templates are associated with location directives using the directive codes that we have created.

Next, see the following query setup for Work templates.

Next, we create a Purchase order for 3 different products. For each product, we set up a fixed location in one of the 3 zones that we have created.

After we receive the purchase order using barcode scanner, we can see that 3 Work IDs are created for 3 products. Each product has its own unique Work ID.

We can see that each item has two pick-and-put steps using their respective staging pick-and-drop locations.

Cumulative update 12 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 CU12, see the Dynamics AX In-Market Engineering blog. The build number for Cumulative Update 12 is 6.3.5000.138 and the knowledge base article is KB3199741.

In short, the following enhancements are now available:

• Work creation policies have been added to control whether work should be created for finished goods putaway and raw material picking.
• A warehouse worker can now cancel work using a mobile device.
• You can now reverse ship confirmations of loads, cancel packing slip updates for sales orders, and cancel product receipts for purchase orders.
• The Movement work creation menu item now has the option to show inventory status.
• It is now possible to merge license plates that are tied to work in staging area.
• Warehouse workers can now manually move inventory using a mobile device even if there’s work created for that inventory.
• It is now possible to change unit of measure during quantity confirmation when picking batch items.
• Improvements to the On-hand form with a new column showing available physical inventory on exact dimensions.
• There is now support to create invoice journals for transfer orders when freight is reconciled in transportation management.
• It is now possible to create a work exception with LP receiving for transfer orders.
• Performance improvements to location directive search.

The following table provides a list of feature enhancements made to WMS and TMS.

This blog provides an overview of the new inbound consignment inventory capabilities in Microsoft Dynamics 365 for Operations version 1611 (November 2016) release.

Overview

It is possible to have consignment inventory owned by a vendor but stored at your site. When you’re ready to consume or use the inventory, you take over ownership of the inventory.

This blog post includes information about:

• How to physically receive vendor-owned on‑hand inventory without creating general ledger transactions.
• How to start a production process where the vendor-owned inventory can be physically reserved.
• How to change the ownership of the raw material so that you can process the consumption as part of production order processing.
• There is also some information about how vendors can monitor consumption of their inventory by using the vendor collaboration interface.

By reading this this blog post, you will learn how to:

• Enable inbound consignment inventory by associating an inventory owner dimension value with a vendor account.
• Create a consignment replenishment order header and line to record and process inbound vendor-owned inventory.
• Physically receive vendor-owned on‑hand inventory.
• Monitor inventory cost values when you have on‑hand inventory that is owned by both your own company and the vendor.
• See which on‑hand inventory is owned by you, and which is owned by the vendor.
• Initialize a production order with lines that are physically reserved/picked against vendor-owned on‑hand inventory.
• Process an ownership change journal that is linked to a production, to record the change of ownership of the inventory from the vendor to the current legal entity.
• Monitor the consumed inventory that external vendors must invoice your company for.
• Adjust vendor-owned on‑hand inventory by using counting processes.
• Transfer vendor-owned inventory between storage dimensions.

The demo data company USMF is used for this blog post.

The materials manager (Karl) associates an existing vendor with an inventory owner dimension value.

To track the ownership of the on-hand inventory, it is possible to associate a vendor account with an inventory owner dimension value from the page:

Inventory management > Setup > Dimensions > Inventory owners

It is possible to add a vendor account to the list. The Owner value can be updated to a value that differs from the vendor account number in case you would like to track it differently within the inventory dimension values. The Owner value will be shown to the vendor in the vendor collaboration interface.

Note: The current legal entity owner is created automatically. In this case, the owner dimension value is USMF for all processes that are not related to consignment inventory.

The product designer (Emil) creates a new tracking dimension group and raw material product for consignment inventory.

Click Product information management > Setup > Dimension and variant groups > Tracking dimension groups.

Search for an existing Owner tracking dimension group, or create a new Tracking dimension group that has the Owner tracking dimension set to Active.

When the Tracking dimension group gets assigned to a released product, it will be possible to track the ownership of the on-hand inventory.

Only Items using Standard cost or Moving average costing methods are supported using the Owner dimension.

The purchasing agent (Alicia) manually creates a consignment replenishment order.

Procurement and sourcing > Consignment > Consignment replenishment orders

A new consignment replenishment order has been enabled to record and process inbound consignment inventory.

The order has a very simple UI with header and lines.

As for the purchase order, the consignment replenishment order lines will create expected inventory transactions and the owner dimension value will automatically be assigned based on the linked value related to the vendor account.

The receiving clerk (Sammy)/purchasing agent (Alicia) performs product receipt against the consignment replenishment order.

To get the vendor-owned inventory physically updated, a registration (either via arrival journal or inventory registration) can be processed.

To get the order and inventory transactions into the final state, run the Product receipt update from the consignment replenishment order.

Note: An External product receipt value isn’t required during the product receipt update process. An Internal product receipt number will be used for tracing.

The order status (header/lines) will be updated to Completed as soon as all quantities gets updated.

The inventory accountant (Cassie) monitors the inventory values and cost objects.

It is important to understand that during the consignment replenishment order product receipt process, no cost value will be recorded, and no general ledger transactions will be created.

This means that all inventory statements and KPIs will show values as 0 (zero).

No Inventory value will exist because the on-hand inventory is not owned by the current legal entity USMF.

The external vendor (Erin) monitors on-hand consignment inventory.

On the Vendor collaboration page, it is possible to monitor the on-hand inventory information related to consignment inventory.

Vendor collaboration > Consignment inventory > On‑hand consignment inventory.

An external user will be able to monitor on-hand inventory for several vendor accounts (inventory owners) depending on setup.

The shop supervisor (Lars) initializes the production.

The production line inventory transactions can become reserved and even updated to the status Picked and having the owner dimension value different from the current legal entity. When reserving, the on-hand inventory owned by the current legal entity will take precedence over the vendor-owned inventory.

The materials manager (Karl) processes an inventory ownership change based on production lines.

Inventory management > Journal entries > Items > Inventory ownership change

To record an inventory ownership change, a new journal has been enabled.

The journal lines can be manually entered or created based on a query linked to production lines.

It is only possible to change the owner dimension value that equals the current legal entity.

When posting the journal, the vendor-owned on-hand inventory will be issued out via an ownership change transaction reference and received on the current legal entity (USMF) dimension value via a Purchase order process. The inbound transactions will become product receipt updated (Received) and the price calculations can be based on the Item prices or Trade agreements.

The purchase order lines created based on the consignment process will have the Origin = Consignment.

From the Purchase order line, it will be possible to view the related ownership change transactions, and from the Inventory ownership change journal lines, it will be possible to see the related production line transactions.

As it can be seen from the above screenshot, the inventory ownership change process automatically updated the Issue field with Reserved physically and Picked and the Owner dimension value is updated to USMF.

Therefore, the production flow can continue for the raw material, so that the material can become consumed and put into WIP.

The external vendor (Erin) monitors the consumption of material.

The external vendor can monitor the consignment inventory ownership updates via the page Vendor collaboration > Consignment inventory > Products received from consignment inventory.

The vendor can also see detailed information about the expected invoicing process by viewing the purchase order information.

The warehouse manager (Ellen) creates an on-hand counting journal for vendor-owned on-hand inventory.

In addition to the Consignment replenishment order, the vendor-owned on-hand inventory can be recorded via a counting process. Note: The data connector can be used to create and update counting lines.

The warehouse worker (John) transfers vendor-owner inventory to production.

In case the vendor-owned inventory needs to be registered and transferred to another storage dimension, for example another location, the Transfer journal can be used.

More information.

For more information, see Demo script for Inbound consignment inventory (Requires access to PartnerSource).

Dynamics 365 for Operations 1611 – Improved packing functionality

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:

• Setup experience is better aligned with the rest of Warehouse management.
• The packing station is now seen as a location. When the warehouse workers are logging in at the packing station, they will only see and operate on shipments and containers that are planned at the specific packing location.
• Work can now be generated to bring goods from the packing station to the staging and bay door locations.
• The concept of container groups has been introduced to allow multiple containers to be moved out of the packing station in one operation.
• A new packing policy has been introduced to give warehouse managers greater flexibility in how containers should be handled in the packing process.
• The concept of manual manifesting has been introduced to allow a loosely coupled integration to external transportation provider systems.
• The user experience for packing and container processing has been improved.

Upgrade from Dynamics AX 2012

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

• All containers must be closed before upgrade. In previous versions, containers did not have a container packing policy assigned on creation. In the current version and going forward, container packing policy must be assigned to containers to process containers. This can be mitigated by using the Change container packing policy function on the Container form, but it is not a recommended approach.
• In the current version and going forward, it is required that the locations that operate as packing stations must be LP controlled. If the packing station is not LP controlled, it is not possible to process containers after upgrade.
• Before using the newly upgraded system, make sure that the right container packing policies have been defined and are associated with the correct packing profiles.

Define location profiles and packing locations

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:

• Use license plate tracking must be set to Yes.
• Allow negative inventory should be set to No.
• Allow mixed items should be set to Yes.
• Allow mixed inventory statuses should be set to Yes.
• Allow mixed inventory batches should be set to Yes.

Set up the locations that operate as packing stations to use the new packing location profile ID.

Use location directives to bring goods to the packing station

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.

Log in the packing station

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.

Set up container packing policies

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.

Container release policy

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:

• Make available at final shipping location. This is the same as in the previous versions. As soon as the container is released, it is updated to the specified location for the final shipping location. When using this option, the field Default location for final shipment is enabled and used for specifying a preferred location for the container after closing it.
• Create work to move container from packing station. Using this option will create work for moving the container from the packing station to the staging area or directly to the bay door. When using this option, the field Work template is enabled and can be used for specifying a work template that should be applied when creating the work for the container.

Work template

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.

Container closing policy

By using this parameter, it is possible to define what should happen when closing the container by specifying one of the following options:

• Automatic release. The container will be considered released from the packing station and the action specified under the Container release policy will be triggered.
• Delayed release. The container will not be released from the packing station immediately. It will be up to the warehouse worker to release it at a later point in time.
• Optional. During the process of closing the container, it will be possible to choose whether the container should be released at the closing time.

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.

Weight unit

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

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:

• All containers must be manifested before container group is manifested.
• All container groups must be manifested before shipment is manifested.

Manifesting will be described in more details when the workflow of the packing station is explained.

Container manifest

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 manifest

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

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.

Packing station workflow

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.

Prepare for packing

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.

Container packing policy

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.

Container group license plate ID

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.

Pack the shipment

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.

Manifest the container

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.

Close the container

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.

• If the policy parameter Container closing policy is set to Automatic release, the container will immediately be released when the container is closed.
• If the policy parameter Container closing policy is set to Delayed release, the container will be closed, but will be pending until released by the warehouse worker.
• If the policy parameter Container closing policy is set to Optional, the container will be closed and the worker can decide to release it as part of closing the container.

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.

Release the container

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 policy parameter Container release policy is set to Make available at final shipping location, the container will immediately be available at the specified location when the container is closed.
• If the policy parameter Container release policy is set to Create work to move container from packing station, work will be created for moving the container out of the packing station.

Unmanifest 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.

Container group manifesting

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.

Unmanifest container group

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.

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.

Manifest shipment

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.

Unmanifest 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.

View containers

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.

Work creation

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.

Work cancellation

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.

Work execution

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.

Packed container picking

Packed container loading

Work creation and possibilities for container groups

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.

Use multiple packing stations

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.

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:

• A tailored interface designed for fast warehouse scanning
• Supports over 40 different warehouse processes
• Custom built on-screen numeric keypad for you to hit numbers easily
• A simple calculator for you to enter and calculate quantities in a breeze
• Possibility to adjust font size and width of input fields on any device

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.

Prerequisites

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.

Install the app

The app is available for download here:

• Windows (UWP) – Dynamics 365 for Operations – Warehousing on the Windows Store
• Android – Dynamics 365 for Operations – Warehousing on the Google Play Store

For detailed steps on how to install and configure the app, refer to this tutorial: Install and configure Dynamics 365 for Operations – Warehousing. 

Navigating the app

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.

Log-in screen and menu

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.

Task and details page

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.

Numeric keypad

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.

Multiple input fields

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.

Action pane

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.

Settings in Dynamics 365 for Operations

There are two new pages added in Dynamics 365 for Operations:

• Warehouse management > Setup > Mobile device > Warehouse app field names
• Warehouse management > Setup > Mobile device > Warehouse app field priorities

I will explain below the use of these pages, and how they relate to the app.

Configure warehouse app field names

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:

• Preferred input mode – This option defines whether a scanning field or a manual entry input field should be shown for the selected field name. This is useful to distinguish fields depending on if barcodes are used for the field or not. Note: Field names with preferred input mode set to Scanning can still enter information manually in case the barcode is unreadable or damaged.
• Input type – This option defines what input type should be used for the selected field name. Four options are available:
  • Selection – The selection list is used for field names that contain a list of options to choose from. This option is not editable, and can only be change through extension.
  • Date – Field names specified as date will show a date format with the label, to help warehouse workers know which format to enter the date in. This option is not editable, and can only be changed through extension.
  • Alpha – If Alpha is selected, the device keyboard will be used when entering information manually in the app. The keyboard experience can change depending on the device used.
  • Numeric – For field names that you know will use numeric input only, you can select this option to display a custom numeric keypad with the input field instead of the device keyboard.

Configure warehouse app field priority

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.

Summary

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.

Concepts

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.

Create a requisition line and set up initial financial dimensions values

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:

1. Project
2. Requester
3. Vendor
4. Item

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.

Manually update the financial dimension on a 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 non-stocked items and lines not referring to a catalog item – Setting a financial dimension value to blank on the requisition line will not update the accounting distribution.
• For stocked items and fixed assets – Setting a financial dimension value to blank on the requisition line will update the accounting distribution by removing the dimension.

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.

Update a vendor or project

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.

Example

Set up the following default values.

Create a requisition line for a non-catalog item.

Use a template to update the accounting distribution

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.

Introduction

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.

WMDP vs Dynamics 365 for Warehousing Mobile App

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.

Customizing the new Dynamics 365 for Warehousing Mobile App

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:

WHSWorkExecuteMode and WHSWorkActivity Enumerations

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:

WHSWorkExecuteDisplay class

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:

[WHSWorkExecuteMode(WHSWorkExecuteMode::WeighContainer)]
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:

[WHSWorkExecuteMode(WHSWorkExecuteMode::WeighContainer)]
class conWhsWorkExecuteDisplayContainerWeight extends WhsWorkExecuteDisplay
{
    container displayForm(container _con, str _buttonClicked = '')
    {
        container    ret = connull();
        container    con = _con;

        pass = WHSRFPassthrough::create(conPeek(_con, #PassthroughInfo));

        if (this.hasError(_con))
        {
            con = conDel(con, #ControlsStart, 1);
        }

        switch (step)
        {
            case conWeighContainerStep::ScanContainerId:
                ret = this.getContainerStep(ret);
                break;

            case conWeighContainerStep::EnterWeight:
                ret = this.getWeightStep(ret, con);
                break;

            case conWeighContainerStep::ProcessWeight:
                ret = this.processWeightStep(ret, con);
                break;

            default:
                break;
        }

        ret = this.updateModeStepPass(ret, WHSWorkExecuteMode::WeighContainer, step, pass);

        return ret;
    }
}

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;

    return _ret;
}

container buildGetContainerId(container _con)
{
    container 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)];

    return ret;
}

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:

class conWHSControls
{
    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.

New Fields

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:

[WhsControlFactory('ContainerId')]
class conWhsControlContainerId extends WhsControl
{
    public boolean process()
    {
        if (!super())
        {
            return false;
        }

        fieldValues.insert(conWHSControls::ContainerId, this.data);

        return true;
    }
}

[WHSFieldEDT(extendedTypeStr(WHSContainerId))]
class conWHSFieldContainerId extends WHSField
{
    private const WHSFieldClassName Name = "@WAX1422";
    private const WHSFieldDisplayPriority  Priority    = 65;
    private const WHSFieldDisplayPriority  SubPriority = 10;
    private const WHSFieldInputMode InputMode = WHSFieldInputMode::Scanning;
    private const WHSFieldInputType InputType = WHSFieldInputType::Alpha;

    protected void initValues()
    {
        this.defaultName = Name;
        this.defaultPriority = Priority;
        this.defaultSubPriority = SubPriority;
        this.defaultInputMode = InputMode;
        this.defaultInputType = 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 <= 0)
        {
            return this.fail("@WAX1172");
        }

        if (mode == WHSWorkExecuteMode::Movement && WHSRFMenuItemTable::find(pass.lookup(#MenuItem)).RFDisplayStatus)
        {
            controlData.parmFromInventStatusId(controlData.parmInventoryStatusSelectedOnControl());
        }
        else
        {
            controlData.parmFromInventStatusId(controlData.getInventStatusId());
        }

        if (!super())
        {
            return false;
        }

        if (mode == WHSWorkExecuteMode::Movement && fieldValues.exists(#Qty))
        {
            pass.parmQty(qty ? data : '');
        }
        else
        {
            fieldValues.parmQty(qty ? data : '');
        }

        //When 'Display inventory status' flag is unchecked, need the logic for #FromInventoryStatus and #InventoryStatusId
        this.populateDataForMovementByTemplate();

        return true;
    }

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.

Error Display

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)
…
ttsBegin;
containerTable = WHSContainerTable::findByContainerId(pass.lookupStr(conWHSControls::ContainerId),true);
if(containerTable)
{
    containerTable.Weight = pass.lookupNum(conWHSControls::Weight);
    containerTable.update();
    _ret = conNull();
    _ret = this.addErrorLabel(_ret, 'Weight saved', WHSRFColorText::Success);
    pass.remove(conWHSControls::ContainerId);
    _ret = this.getContainerStep(_ret);
}
else
{
    _ret = conNull();
    _ret = this.addErrorLabel(_ret, 'Invalid ContainerId', WHSRFColorText::Error);
    pass.remove(conWHSControls::ContainerId);
    _ret = this.getContainerStep(_ret);
}
ttsCommit;

Caching

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.

Conclusion

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 2017 release of Dynamics 365 for Finance and Operations or later.

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!

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.

• Packed goods can now be brought from the packing station to the staging area or loaded directly on a truck.
• Ability to move one item or the entire license plate (LP) although there is replenishment work behind.
• Transfer order receiving and returns are now enabled as part of Mixed pallet receiving.
• Guided partial cycle counting at a location has been enabled.
• Short picking - Inventory reallocation. Ability to pick items from another location in short picking scenarios.
• Use the demand replenishment method in the raw material picking process.
• Correct reservation status after re-marking of WHS items with the Storage dimension enabled.
• Timing of planned production orders when overlap jobs are enabled and the route operations use different calendars.
• Product confirmation requested by the system before a put is completed.
• Ability to report consumption of staged and order picked material.
• Plan purchase orders through TMS in an inbound process when using Change management.
• Pick (other) work order lines even if one of the order lines is blocked by demand replenishment.
• RAF\Transfer Order integration. Finished goods can be cross docked to bay door locations providing an alternative to the put-away process where finished goods from the production output would normally be put in the Finished goods put location.
• With a maximum weight or volume on the work template, the work split is now based on the directive unit and not on the lowest unit of measure.

Key concepts

Inventory dimension

An inventory dimension can have a Physical value and a Financial value. The setting of the Physical value controls whether a dimension is active for Inventory management and Warehouse management. The setting of the Financial value controls whether a dimension is active for Inventory accounting in Cost management.

Note: An inventory dimension can have an active Physical value but no Financial value. However, it can’t have an active Financial value but no Physical value.

Cost object

The term cost object was introduced in Microsoft Dynamics 365 for Finance and Operations, Enterprise edition. It represents a key concept that is used in the management of business costs. A cost object is an entity that costs and quantities accumulated for. For example, a cost object entity can be either a product or product variants, such as variants for style and color.

A cost object is derived from the item ID and the inventory dimensions that have an active Financial value.

There are three groups of inventory dimensions: product, storage, and tracking. Each inventory dimension can have a set of dimensions associated with it. For each dimension, you can set up the following inventory dimension values.

Example: Define a cost object

When an item is created, a set of inventory dimension groups can be assigned to it. The following table shows how you can define a cost object.

In the following example, the cost objects are defined by Item + Color + Site.

Examples:

• Speaker + Black + Site 1
• Speaker + White + Site 1
• Speaker + Black + Site 2

The inventory objects can be used to report the physical quantity at any level in the warehouse that is defined by Item + Color + Site + Warehouse.

Examples:

• Speaker + Black + Site 1 + WH 11
• Speaker + Black + Site 1 + WH 12
• Speaker + White + Site 1 + WH12

It’s crucial that you understand the concepts. The configuration and implementation of these concepts have a significant impact on the whole system, especially in Inventory management and Cost management.

After the configuration is implemented, it’s almost irreversible. Any change will require significant resources and will affect system usage itself.

In the rest of the document, we will use the Speaker item as an example. The inventory valuation method is set to Moving average.

Cost object:

• Speaker + Black + Site 1

Inventory objects:

• Speaker + Black + Site 1 + WH 11
• Speaker + Black + Site 1 + WH 12

After a few transactions have been posted, the following inventory transaction entries are generated in the Inventory subledger.

The inventory close job was run as of January 31, 2017. Because the inventory valuation method was Moving average, no adjustments were posted.

As part of the fiscal period–end process, an Inventory value report that shows the ending inventory balance in quantity and value is required. To meet this requirement, the inventory value report framework was introduced. The framework lets you create custom reports by including more data points that depend on the type of business. It also lets you define the level of aggregation for cost objects.

Note: The inventory value report is designed to print only the values per cost object or aggregations of cost objects.

You create an Inventory by cost object report, based on the configuration in the following table.

The report will look like this.

Note: The Warehouse column will remain blank, because the Speaker item doesn’t have any cost object that includes the Warehouse dimension. Inventory dimension Warehouse is only set to Physical.

View the inventory value by physical location Warehouse

Configure the storage dimension group

To meet the customer’s request, you could configure the storage dimension group differently. In this case, the Warehouse dimension is configured so that it has a Financial value.

This configuration affects how the Speaker item is handled by the system. The cost object and inventory object now have the same level of granularity.

Cost objects:

• Speaker + Black + Site 1 + WH 11
• Speaker + Black + Site 1 + WH 12

Inventory objects:

• Speaker + Black + Site 1 + WH 11
• Speaker + Black + Site 1 + WH 12

The configuration also directly affects the inventory valuation. In this example, the FIFO, Weighted average, or Moving average inventory valuation method will be applied per cost object, and the overall result will differ.

The result will also differ when the Inventory value report is run by using the same configuration that is described in the previous section.

The Warehouse column now has a value, and the inventory value is 26.00 instead of 24.00.

Note: When you activate the Financial value for the Warehouse inventory dimension, you might affect performance. All transfers between warehouses are now considered financial movements, and financial movements can cause cycles in the Inventory close job. If the Warehouse inventory dimension is used only to physically track inventory, these will be closed as non-financial transfers before the cost calculation begins and the changes of cycles reduced.

Create a custom report that looks at inventory transactions and settlements.

You can create a custom report that sums inventory transactions and settlements by InventDim ID.

The old Physical inventory by inventory dimension report was designed for that purpose. In the report dialog box, users could select any inventory dimensions, regardless of whether they were part of the defined cost objects.

This approach works, provided that the inventory dimensions that you select are part of the defined cost object. However, if you select an inventory dimension that isn’t part of the cost object, the report starts to print incorrect results.

The following table shows the result of printing balances per item and inventory dimensions.

Note: The inventory cost is calculated at a level above the inventory dimension and warehouse. Therefore, the cost on issue transaction from warehouse WH11 explains why the inventory value per warehouse can become negative.

Report the value of physical locations

If the value of a physical location must be reported, a sum of transactions per location, as described in the previous section, isn’t the solution.

The correct approach is to calculate the value per location by using the following simple formula:

Value = Cost object, cost × physical object, quantity

Cost object:

• Speaker + Black + Site 1

Inventory objects:

• Speaker + Black + Site 1 + WH 11
• Speaker + Black + Site 1 + WH 12

In Microsoft Dynamics AX 2012 R3, a new report that is named Inventory aging was introduced. As the name of the report implies, this report does more than just report the value by physical location. It can also show the age of the current inventory in the user-defined buckets.

In the report dialog box, enter the following information.

The following table shows only the first section of the Inventory aging report, but the user-defined buckets have been omitted.

Conclusion

If your organization must provide inventory value by any physical location, you don’t have to update the current configuration of inventory dimension groups. This change can be very intrusive, and also affects the cost calculation and performance. We also don’t recommend that you build a custom report for this purpose.

The Inventory aging report is designed to calculate the cost per cost object and then can apply it to any physical level that is selected on the report. This report is designed to automatically detect the level that the cost object is defined at per item. It then applies the formula to calculate the value by physical location.

Allowing physical negative inventory may have undesirable consequences in inventory accounting, especially if the inventory costing principle is Actual and the valuation method is either FIFO or Weighted average.

Most of the issues that are related to physical negative inventory can be mitigated by using the correct configuration and maintenance of data.

Example: Why is the cost out of sync?

The following table lists the required setup for the Item model groups.

The purchase from the supplier always takes place at a unit cost of 7,500.00.

The following table lists the events as they occur, in chronological order.

The system starts issuing from inventory at cost per unit of 18,750.00 even though the cost of purchase has not exceeded 7,500.00.

Why does this happen?

In order to explain this in better detail, let’s add a few more columns on the rightmost side, in green. These new columns represent the inventory balance after posting the specific transaction. The inventory balance is also known as InventSum.

Notes:

1. The Cost per unit is 0.00. When the balance is negative, the system looks for a fallback cost to apply.
   1. First, the system looks for an active cost. This fails.
   2. Second, the system looks for cost set up in the Cost price field in the item master record. The cost is equal to 00.
2. The Cost per unit is 7,500.00. The balance is still negative. The system looks for a fallback cost to apply.
   1. The system looks for an active cost. This succeeds.
   2. The latest cost price was set to Yes on the item record. The prior Purchase order unit cost of 7,500.00 has now become the active cost.
3. The same condition applies as in number 2.
4. The Cost per unit is 18,750.00. If the balance is positive at the time of posting the issue transaction, the system applies the average cost of the balance.
   500.  Average cost is calculated as: 37,500.00 / 2.00 = 18,750.00

The issue is that the inventory balance of 1 piece at 18,750.00 is overvalued because the item has never been purchased at a cost higher than 7,500.00. The reason for this overvaluation is that the first issue transaction leaves inventory at a cost per unit of 0.00. The wrong cost estimation will continue to ripple through the following transactions.

The only way to get the inventory balance back in sync is to run either the Recalculation or Inventory close jobs.

The Inventory close will apply the selected Inventory model, in which case is FIFO, and then adjust the cost on the issue transactions accordingly.

Note: If the inventory balance is negative when executing the inventory close, the balance will not be adjusted. A full adjustment can only occur when the balance is positive, and enough receipts exist that can adjust the issues.

Conclusion

By default, all items should have an active cost. If you plan to allow temporary physical negative inventory, which is a valid scenario in certain business, it’s essential to apply an active cost before creating any transactions on the item.

Introduction

This blog describes the new capabilities that allow you to migrate existing items with open inventory transactions so they can use the new storage dimensions. This can be needed when you upgrade from older versions of Microsoft Dynamics 365 for Finance and Operations that supported the pallet dimension or if you want to use the Warehouse management functionality for existing items that were previously using WMS1 processes.

Typical migration scenarios:

• You have existing items with the location dimensions enabled.
• You have existing items with the location dimensions enabled and the pallet dimensions active.
• You have existing items with the location enabled which are catch-weight items.

The goal when migrating items to use warehouse management enabled processes

The following setup is required to use an item in warehouse management processes:

1. The item must use a storage dimension group that is set up to use warehouse management processes which means that the Inventory status dimension, the location and the license plate must be active.
2. A reservation hierarchy must be assigned.
3. A unit sequence group must be assigned.

The goal of the migration is to enable the items to meet the above  criteria and ensure that all related data is consistent with the items’ new settings allowing business processes to proceed after the migration.

High-level overview of the process

The upgrade process – blocking items

If you upgrade from a version that supported pallets the upgrade will identify the items that had the pallet dimension active and create a record in a new table called InventUpdateBlockedItem. This is done to block the items from all inventory processes because the item is configured using unsupported settings.

Items that are blocked must be migrated. The blocked items can be viewed in the Items blocked for inventory updates form.

The migration cockpit Change storage dimension group for items

The migration cockpit is simple. It allows you to enter the item ID of the items you want to be migrated and the new storage dimension group. If the item is to be downgraded from a group with the pallet dimension active, this is all you need.

If the item should be converted to use warehouse management enabled processes, you need to assign a reservation hierarchy and a unit sequence group.

The illustration below is a screenshot of the form.

Using entities to populate the data

You can use both OData which allows you to use Excel directly and data management to import and export the data.

OData

You can use the OData approach by clicking the Open in Microsoft Office icon and export the data to Excel. Once the information has been entered, the changes can be synchronized back.

Data management

For larger datasets, data management is the most effective. The entity is called Item storage dimension group change request and follows normal data management patterns.

Validation

Before the migration is started, the validation should be performed to ensure that the data is ready for migration. Several conditions are validated:

• A default inventory status value must be defined
• Inventory on-hand on pallets must not exist on non-license-plate-tracked locations
• Inventory on-hand without pallets must not exists on license-plate-tracked locations
• That the combination of the selected storage dimension group and reservation hierarchy is valid
• If migrating to use warehouse management processes, the item cannot be enabled with catch weight

The list is not exhaustive, but it covers the most important validation points.

Starting the migration

The migration is started by clicking the Process changes button.

The migration supports parallel processing for parts of the process. The batch framework is used and the different steps will be handled by different batch tasks.

The recommendation is to set the Recommended number of parallel tasks field to two times the number of cores that are available. It is recommended to have a dedicated batch server for the migration since the migration is a heavy process due to the updates to the inventory dimensions.

Un-supported scenarios

Catch weight enabled items:  Catch weight enabled items are not supported in the new WHS. If such items exist, and they have the pallet dimension active, they will need to be downgraded to a dimensions group where only the location is active., Otherwise an ISV solution should be used.

Reserve Ordered transactions: Because of the way reservations work for warehouse management enabled items there are certain constraints on the state of the inventory transactions. If there are Reserved ordered transactions with a “hole” in the dimensions, the item cannot be converted.

A “hole” could exist for an item that has the batch dimension active and has the batch placed below the location in the reservation hierarchy. If a reservation exists on site, warehouse, batch, then the location is missing, which is what we refer to as a “hole”. This is not supported.

The mitigation is to either assign the missing dimensions or clear the dimensions so the “hole” is removed.

Customization that involves inventory dimensions

If you have customizations related to inventory dimensions that fall in one of these two categories:

• New inventory dimensions field on existing table
• New table with and inventory dimensions

You need to do something before you can use the migration process. Otherwise you will get an error like the one below:

Since a new inventory dimensions field exists, the system needs to know what actions should be taken for the dimensions in the table. This is done by implementing an event handler.

Three situations where an inventory dimension field is added:

1. You do not want the data updated
2. You want the data updated and the table has the itemId on it
3. You want the data updated but the table does not have the itemId on it

In the below examples we will assume that we have added a table looking like this:

Handling situation 1 and 2

The below eventhandler illustrates how an eventhandler for situation 1 and 2 can be implemented. Here we want to update the dimensions related to the InventDimIdAllDimensions but not the dimensions in InventDimIdOnlyProductDimensions

[SubscribesTo(classStr(InventItemInventoryDimensionConversionTaskInitiator), delegateStr(InventItemInventoryDimensionConversionTaskInitiator, tableWithInventDimIdDiscoveredDelegate))]
    public static void tableWithInventDimIdDiscoveredStorageConversionDelegateHandler(
        TableId _updateTableTableId,
        FieldId _inventDimIdFieldId,
        InventItemInventoryDimensionConversionType _conversionType,
        EventHandlerResult _result)
    {
        if (_updateTableTableId == tableNum(MyOwnTableWithInventDimId))        {
            
            if (_inventDimIdFieldId == fieldNum(MyOwnTableWithInventDimId, InventDimIdAllDimensions))
            {
                InventItemInventoryDimensionConversionTaskCreator creator = InventItemInventoryDimensionConversionTaskCreator::newStorageConversion();
                creator.createTasksForTableWithItemId(
                    _updateTableTableId, //tableId of the table that should be updated
                    _inventDimIdFieldId, //fieldId of the inventDimId field that should be updated
                    fieldNum(MyOwnTableWithInventDimId, ItemId),  //fieldId of ItemId field
                    fieldNum(MyOwnTableWithInventDimId, DataAreaId)); //field id of DataAreaId
                _result.booleanResult(true); //we need to update
            }
            else if (_inventDimIdFieldId == fieldNum(MyOwnTableWithInventDimId, InventDimIdOnlyProductDimensions))
            {
                _result.booleanResult(false); //no update needed
            }
        }

Handling situation 3

Situation 3 is different since the itemId is on a different table. Here we need to write code specifically to the datamodel for the involved tables. The best approach is to follow the existing examples in the code. The InventBatchJournalResult table is a good example. This table is more complex because it has an InventDimId, but the itemId is on the inventBatchJournal table. The code below shows how this scenario is handled.

public class InventItemInventDimConversionInventBatchJournalLinePopulationTaskProcessor implements InventItemInventoryDimensionConversionITaskProcessor
{
    public boolean process(InventItemInventoryDimensionConversionTask _conversionTask)
    {
        var queryBuilder = InventItemInventoryDimensionChangePopulatorItemIdTableJoinedQueryBuilder::newFromParameters(
            _conversionTask.UpdateTableName,
            _conversionTask.InventDimIdFieldId,
            _conversionTask.DataAreaIdFieldId,
            tableStr(InventBatchJournal),
            fieldNum(InventBatchJournal, ItemId));

        InventItemInventoryDimensionChangePopulator::newFromQueryBuilder(queryBuilder).populateDimensionChanges();

        return true;
    }

}

Additional information

You can find more information as part of the product documentation:

https://docs.microsoft.com/en-us/dynamics365/unified-operations/supply-chain/warehousing/upgrade-migration-warehouse-management-processes

Introduction

This is another blog post in the series about warehouse mobile devices in Dynamics 365 for Finance and Operations. In the last blog post, the difference between customizing for WMDP and the warehouse mobile app was discussed. This blog post will be walking you through a new control scheme that was recently released, explaining how it unlocks new potential for partial offline processing in the warehouse mobile app.  This new functionality is called “multi-scan” and it enables a user to perform a series of offline scanning operations and then return them all to the server in one round trip operation. The goal for this control scheme is to allow for very quick scanning operations (many scans per second as an example) in high transactional warehouses where the standard model of a server round trip after each scan will not scale. Especially in sequential operations where the user does not need to look and verify on the device after each scan, but rather just need to register all scans in one go.

Multi-scan Functionality

If you download the latest version of the warehouse mobile app, you will have some new capabilities in the demo-mode which shows how this new control pattern works.  Once you have enabled the demo mode you should see the following menu:

Cycle counting is the flow we have enabled in the demo with multi-scanning to demonstrate the new capabilities.  It is designed to simulate a user performing a spot cycle count at a location in a warehouse or retail store where there are many items to scan. Currently this in only available in demo mode of the app, there is no support for this functionality when connected to a Dynamics 365 for Finance and Operations environment.

The first screen that is displayed is a location scanning screen – you can enter (or scan) anything in the demo mode here to move to the next screen.

Once you have scanned the location, the app enters the multi-scanning mode.  This is the new control that is being introduced in this release, so let’s go through the different UI elements that have been introduced to support this new flow.

This is the initial screen – you can tell it is the multi-scanning interface because of the new list icon in the bottom left corner; clicking the list icon will show you the list of items you have scanned so far. The checkbox icon in the bottom right is used to report to the app that you are done scanning and it is the only time the processing returns to Dynamics 365 – everything else will take place within the app locally on the device.

Once a worker starts to scan barcodes (or enter data manually into the app) the UI will change slightly.  Every item scanned will be added to an internal buffer and the number of items scanned will be displayed in the main UI.  For example – after a few scans the UI will now display the scanned count of three:

At any time, the user can click the list icon in the lower left, which will then display the list of items that have been scanned (in this example perhaps product barcodes in the location).  The UI for this looks like the following:

This lists the barcodes that have been scanned as well as a count of the times they have been scanned by the user.  This is very useful in the counting scenario, as a user can simply scan each product’s barcode to generate a count of items at that location.

You might note that there are two disabled buttons at the bottom of the screen.  These become active when a row is selected by the user in the list – as you can see below:

The edit icon on the left allows you to manually change the number of scans for the selected row. The icon on the right with the “X” deletes the selected row in case something was scanned accidentally.  

The edit icon will open a new screen with the numeric stepper UI allowing the user to quickly increment or decrement the number of scans or click on the value to open the numeric keyboard:

When clicking on the value, the numeric keyboard will open. As the number of barcodes cannot be negative, or integers, buttons that aren’t relevant for this use case has been disabled:

Returning to the main screen (by clicking the back button in the upper left corner) we are ready to submit the scanned list of items and their counts to the server. We do this by clicking the checkbox button in the bottom right – this is when we finally make the round-trip to the server and communicate with Dynamics 365. Later in the blog post the API will be explained and how to consume the scanned items and their quantities in X++ code.

In the demo flow, the next screen that is displayed is the following list of items which are not present in the location:

This is the second control pattern that we have introduced as part of this release – it allows a workflow to display a list of items (for example barcodes or product UPCs) and then allow the user to “scan to remove” from the list.  In this demo example we are displaying the items that were found in the cycle count but are not currently registered as on-hand for this location; the intention is that the warehouse worker would double check this list and scan any items that were indeed found as an extra validation check.  Scanning “T0001” in the above screen would then remove this from the list – and remember that this is all done client-side at this point. It is also possible to click on any value in the list and remove it.  Then when the user clicks that checkbox/submit button the new list of items would be submitted to the server for processing through a X++ workflow.

Custom Workflow

Hopefully that walkthrough gives you some idea of the capabilities we have added with these two new client-side control screens.  It is important to know that we have not currently added any multi-scan capabilities to the core product yet – the above cycle counting workflow is just a demo inside the app.  The goal of introducing these new control screens is to enable partners and customers to build new workflow-based solutions in the mobile app that support client-side driven scanning operations.  As such let’s walk through a simple customization example to show how the new control screens can be utilized in a real workflow.

Page Patterns

The way to enable the multi-scan screen is through a Page Pattern.  This might not be something you are aware of in the mobile app, as most of the time this is handled for you by the standard framework.  The Page Pattern is what tells the mobile app what type of UI to display on the device itself.  If you look at the WHSMobileAppPagePattern Enum you can see the different options available:

• Default
  • This is the page pattern used for 90% of the screens in the app. It displays a primary scanning UI and a set of controls in the secondary tab – of which a few can be promoted to the first screen.  An enter and cancel button and an optional set of additional buttons in the menu are supported.
• Custom
  • This Page Pattern is not used in many places in the core mobile flows – it is designed to allow partners to convert their old WMDP pages into the new model. Using this pattern will render the controls as it was done in WMDP  – each control simply vertically stacked in a single screen.
• Login
  • This is used for the initial login page.
• Menu
  • The Menu screens are rendered with this Page Pattern.
• Inquiry
  • This Page Pattern support the workflows that allow the user to search for something and then see the results – such as LP or Item lookup screens.
• InquiryWithNavigation
  • This is the Page Pattern that supports the Worklist view in the app. It is similar to the Inquiry pattern, except that includes some sorting options as well as the tiles are navigable.
• MultiScan
  • This is the new pattern that has been added which will display the multi-scan UI shown in the demo above.
• < MultiScanResult>
  • Note that as of the 8.1.1 release there is one missing and will be added in an upcoming release. If you want to enable a workflow to use the second screen described above – the “result list” of items, you would need to add a new Enum and return the value MultiScanResult. 

The actual job of returning the Page Pattern to the app is done through a class which derives from WHSMobileAppServiceXMLDecorator. This abstract class has a “requestedPattern” method that can be overridden to return the specific Page Pattern that is necessary.  This is typically done through a workflow-specific factory class that understands the correct workflow steps and thus can return the correct XMLDecorator class depending on the stage in the state machine.

For example – here is the standard factory class for the Work List functionality.  You can see that it typically will return the WHSMobileAppServiceXMLDecoratorWorkList object – which will render the work list Page Pattern as you would expect, however if the user has switched to the edit filter view then we need to display a different Page Pattern – thus the factory has the context to make this switch.

Multi-Scan API

Now that we know how to enable the Multi-Scan UI through a Page Pattern, we need to understand the basic API for passing the scanned items back and forth.  Once the MultiScan Page Pattern is requested, the first input control registered on the page will be used for the multi-scan input.  Remember that most of the UI interaction is all done client-side – so the only thing the server X++ code needs to do is define this control and the data that it contains.

When the user clicks that “submit” check box and sends the multi-scan data back to the X++ code, this is formatted in a very specific way.  The actual parsing of the data is done using the same interaction patterns as before – it will be stored in the result pass object for the specific control defined as the primary input of this page.  But the data will be passed in this format:

                         <scanned value>, <number of scans>|<scanned value>, <number of scans>|…

Thus, in my demo example above the data that the server would receive would be the following:

                         BC-001,2|BC-002,1|BC-003,1

In the X++ code you would then be responsible for parsing this string and storing the data in the necessary constructs.  We will see a simple example in a moment of how to parse this data.

Asset Scanning

The workflow I will demonstrate is very similar to some of the WHS workflow demos we have described in previous blog posts.  In this flow we will be scanning a container and then capturing all the “assets” that are stored in that container.  Imagine that these assets are very numerous and thus are stored outside of the standard batch tracking mechanisms in AX – they are implemented in the sample as a simple asset table associated with a container.  The assumption here is that scanning assets needs to be extremely quick and thus the offline “multi-scan” mode is the perfect solution.

The state machine for this workflow is similar to our previous examples – we will have an initial scan container screen, which will transition into the multi-scan enabled “Scan Assets” state – and finally when the list is returned we process the assets and return to the initial state. 

You can see this reflected in the core displayForm method below.  We will not be covering some of the lower-level details of the code – please review the earlier blog posts for details on the enums and control classes necessary to facilitate the new workflow.  All the code necessary for the solution can be downloaded at the end of the post if you want to dig into the details.

The getContainerStep is identical to our previous examples – it simply shows a simple UI and grabs the container ID from the user.  The getAssetStep method validates this container ID and calls the buildGetAssets method – which is where the UI for the multi-scan screen is built.  This is copied below:

As you can see this does not look much different that standard WHS code we have done previously.  The first input control (in this case the Asset ID field) will be used as the multi-scan field, but this code does not need to be modified in any way to support the multi-scan Page Pattern.  Instead what we need to do in ensure the correct Page Pattern is returned to the app during the correct workflow step.  To make this happen I have added a new DecoratorFactory class which will return a WHSMobileAppServiceXMLDecoratorMultiScan object at the appropriate step for my workflow – which in turn is what renders the Page Pattern to the app.

Please note the attribute at the top of this class – it is the same WHSWorkExecuteMode mapping attribute used for the WHSWorkExecuteDisplayAssetScan class in the code sample above.  This is how the framework knows that this specific decorator factory class is used for this work execute mode – the enum-based attribute ties these classes together through the sysExtension framework.  The key point here is that if you need a custom decorator factory to define when exactly to switch to multi-scan mode, the above example is how you will enable this.

In the final workflow step we need to process the incoming multi-scan results. As mentioned before these are returned to the server in the same way as normal data – it will simply look like a specially formatted string in the value of the input control.  Recall the discussion above with the format of the string being <scanned value>, <number of scans>|… In my simple example below, I am parsing this string using X++ and saving the assets to a new table associated with the Container.  In this case I am not making use of the second piece of information in the collection – the number of scans was not necessary in this case.

Hopefully it is clear how we loop through all the scanned assets and save each one to the new table.  After this is complete, we reset the workflow and move back to the first stage in the state machine.

Example Workflow

Now that you have seen the code to enable this in a custom workflow, let’s walk through this demo.  You can download the complete code for this project in the link at the bottom of this post – you just need to get it up and running on a dev environment and configure the necessary menu items to enable the workflow for your system.

The initial screen shows the Container ID scanning field.  Not that in the sample project I have included the necessary class to default this to the scanning mode – however you will need to set these up in Dynamics as defined here.

Scanning a container id (CONT-000000001 works if you are in USMF in the Contoso demo data) will navigate you to the next screen and enable the multi-scan Page Pattern.

Here you can enter any number of assets and the app will store them into the local buffer.  As we described above you can view the scanned assets by clicking the icon in the lower left.  After a few scans we would see the UI updated:

Clicking the list icon would show us the scans we have performed offline:

Finally clicking the “submit” button on the main screen will push the items to the server, which will then be saved to the custom table we have and the UI will display the success message.

Conclusion

Hopefully this help you understand the new control scheme that was added and how it can enable fast scanning operations.  The code used for this demo is available to download here – please note that this code is demonstration code only and should not be used in a production system without extensive testing.

As the manufacturing marketplace continues to evolve, so do customer expectations. Customers expect faster and faster response times and improved asset availability. To meet these growing demands, manufacturers need to transform field service to increase efficiency and ensure a first-time fix. Todays average first-time fix rate is 74 percent, which means over 25 percent of service calls require return visits, which can cost upwards of $1,100 per truck roll., according to an article in Field Technologies Online. Return visits also mean dissatisfied customers, broken SLAs, frustrated technicians, and wasted time and resources.

Remote monitoring of assets is the first step for manufacturers to leverage the Internet of Things (IoT) to increase operational efficiency and improve profitability. Operational data, provided through remote monitoring, enables field service to deliver quick response times and improve first-time fix rates.

Connected field service is the next step in the journey to transform field support. Connected field service enables organizations to transform service from a costly break-fix model to a proactive and predictive service model through the combination of IoT diagnostics, scheduling, asset maintenance, and inventory on the same platform. It is the foundation of a seamless service process that can increase customer satisfaction and boost revenue.

Want to improve visibility and field operations? Let me tell you a story.

Swiftel International is a telecommunications firm specializing in electronics payment solutions. Swiftel needed greater visibility when it came to device management and field operations. Device malfunctions demanded time-consuming inspections and scheduling field technicians was difficult due to blind spots in the companys performance tracking and work scheduling. Swiftel wanted to:

• Streamline remote device tracking and troubleshooting
• Monitor field technician performance and leverage technicians with the right training
• Improve customer satisfaction with greater service visibility

Collaborating with Microsoft, Swiftel chose a comprehensive solution of Microsoft Dynamics 365 for Field Service and Azure IoT. This approach would allow asset tracking and scheduling in the field with the flexibility of cloud access. Swiftel would also be able to optimize technician schedules, track inventory, and perform advanced data analysis for efficient routing and technician skill-matching.

Fast forward to streamlined services and enhanced productivity.

Now Swiftel can manage its devices remotely, and schedule better and manage logistics more effectively. Swiftel has a more comprehensive view of workers in the field, and has increased productivity and lowered costs due to more streamlined services.

Swiftel uses this intelligent system to optimize technician assignments using multiple factors, such as a technicians experience in handling the specific failure, the customers preferred technician or the technicians proximity to the site. Leveraging machine learning, Dynamics for Field Service automatically assigns the work order to the most experienced available personnel.

As the volume of requests increase, this system optimizes the technicians schedule to create the most efficient travel path, allowing the technician to perform additional calls that day. Real-time inventory management ensures that the replacement part is available on the scheduled date and that the technician has access to the tools needed to complete the job. Dynamics for Field Service can identify the right parts to replace, where they should be purchased, and provides more accurate lead time predictions for the organization.

Lets take our story even further. What if a technician needs additional help during the service call? They can leverage Dynamics 365 Layout and Dynamics 365 Remote Assist using HoloLens. This emerging technology offers technicians 3-D renderings overlaid directly onto the device, highlighting the parts needing repair while displaying performance dataeven on a mobile device. Artificial intelligence (AI) can use the data from predictive analytics to make just-in-time recommendations to the technician, ensuring repairs are completed correctly the first time, every time. Remote Assist is in the early phases of being used to improve safety and reduce costs through the use of remote experts for equipment verification and incident response.

Lets get back to our story. Now Swiftel technicians can commit repairs to a device with minimal downtime, and the device is fixed right the first time by the best technician available. Check out the full Swiftel case study for more information.

Create your own story at Hannover Messe

Make your field service dreams come true by experiencing Dynamics 365 for Field Service, and Dynamics 365 Remote Assist, using Hololens, and learn how connected field service works. Join me for a personal tour of these technologies in booth #40 at Hannover Messe on April 1 5 in Hanover, Germany.

Youre invited to learn how Microsoft Dynamics 365 Business Applications can transform your support operations. Try mixed reality and Hololens and see for yourself how AI can proactively drive efficiencies, optimize resources and modernize field service. Find out how easily you can leverage connected devices and IoT with Field Service to deliver proactive and never fail service to your customers.

I look forward to seeing you at Hannover Messe!

The post Intelligent field service at Hannover Messe appeared first on Microsoft Dynamics 365.

Applies to: Project Service Automation for Dynamics 365

Were pleased to announce the latest update for the Project Service Automation application for Dynamics 365. This release includes some important feature enhancements, improvements to quality, performance, and usability, and is based on your feedback and requests.

This release is compatible with Dynamics 365 for Customer Engagement apps version 9.x. To update to this release, visit the Admin Center for Dynamics 365 online, solutions page to install the update. For details, refer How to Install, Update a Preferred Solution.

Project Service Automation (V3.6.0.67)

Features

• Support for bulk adjustments of approved Time and Expense lines.
• Allow price setup in any currency for labor prices within a single cost price list.
• Allow price setup in any unit of time within a single price list (in sales or cost context).
• Support for a currency agnostic Cost Price List defaulting for a global PSA practice.
• Make Product price list optional on project based opportunities.

Bug fixes

• Fixed: Respect system settings for using currency code vs. symbol on estimates tab.
• Fixed: Expense “New” button displays the incorrect tooltip.
• Fixed: Expense: Incorrect values in the Remaining Effort columns when editing schedule in specific scenarios related to adding a new task to the WBS.
• Fixed: Resource utilization grid not respecting resource calendars correctly and calculating utilization incorrectly.
• Fixed: When creating a requirement through generic team member, requirement details are not respecting the project calendar.
• Fixed: Duration in the Microsoft Project desktop client when linked Microsoft Project Add-in, increases when refreshing the project from PSA.
• Fixed: Unbilled Sales Actual marked as “ready to invoice” is not reversed when cancelled or recalled.
• Fixed: Time duration entry updated to support HH:mm -> HH.hh

-Project Service Automation Team

The post Release Notes for Project Service Automation Update Release 6 appeared first on Microsoft Dynamics 365.

We are excited to announce the support for Apply with LinkedIn for candidates to easily apply to jobs 

LinkedIn is the world's largest professional network with more than 610 million users in more than 200 countries and territories worldwide. Most LinkedIn active users keep their profile up to date so recruiters can match them to the right opportunities. 

Dynamics 365 for Talent Attract customers can now allow their candidates to apply for jobs through the Attract career site using “Apply with LinkedIn” functionality. Once the integration is setup by the Attract administrator, candidates will now be able to easily use their full LinkedIn profile to auto-fill applications for jobs within the Attract career site. This capability streamlines the application for the candidate providing latest and relevant information about themselves. Additionally, for the hiring organization, “Apply Starters” helps to keep track of candidates that started their application with LinkedIn data but do not submit the application. Apply starters is available in LinkedIn Recruiter as we work on adding Apply starters explorers widget in Attract.

To set up “Apply with LinkedIn” integration with Attract, please click here. If you have any feedback or ideas for how we can improve the product and its capabilities, please submit an idea here or leave a comment below. 

The post Dynamics 365 for Talent now supports Apply with LinkedIn appeared first on Microsoft Dynamics 365.

Last week, I had the opportunity to spend two days at the Adobe Summit, where our longstanding partnership with Adobe grew deeper and stronger. The momentum around Adobe and Microsoft was palpable, and Im thrilled that were offering our mutual customers best-in-class solutions to provide great experiences for their customers. It was an exciting week in Las Vegas!

The next steps for the Open Data Initiative

During Wednesdays general session, Microsoft CEO Satya Nadella joined Adobe CEO Shantanu Narayen onstage for a conversation covering digital transformation, creating a learn-it-all culture at Microsoft, and leveraging data to create personalized, impactful customer experiences. We also saw the Open Data Initiative (ODI) in action. As originally announced last September by Adobe, Microsoft, and SAP, the ODI is a new approach to business data that helps companies transform customer experiences through real-time insights delivered from the cloud.

Unilever, one of the early global brands to express support and excitement about the ODI, announced its intention to leverage these data connections immediately. At the Adobe Summit, Unilever demonstrated how it plans to bring together disparate customer, product, and resource data and use AI-driven insights to reduce plastic packaging and encourage consumer recycling. By eliminating silos of data, Unilever will connect inventory and plastics data with Adobe data on Azure to enhance customer experiences and encourage participation in this sustainability initiative.

We also announced a new approach as part of the ODI for publishing, enriching, and ingesting initial data feeds from the Adobe Experience Platform, activated through Adobe Experience Cloud, Microsoft Dynamics 365, and Office 365 and SAP C/4HANA, into a customers Azure Data Lake. This enables customers to use AI and machine learning to generate new, actionable insights that can transform their business.

Just after Wednesdays general session, I had the privilege of kicking off the first-ever meeting of our ODI Partner Advisory Council, along with my colleagues from Adobe and SAP. Our partners will be critical to unlocking the true opportunity presented by the ODI, and Im excited to work closely with them to develop this initiative further and bring this innovation capability to more customers.

Read more about ODI in last weeks announcement.

Accelerating account-based experiences with LinkedIn

On Tuesday, we also announced a new extension of the Microsoft and Adobe partnership to include LinkedIn. This addition expands opportunities for product innovation and increases value for our joint customers. Were adding new integrations across Adobe Experience Cloud, Dynamics 365 for Sales, and LinkedIn Marketing Solutions to accelerate account-based experiences empowering B2B marketers and account-based sellers to easily identify, understand and engage customers, and create better orchestration, measurement, and delivery of targeted content for more personalized experiences.

Enterprise sales and large account deals often demand long negotiations, multiple decision makers, and complex relationship dynamics. We believe account-based experience drives success. Today, enabled by deeper data integration across Microsoft, Adobe, and LinkedIn, marketing and sales teams can tailor their offerings to individual customers, understand changing demands, and land complex sales.

Read more about this in the announcement from Adobe.

Customers seeing value of Adobe + Microsoft

Also on Tuesday, Brenda Bown, General Manager for Microsoft Business Applications, hosted a panel with Matthew Jafarian, Vice President of Digital Strategy and Innovation, Miami Heat and Mark Pelletier, Vice President of eBusiness, AAA Northeast. Matthew and Mark represent two of many customers using Adobe and Microsoft solutions to understand and delight customers. They shared their challenges and opportunities, explaining how their partnership with Adobe and Microsoft connects them with people in a more personal, relevant way.

For Matthew, working with the Miami Heat, this was all about the guests in the stadium:

Were focused on fan facing technology. Thats everything from ticketing tech when you walk in the building, thats retail tech, thats food and beverage tech. All of that data flows into our applications, Dynamics 365, our martech stack which is primarily Adobeeverything is focused on creating great fan experiences.

This type of business evolution is underway across the globe.

In Colombia, Avianca Airlines is focused on creating highly personalized and specific customer journeys for every passenger they fly. As Santiago Aldana Sanin, CDO and CTO, explains, success in the travel business requires a focus on the complete experience, from booking, to the gate, to the air. They are already seeing the value of customer-centric IT with Microsoft and Adobe today.

Closer to home, 24 Hour Fitness has pioneered the health and wellness industry for more than 30 years. Today, with the partnership between Adobe and Dynamics 365, 24 Hour Fitness targets and nurtures users throughout their health journey, from exercise evaluation and purchase, to long-term wellness and personal engagement, all on a single digital platform.

Our commercial environment is changing. And my favorite part of this job is not the growing list of marketplace applications, services, and solutions, its the partnerships. By partnering with industry leaders like Adobe, growing our ecosystem with ISVs, and working directly with customers to build new solutions, we can add genuine value and help transform the world together.

Last weeks Adobe Summit was the next step in our ongoing partnership with Adobe. Learn more about how that partnership can transform your business here.

The post Growing the Microsoft and Adobe cloud partnership appeared first on Microsoft Dynamics 365.

We are thrilled to announce that the much-awaited feature mobile offline for Dynamics 365 for Customer Engagement apps (9.x online versions only) is now available for Public Preview. This feature is available on Dynamics 365 for phones and tablet app for iOS and Android users. Going forward, we will also enable this functionality for all model-driven apps.

Today, traveling workforce and frontline workers cannot work with their data in areas with no internet connectivity, thereby hampering their productivity. With the release of offline capabilities, users can now continue to work without hindrance in elevators, building basements, subway commute, etc.

How does mobile offline work?

Using mobile offline solution is easy. Once Dynamics 365 administrators set up mobile offline solution, users can start using it right away without having to do anything else. Administrators can set up offline solution in a few simple steps.

1. Select the data/entities that you want users to have access to in offline mode.
2. Create a mobile offline profile by adding a subset of entities selected above, corresponding filters for data download, and users who will have access to that data.
3. Select app modules and associate them with the profiles created above to ensure that right app modules and data are available to the users.

For more information, see the Mobile Offline Admin Guide.

Once the above set up is done, which should only take a few minutes, users can start to access their data on the device in offline mode without any hassle.

Offline data on the device is updated periodically in the background to ensure that you always have access to the latest data whenever you go offline. At any point, you can check the time and status of the latest data update on your device. While in offline mode, you can easily interact with your data using commands such as create, read, update, and delete. Once you are back online, any changes made in the offline mode are automatically synchronized with the server without any additional steps. Refer to the Mobile Offline User Guide for detailed information.

This is just the start and we are committed to continue working towards improving it. Based on your feedback so far, we have invested in delivering a high-quality feature that caters to your key business scenarios in offline mode. Some of the improvements underway are:

• Improved user experience: Offline metadata download which happens in the foreground today, will be moved to the background, allowing users to work seamlessly in online and offline mode
• Improved admin experience: Improvements to offline profile publishing experience to ensure that administrators can quickly create and publish offline profiles for their users

How do I start using it?

All the Dynamics 365 for Customer Engagement apps (9.x online server versions) will automatically have access to mobile offline functionality. Before you can start using it:

1. Follow the detailed step-by-step instructions provided in the Mobile Offline Admin Guide to set up the offline solution for the Dynamics 365 mobile app users. Before users can access their data in offline mode, administrators need to select the app modules and the data within it which will be available to the users in offline mode.
2. Once the setup is done, download the latest version of the Dynamics 365 for phones and tablet app (13.19033.1 or higher) from the app store to start using the solution. For more details on the feature, refer to the Mobile Offline User Guide.

How can I provide feedback?

A huge thank you to all the customers who provided their valuable feedback to help improve the feature. We would love to hear your ideas and suggestions for any improvements in this feature. Please provide your feedback through the Dynamics 365 insider portal.

1. Sign up on the Dynamics 365 insider portal.
2. Once signed in, select the Insider Program and select Dynamics 365 Mobile Offline Preview.
3. Leave your comments on the feedback forum which is regularly monitored by us.

Kavishi Agarwal
Program Manager
PowerApps

The post Stay productive always with mobile offline for Dynamics 365 for Customer Engagement apps (Public Preview) appeared first on Microsoft Dynamics 365.

Today, we officially kick off the release of a six-month wave of more than 350 new capabilities, feature updates and applications across Dynamics 365 and the Power Platform.

This update continues our commitment to deliver two major releases per yearin April and Octoberwith new capabilities and innovations to help you stay ahead of rapid changes in your business and industry. These biannual updates are supported by our monthly improvements, helping to ensure continuous delivery of exceptional stability and performance of a modern SaaS service (read more about our One Version service updates).

At this mornings Virtual Launch Event (streaming live at 8:00 am PST, then on-demand), well provide a preview of feature releases over the next six months, spanning some of the latest applications we are bringing to market in the next few months, including Dynamics 365 Customer Insights, Dynamics 365 Virtual Agent for Customer Service, Dynamics 365 Fraud Protection and Microsoft Forms Pro. Well also show new mixed reality applications and the continued innovations coming to the Power Platform.

Connecting customer experiences with the power of AI

Enabling a world-class customer experience, this update introduces AI-driven applications that produce deeper actionable customer insights and personalized experiences, while giving sales teams more integrated collaboration and buyer insights for a modern, relationship-focused approach to selling.

The trifecta of apps starts with Dynamics 365 Sales Insights, which gives businesses insights that help them drive effective sales coaching and personalized engagement with buyers. Dynamics 365 Market Insights tracks web search data and social conversations to help companies know what their audience is saying, seeking, and feeling about products, brands and topics important to their business. And Dynamics 365 Customer Insights, unifies data sources to provide businesses with a single view of their customers and discover insights that drive personalized experiences. For instance, Tivoli, the worlds second oldest amusement park operator, is using Customer Insights to help personalize everything from marketing outreach to frontline, on-property guest experiences. Here is a video with Tivoli talking about their experience:

Watch Tivoli video now

The ability to connect data and then apply intelligence to it to deliver a transformed customer experience extends to customer service as well. Dynamics 365 Customer Service Insights provides actionable insights into critical performance metrics and emerging support questions, enabling managers to proactively train agents on new emerging topics, create new materials or automate responses through the virtual agent, so they can resolve customer issues quicker. Dynamics 365 Virtual Agent for Customer Service automates common service requests and issues to let call center agents focus on the more complex topics. It empowers customer service teamsthe people closest to the customers and experts on how to engage effectivelyto be proactive as well as customize and maintain virtual agents without the need to write code or be an AI or ML expert.

Were introducing Microsoft Forms Pro, a comprehensive survey solution that makes it easy to collect feedback across customer touchpoints, correlate the feedback with business transactions, and derive actionable insights from the combined data.

We are also excited to highlight Dynamics 365 Fraud Protection, a product built from Microsofts deep experience managing billions of ecommerce transactions. This public preview product offers state of the art fraud protection based on connected knowledge, industry leading AI and operations research to help businesses shield themselves and their customers from payment fraud.

Mixed reality: on-site field training goes mobile

In October, we introduced the first set of mixed reality apps for HoloLens, including Layout and Remote Assist. The April 19 release includes a new wave of innovation that extends Dynamics 365 mixed reality to HoloLens 2 and mobile devices, as well as provides step-by-step Guides that enhance training and on-site guidance for technicians. These new mixed reality applications help to empower front line workers, transfer skills, and reduce the time it takes to train new employees in a fundamentally different and more experiential way.

Were also introducing Dynamics 365 Product Visualize that allows sellers a new way to convey the true potential of products in a customers actual environment so they can interact with and understand the product. This mixed reality business app is available for preview on iOS today.

Power Platform: upgrading the power of three

The Microsoft Power Platform Power BI, PowerApps and Microsoft Flow – keeps getting better with every release, and the April 19 update is no different, offering exciting updates across all three products.

As I recently explained in-depth, the Power Platform enables business users to Analyze, Act, and Automate in ways that can make a big impact across the business. It creates a digital feedback loop that harnesses data sources to build a continuous stream of insightsa perpetual engine for business automation and intelligence. Any business user, from the CEO to frontline workers, can gain insights from data using Power BI, create intelligent business processes via PowerApps without writing code, and then leverage Flow to automate workflows between apps and services.

The April 19 release enables citizen app makers to build higher-quality PowerApps more easily. Flow helps organizations automate and extend processes directly from business and productivity apps like Microsoft Teams, Excel, and OneDrive. Power BI has been updated to further empower organizations to create a data cultureenabled by major new capabilities to support large scale enterprise BI deployments, adding pixel-perfect paginated reports, and new AI capabilities that make it easier to extract insights from data.

The best way to understand whats possible with the Power Platform is to see it in action. Take a look at how Arriva, one of the largest providers of passenger transport in Europe, is giving non-technical users access to PowerApps to do anything from optimizing routes to better servicing buses.

Watch Arriva video now

Get a deep dive look at April 19 release innovations

In addition to the new applications the April 19 release delivers new features and capabilities across all Dynamics 365 applications and on behalf of the entire Business Applications team, its a privilege to introduce this wave of innovation.

Be sure to watch the Virtual Launch Event this morning at 8am and check out our April 19 release page for the very latest release information, key dates, and deep dive demo videos.

Learn more about the April 2019 release

• April 2019 release notes: details about all features releasing from April 2019 through September 2019 for Dynamics 365 and Power Platform
• Blog: New AI, mixed reality business solutions lead the way for Microsoft Dynamics 365
• Blog: Introducing Dynamics 365 mixed reality applications for HoloLens 2 and mobile devices

The post April 2019 Release launches with new AI, mixed reality, and 350+ feature updates appeared first on Microsoft Dynamics 365.

Customer relationships are at the heart of every successful organization. To deliver high quality customer experiences, you need to not only be collaborating internally within your organization but also engaging in effective customer conversations. As part of our goal to put people at the center of your experience in Dynamics 365, we are bringing a familiar experience to Dynamics 365s Unified Interface: Profile cards.

Profile cards exist in Outlook and other Office apps today to help you collaborate with a person, whether they are your colleague or an external contact. They enable you to have their information at your fingertips wherever you are in the Office ecosystem. Starting today, this experience is rolling out for Dynamics 365 so you can take the same actions on your data in Common Data Service within Unified Interface.

View your contacts information at a glance

Collaborate with your colleagues in Dynamics 365

For more information, see View the profile card for a contact or user.

Srihari Srinivasa
Senior Program Manager

The post Introducing Profile cards in Dynamics 365 appeared first on Microsoft Dynamics 365.