[Tutorial] Piece by piece receiving process with Advanced Warehouse Management in Dynamics 365 SCM

Introduction

In a recent post (Piece by piece picking process with Advanced Warehouse Management in Dynamics 365 SCM) I described the configuration necessary to allow performing picking in the warehouse by scanning each SKU one by one aka "piece by piece". I suggest you familiarize yourself with this post as I will be re-using the master data setup here. 

In this post, we will be receiving a purchase order with 4 lines, all for DemoShoe product, with similar variants (Size and Color) and quantities, as in the prior example with a sales order. Below you can see the PO lines in full:

Purchase order with 4 lines for DemoShoe

Standard receiving flows like Purchase order item receiving, load item receiving and similar, which receive one purchase order line at a time do not support the piece by piece item entry. 

But there is one mobile device receiving flow that does. It is Mixed License Plate receiving, and below you can see how I have configured it in the application - pretty much a default configuration:

Mixed LP receiving mobile device menu item

Mixed LP receiving is meant for receiving a pallet with mixed items, as described in more detail in our team's blog post. As you can read in the blog post, the initial feature was built with a slightly different purpose, but can be used as well as described in this post.

As before, and very important, we need to configure the bar codes for scanning for all the variants. Exactly the same as in the previous post:

Product variant bar code setup for DemoShoe

Flow

1. We start by scanning in a license plate. This will be the license plate we are going to use for putaway, and as such will be set as the target LP on the created work order.

Enter License Plate

2. As Mixed LP receiving allows receiving items from multiple purchase orders, we then need to enter the PO number we are going to be scanning items from. 

Enter Purchase order number

3. Now we have reached the page where we can start scanning in the barcodes. That's exactly what we are going to do, by scanning in 38White, corresponding to 1 unit of the DemoShoe product variant of size 38 and color White.

Scanning the first product variant

4. After scanning the item we do not see any confirmation, but are presented with the same screen, allowing us to scan the next variant barcode, in this case, 38Black.

Scanning the second product variant

5. At any point in time during the process, we can view the list of items already scanned, change PO number to receiving another purchase order, or complete the scanning for current LP, in our case, when it's full and we want to commence putaway operations. 

LP Complete is what we are going to select below, after having scanned a few more items

Mixed LP receiving - Available actions

6. When completing a license plate, we are first presented with an overview of all the items, and we can still edit the list by adjusting the quantities or removing some of the items from the list. 

(Note. Similar activities can be performed from the web client)

Preview of the scanned items before completing LP

7. When we confirm the list by selecting the checkmark action at the bottom of the page, work will be generated for all the scanned purchase order lines with the respective quantities. This will use the same location directives and work templates as when scanning items in the "standard" way.

Note, that this can take some time, more than it does for a single line receipt, as this will be doing the same action N times, for each PO line we scanned. 

Maybe In future versions of Dynamics 365 SCM we will allow you to configure this process to run "deferred", so that the receiving clerk can move on to the next pallet / purchase order

While the process is running, the app will be blocked and the standard progress icon will display, as shown below:

Progress of creating receiving work

8. Once the process is complete, we will be directed to proceed with scanning the next license plate / purchase order information.

We can review the created work order in the Dynamics 365 SCM web client. 

Nothing unusual here, just a regular work order, as you can see below:

Work order for purchase order

Summary

Now you are familiar with "piece by piece" scanning operations on both inbound and outbound side.

In one of the following blog posts we will review the options available when doing inventory counting operations. 

As for now, let us know if this feature is useful for your business. What's missing? 

Anything else that you would like to see described?

Thanks

Tutorial: Moving inventory out of a location to complete a put away inbound operation

Introduction

As some of you have probably already read in this blog post, we have recently made some improvements for the inbound flow in Warehouse management, and I wanted to do a quick recording demoing an example which uses some of these capabilities.

For some additional information about the different types of movement flows currently supported please follow to another blog post we've recently published.

Another reason for publishing this particular scenario recording is that we are currently working on another improvement, this time focusing on adding more flexibility for inventory movement operations, where there are work reservations blocking the items in the location from being moved anywhere else. This is a known pain point for a number of customers, and if all goes well, we'll have it addressed in the Fall release of the new Dynamics AX.

The scenario recording is covering one such flow, except for the fact of existing work reservations - in my example there will be none.

I am trying out uploading this to Office Mix, as well as YouTube. Let me know if you like the Office Mix approach - I think it's pretty cool as it makes it possible to browse the recording to a specific point more easily.

Demo

YouTube video:
https://www.youtube.com/watch?v=P7W2Th43-Fo

Question for you

As you can see from the above video, the approach John took is to cancel out of the Put, complete the movement, and then continue the Put.
An alternative could be to complete the put, even though physically the goods are not yet placed into the location, and then create the movement, but in this case we are for a period of time out of sync with the app.

Please leave a comment if the above approach is not a good match for your company, and explain what approach you use instead and why.

Thanks!

Walkthrough: Fixing the error message "WorkGroupingId is not found in the map"

Introduction

Since the release of the new Warehouse management solution with Microsoft Dynamics AX 2012 R3, a number of people have reported a sporadic error that was difficult to reproduce, but it was happening consistently on their environments.

The error message shown to the user on the mobile device was also not very helpful:

The value "WorkGroupingId" is not found in the map.

The challenge for us is usually to reproduce the problem, so we can actually debug through the code and see the root cause. We have finally managed to reproduce the problem recently, and have produced a simple fix, that will prevent people from getting into this situation in the future.
I don't yet know if this will be released as a hotfix for 6.3, but I will make sure to update this post with the link if that happens.

You can also just get the code from this post below, but that means you will need to apply it yourself.

But the primary purpose of this blog post is to release a small job to update the data that was messed up. Since we will not update all consumers of the mobile device menu items impacted, but only prevent future setup like that.

Of course, please have your development team review the job and the fix before applying this on your environment, and make sure to run it on your test environment first.
Neither Microsoft nor I will be held accountable for any data loss you might experience as a result of incorrectly applying the fix.

Example of scenario that is broken

I have a purchase order for one of my vendors, for 1 item that is WHS-enabled, as shown below:

Simple purchase order

I now want to use the mobile device to receiving this purchase order in my WHS-enabled warehouse 42. That assumes that I have Location directives, Work templates, Work users, etc. set up already. If you are not familiar with the inbound flow in Warehouse management, please look at some my other posts, where this is described. For this post, I only will include the configuration screen for the Mobile device menu items.

In my company, we used to normally receive small inbound orders, so we configured the mobile device to allow first grouping multiple incoming orders to put them away all at once, and then grouping the puts into one once you are at the location (assuming, of course, that the put-away location is the same for multiple orders). The following menu item configuration corresponds to that:

Mobile device menu items - User grouping

But then, since we got more and more deliveries that were much larger in size, where grouping them for put away on one pallet was no longer an option, we decided to change the menu item setup to just order by order, as shown below:

Mobile device menu items - User directed

But suddenly, when processing putaway for incoming orders, our workers started getting the above error about "WorkGroupingID not found in map":

Warehouse mobile device portal flow

Product bug fix

The fix, as I mentioned above, will only address the part, that touches the configuration of the mobile device menu items, as that is where the root cause of the issue is. When you change the "Directed By" to something other than "User grouping" or "System grouping", the "Group putaway" gets hidden, but still contains the value it had before. Then the mobile device code relies only on this value (in some flows), and does not check that the "Directed by" is also appropriate.

Here's the fix. I am inserting it as an image so it's more difficult to copy to make sure you don't overwrite whatever changes you have in that method already.

Code changes required to fix "WorkGroupingId" bug

Data fix

The above fix means that people who have invalid setup will still be hitting the exact same issue when doing putaway. So below is a small job that fixes the invalid data by unchecking the "Group putaway" check-box for menu items where it was set incorrectly.

static void dataFix_WHSRFMenuItemTable_WorkGroupId(Args _args)
{
    WHSRFMenuItemTable menuItemTable;

    ttsBegin;

    update_recordSet menuItemTable
        setting GroupPutaway = NoYes::No
        where menuItemTable.MenuItemDirectedBy != WHSMenuItemDirectedBy::SystemGrouping
            && menuItemTable.MenuItemDirectedBy != WHSMenuItemDirectedBy::UserGrouping
            && menuItemTable.GroupPutaway == NoYes::Yes;

    ttsCommit;

    info(strfmt('Fixed %1 menu item(s).', menuItemTable.RowCount()));
}

When you run the above job, you'll at the end get an infolog message informing you how many records were fixed.

Result

After applying the above fix and running the above data fix job, you should be able to successfully complete the putaway.

Walkthrough: Cancelling put-away work in Microsoft Dynamics AX 2012 R3

In the new Warehouse management solution shipped with Microsoft Dynamics AX 2012 R3, any movement of inventory in the warehouse would normally have a corresponding piece of work registered together with work lines detailing where the warehouse workers should pick the goods from and where they should put them.

Therefore, it is no surprise, that when you receive a purchase order (or any other inbound order, like a transfer or a return) through the new mobile device portal, work will be created to put away the goods into a storage location (or QA or whatever you set up in your location directives). The closest analogy for those who know the existing WMS II solution that I have is the pallet transports used in conjunction with arrival journals, where goods get physically registered at the inbound dock, and a pallet transport is created to move the pallet to the location found based on the put-away rules selected on the arrival journal line (Check picking/bulk locations). The new solution allows a much better level of control over all the warehouse operations.

What I want to talk about today is the cases where the created work is not satisfactory and needs to be modified / canceled.

There are three scenarios I would like to mention:

1. The put-away location needs to be changed, because the suggested location is unavailable or another location is simply preferable.
2. The put-away work needs to be canceled, where a decision about the put-away location will be taken later
3. The put-away work needs to be canceled, because the receipt was incorrect to start with

1. If the warehouse worker doing the put-away is an experienced user who is allowed to make on the spot decisions about modifying the suggested flow of inventory, he can override the put location, storing the goods away into a different location at the warehouse.

This is controlled by a policy on the setup of warehouse workers, accessible through Warehouse management \ Setup \ Work users \ Worker, as shown in the below screenshot:

Allow work user to override put location when executing work

2. Another way to achieve this would be to cancel the pending put-away work, ensuring that workers do not see it on their mobile devices as something they should execute now, and creating a manual movement to a location of choice when the decision where to move the goods is made. This would be a decision done by a receiving clerk / warehouse manager. 

It could also be due to some extra paperwork or inspection being done on the items, where it's yet unclear if the system-selected put-away location is OK. (If it is, the warehouse manager could simply block the work until a decision is made, which would prevent workers from executing on it)

In order to cancel the work, simply press the "Cancel work" button on the Work details form (or corresponding list page). See a step-by-step walk-through below.

3. Now, sometimes, due to input errors or other factors, you would want to not only cancel work, but also make sure the goods are not physically at the warehouse either, reverting the entire receipt as if it never happened (you'll still have a trace of it happening). This could, for example, be useful if the receiving clerk was logged in to a different warehouse and accidentally received a purchase order to that warehouse instead of the one the user was actually at (Note: Not possible in RTM, need a corresponding hotfix installed).

This additional step of unregistering the items is controlled by a policy on the Warehouse management parameters, called "Unregister receipt when canceling work".

Warehouse policy - Unregister receipt when canceling work

Here is a step-by-step description of the cancel workflow:

• Create a new purchase order for a WHS-enabled item to a WHS-enabled warehouse

Purchase order with one line for a WHS-enabled item to a WHS-enabled warehouse

• Using the mobile device portal, register the receipt of the above purchase order (Hint: use a mobile device menu item with Mode = Work and Work creation process = Purchase order item receiving)

Purchase order receipt on Mobile Device Portal

• View the inventory transactions for the above purchase order, and confirm that they are registered at the default receiving location at the selected warehouse (Note: It is the warehouse the user was logged in to when doing the PO receipt from the mobile device)

Purchase order inventory transaction with Receipt status = Registered

• Open the created put-away work (Hint: You can navigate directly to the new piece of work from the purchase order details form, by clicking on Work details button in the Lines section), and click on Cancel work.

Canceling put-away work

• Confirm that Work status of the work header and lines has changed to Canceled, and (depending on the above warehouse management policy) the purchase order line inventory transaction is back in Ordered receipt status. 

Note: This policy is currently implemented only for Purchase orders and Transfer order receipts. It will not come into play when registering the receipt of a return order or any other inbound order types.

I would also be interested in hearing your scenarios, which require canceling put-away work, and the reasons behind them. So if you use this functionality for reasons other than described above, please leave a comment below.

Thanks