[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: Label printing in Microsoft Dynamics AX 7

A while back I posted a tutorial on how to configure and use the label printing functionality in Microsoft Dynamics AX 2012 R3:

http://kashperuk.blogspot.dk/2014/09/printing-labels-with-new-warehouse.html

With the release of Microsoft Dynamics AX 7 and the move to the Cloud, printing has become a bit more complicated than before, since the printers are not on the same domain / network as it used to be when everything was installed on-premise.

The major change that I will talk about in this post is the way we set up printers now.

Installing & configuring the Document Routing Agent

The wiki article describing the installation and configuration of the Document routing agent is very well written and contains a lot of details about the restrictions and requirements for this to work, so I will not repeat it here. Here is the link:

https://ax.help.dynamics.com/en/wiki/configuring-the-document-routing-service-to-enable-network-printer-devices/

For example, one of the unexpected requirements is that Adobe Acrobat Reader is installed.

Note, that with a recent update of the AX platform, the Document Routing Agent can now be run in the background as a Windows service, which adds a number of benefits. Read more about that in the below wiki article:

https://ax.help.dynamics.com/en/wiki/running-the-document-routing-agent-as-a-windows-service/

Now that the document routing agent application / service is installed and can sign in to AX, you can select the printers you want to expose, activate them in the Network printers form, as described in the above wiki article.

After that, they will show up in the Printer name lookup on the Document Routing form as before.

Everything else is pretty much the same from a user standpoint, nothing changed in terms of document routing configuration or the WMDP configuration.

So when a label needs to be printed, here's what happens now:

1. The label is generated in the ZPL code, as before, containing all the replaced variables from the document routing layout
2. It is then saved in a file in the Azure Blob Storage (since the AOS does not have access to the client machine, we cannot just go and do something with it) in a pre-configured folder, including all the relevant settings, specifically, which printer to use for this label
3. The Document Routing Agent application / service on the network printer server or just as a local application one of the network PCs will periodically query if there are any pending files to be printed, downloads them from the Azure Blob storage and, depending on the printer settings defined for the specific file, re-routes the file to be printed, whether that is to a Zebra printer, or, in the case of regular SSRS reports, to a PDF document, or a regular printer.

Note that before Platform Update 2 there was an unpleasant bug in this framework, which prevented printing of labels from the Warehouse Mobile Devices Portal. That has since been fixed, and you should be able to print labels without any problems (Workaround for people on earlier installations is to use the WMDP enumlator form from AX web client)

Give it a try and report back here in case you find some of the instructions unclear, or if something is not working according to your expectations.

Thanks!

Walkthrough: Manual creation of Load packing structure in Warehouse management, Dynamics AX

Introduction

In the current version of Dynamics AX we have the ability to receive advanced shipping notes (ASNs) from vendors, store the corresponding shipment information, and then use this information to make receiving processes more efficient. Receiving an ASN is currently only available for products and warehouses that are enabled for advanced warehouse management processes (the so-called WHS-items and warehouses).

You can learn about importing inbound ASN files by following this link, where in my blog post I described that process in detail. 

Here we will walk through an example of manually registering the ASN information in the system. 

This could for example be used, if we are unable to import a specific ASN file format, having receiving an advance shipping note from the vendor. Or, if we want to rely on this functionality to “build-up” a pallet to be received, without actually having EDI document exchange with the vendor.

Here's a link to the video recording on YouTube.

Result

If you follow with the above walk-through, here is how the Load packing structure should look:

Resulting Load packing structure

Note

One other thing I did not pay much attention to were the UOM used for the lines, having interchangeably used 'ea' and 'pcs'.

Thanks for watching!

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.

Tutorial: Update product receipts for loads and how to handle items missing from ASN

In my post about the ability of receiving a mixed pallet through the License plate receiving method on the mobile device, I mentioned that once the receiving and put away is complete, the next step would be to update the product receipt document. With that, the purchase order status is updated to Received and all relevant GL postings are done.

Posting a product receipt for a load can be done from two places in the new warehouse management module:

• For a selected load, whether that is from the All loads list page, Load details or from the Load planning workbench. This will execute the posting right away
• For 1 or more loads, running as a batch job in the background, using the periodic operation "Update product receipts"

The actual business flow is more or less the same regardless of where you launch the update from, and I am going to describe it below, also doing a small demonstration of the forms and data that are relevant.

One thing that I specifically want to call out in this blog post is a piece of functionality related to receiving ASN documents, namely the receiving exceptions for items missing from ASN.

Preparation

So, i guess it's clear that the first step for us to look into the product receipt process is to get a load created and corresponding work created/executed for it. This is described in my post about importing an ASN and using License plate receiving to register their arrival and complete the put-away, so I will start here by just briefly listing the data I am going to work with in this demo:

• A load with 2 purchase orders on it, with shipping carrier specified as JB Hunt:
• PO #1 with 1 line for item 000148_202, qty = 2 PL (150 ea), WH = 42
• PO #2 with 1 line for item 000147_202, qty = 1 PL (100 ea), WH = 42
• A packing structure for this load (based on ASN received from the vendor)
• 1 pallet with License plate LP2POs006
• 75 ea of 000148_202
• 100 ea of 000147_202
• 1 pallet with License plate LPMissASN001
• 75 ea of 000148_202
• Work is created and executed for LP2POs006 through License plate receiving. 
• LPMissASN001 has not been received, as it did not actually arrive on the truck.

What the last line essentially means is that the vendor planned to and believes he sent us the entire order (thus it is in the ASN document), but in reality, one of the pallets is missing. So somebody needs to get notified about this exceptional situation and act on it, ensuring we do not get billed for the missing goods.

In order to showcase the receiving exception related to items missing from load as compared to the ASN I have also specified the corresponding work exception code in the Warehouse management parameters, as shown below:

Flow description

Warehouse management parameters

The "Update product receipts" menu item is located under Warehouse management \ Periodic, and opens into a dialog, where you can select the loads you want to post product receipts for. The criteria could be, for example, the shipping carrier bringing in the loads. If you know that "JB Hunt" delivers before lunch, we can try posting product receipts for their deliveries at, say, 2 pm.

Note

The batch job flow is per my understanding going to be used more often, so this is what I am going to describe in this post. Manual posting is pretty much identical, with 1 difference mentioned below.

Once you confirm the processing, the job will be added to the queue on the batch server, and will be executed based on the recurrence you have selected on the Batch tab page.
For this demo I have not enabled it to run in the batch, so the execution happens right away.

Here's an attempt at capturing what is going to happen with the selected loads when you schedule the product receipt update for them:

• Loop through all the selected loads
• If Load has not yet been Received
• check if the load has been ship confirmed, or the state of the related route (TMS functionality) if a load is part of a route. If it is not confirmed
• ship confirm the load and all related loads that need to be confirmed at the same time (because they are on the same route)
• if at least one of these loads cannot be ship confirmed, none of the loads will be confirmed. A number of things are checked here, but they are part of the transportation management flow, which is not the focus of this post, so I will omit describing them
• As a result, the status of the load changes to Shipped 
• check the document status of the purchase orders related to the load
• if the purchase order is not confirmed, confirm it.
• This entire step is executed within 1 transaction, while the below steps are part of another transaction. So if you for example cancel the actual product receipt, your loads would stay ship confirmed.
• Loop through the load lines
• Compare the load line to the related ASN item lines, finding discrepancies between the "planned" receiving quantity on the load line and the quantity work was actually created for based on the ASN packing structure. To rephrase, we compare, how much we ask the vendor to deliver in the selected load and how much he actually delivered.
• If a discrepancy is found, create a receiving work exception with exception code selected in Warehouse management parameters \ Code for missing items from ASN

Note: We currently do not record the actual quantity discrepancies, just that there was a difference, as well as the load and order line information

• For each purchase order linked, prepare the order for posting product receipt. All load lines will be posted as part of 1 large update, so if multiple orders exist they will be posted in 1 go, with the same ParmId.
• Actually post the product receipt for all relevant orders. 
• Display the Posting product receipt dialog. Note the product receipt IDs are generated as _#, so you should be able to later identify all product receipt documents posted for a load based on such a condition (if you do not override the number with the actual vendor IDs)
• Select to update only the Registered quantity, as that is what we have received according to the warehouse
• As a result, the status of corresponding purchase orders is updated to Received, or stays Open if some of the quantity was not received in full. 
• Update the load, removing load lines that were not received at all and decreasing quantity on those that were only received partially.
• Update load status to Received
• Update status of all shipments that are part of the load to Received

Manual posting difference

When posting the product receipt manually, the button to post is actually disabled until the purchase orders in the load are all in Confirmed status.

Demonstration

Navigate to Warehouse management \ Periodic \ Update product receipts, and configure the criteria for updating all loads delivered by JB Hunt that have not been Received yet. 

Update product receipt selection criteria

When you confirm the update, the above flow is going to execute, confirming the inbound shipment and displaying the product receipt posting dialog with both purchases shown. Notice the product receipt numbers assigned, and that only the registered quantity is updated. Confirm the processing.

Product receipt posting dialog

Once the update is complete, we can go back and check on the load. As you can see, the Load Status has changed to Received, and the quantity on the first load line has been decreased to match what we actually received.

Received load information

At the same time a receiving work exception has been logged in the system, pointing to a discrepancy of type "Missing item from ASN", as shown below:

Work exceptions log

If you now take a look at the purchase orders from the All Purchase orders list page, you will see that one of them was fully updated and thus has a status of Received, while the other is still Open and has an expected delivery for the quantity that was missing from the ASN. We'll now need to contact the vendor/carrier and figure out what went wrong with this shipment.

Youtube video walkthrough

As an experiment, I have also recorded the above flow in a screen cast and uploaded it to my Youtube channel. Take a look and let me know what you think. Is that helpful at all? (I take any kind of feedback very well :))

Summary

This post was trying to address two main goals:

• Explain and demonstrate, what happens behind the scenes when posting a product receipt for loads
• Show, how you can set up a receiving exception, that will allow more easily tracking cases where something went wrong and we did not get the goods we were supposed to.

I hope it's more clear now and you'll be able to use AX to the full extent when it comes to inbound ASNs.

Printing labels with the new Warehouse management solution

Hi all,

This blog post is based on a document I got from Boštjan Golob, a solution architect working with Dynamics AX. You can connect with Boštjan through LinkedIn.

I really enjoyed the information he provided and therefore wanted to share it publicly so all the AX community can learn how to configure and print labels with the new warehouse management solution. So here it is, enjoy:

Step 1: Understanding

How does AX actually print the labels? It is important to know that most label printers currently in use (such as Zebra brand printers) include some sort of a programming language interpreter and that the print job sent to a label printer is actually a small program. This is no different than with larger printers that use Postscript (there are web servers written in Postscript). In label printing, the feature set of a command language is usually quite rich: you can control the cutting of labels, the printer itself knows how to draw barcodes, you can select fonts that it has loaded in its memory and so on. This is an example of a ZPL (Zebra Programming Language) program:

CT~~CD,~CC^~CT~
^XA~TA000~JSN^LT0^MNW^MTD^PON^PMN^LH0,0^JMA^PR2,2~SD15^JUS^LRN^CI0^XZ
^XA
^MMT
^PW320
^LL0160
^LS0
^FT20,58^A0N,28,28^FH\^FDNalepka:^FS
^FT20,81^AAN,18,10^FH\^FD$LicensePlateId$^FS
^BY1,3,17^FT20,106^BCN,,Y,N,N,A
^FD$LicensePlateId$^FS
^PQ1,,,Y^XZ

AX can print a very sophisticated label by sending such a »program« to the label printer, while at the same time knowing absolutely nothing about label layouting. The labels stored in AX are command snippets like above. These are stored in Document routing layouts (Warehouse management – Setup – Document routing – Document routing layouts).
Knowing when to print a label is the job of configuration of menu items and work templates. AX can initiate printing of labels at work creation (for example in receiving scenarios), or during work execution. Which label to print is the job of document routing setup, where we tell the system, based on what we are currently doing, which label to pick and which label to send it to. We well get to configuration later.

Step 2: Getting the label in a text format

In order for this walk-through to be as comprehensive as possible (and as easy to click through without any annoying »this is left as an exercise to the reader« parts), the process of creating a small demo label will be demonstrated. I will use the NiceLabel labeling software (Made in Slovenia).

First, get the NiceLabel Designer Pro from the web site (www.nicelabel.com) and install the 30-day trial. Also download the NiceLabel Label Printer Drivers, as we will need them to create a dummy printer for NiceLabel to adapt the label to. This is important – label designs can be printer dependent and if you use multiple types of printers, it's best to export the labels with NiceLabel set to every different printer you will use the label with!

Before creating the label, follow these steps to create a dummy printer:

1. Open the »Devices and Printers« in Control Panel, click on any printer and from the toolbar, select Print Server Properties.
2. In the next form, select the Ports tab.
3. Click Add Port…
4. Select Local port and click New Port…
5. For the port name, enter a file name (I use C:\_TEMP for misc. crap, so I put in C:\_TEMP\ZEBRAPRINT.TXT)
6. OK out of everything.
7. Run the installation program for the NiceLabel Printer Drivers and select a printer you would like to use (I have chosen a pretty basic »ZEBRA GC420d ZPL« printer).
8. Select the port you have just created.
9. Finish the installation.
10. Rejoice!

After the printer is ready, open NiceLabel Designer and create a new label, selecting the printer you have just installed. You will get a blank canvas and you can start drawing. I have created the following layout using the Text and Bar code tools:

Label designer

The second text field is a variable field with the variable name LicensePlateId and the same variable is used for the bar code as well. You can design the label with fixed values, but you will then need to change the text in AX. NiceLabel also comes with plenty of out of the box sample labels, including GS1 SSCC label and so on, which can also be used as a starting point.

To get the text version of the label, you can use several options. NiceLabel Designer Pro supports export of templates for use in external systems. First, let's configure the AX specifics for export. Select File – Export – Printer Template Export Configuration and Add a new system. Give it a name (Dynamics AX WHS) and an extension (txt) and in the Variables tab page, enter $[Name]$ in Variables field like so:

NiceLabel Printer Template Export Configuration

This will cause variables used in the label to be exported in the generated file as $VariableName$, which is the format expected by AX when it does its own substitution of variable contents.

After you are done with this definition, click File – Export – Dynamics AX WHS and NiceLabel will create a nice text file which you then copy and paste into AX:

Document routing layouts

Step 3: Configuring document routing

We will use this label as part of the receiving put-away process 24 PO Direct, so we need to configure the document routing record. In the Document routing form, create a record similar to this one:

Document routing

I have used my dummy printer that I have installed on the AOS. Feel free to experiment with other filter values, which you will probably use in production, at least to differentiate to which printer you want to print the label (note to Microsoft: some web browsers can print to locally attached printers that people carry around with them, so printing could also be done via the web interface). Again – to use the printers, AOS will need to be able to print to them. I would strongly suggest using networked printers, not printers connected locally to computers in the warehouse and then shared, at least from experience. It is best to log on locally to the AOS as the AOS service account and check if you can print to the printers.

Lastly, we need to configure the work templates to print the label as part of the process. To do this, insert a Print step in the Work Template. In our example, 24 PO Direct gets another work step:

Work templates

 

The same approach can be used in the Sales order scenario as well, to create shipping labels for the picked license plates.

In case you would like to print your own labels as a part of receiving goods, you can use the "Print label" check-box on Mobile device menu items for several Work creation processes (PO receiving, Report as finished, Load receiving, TO receiving, Kanban). There is also an indirect activity "Reprint label" for later printing of LP labels.

Step 4: Demo

Create a purchase order for some goods and receive it using the mobile device (web or AX form). There will be no visible change from the user perspective, but, if all goes well, the file you set up for the dummy printer should appear and under Inquires – License plate labels, you should be able to see the newly created label. If you open the file using Notepad, it should contain ZPL with LicensePlateId substituted for the actual license plate number:

CT~~CD,~CC^~CT~

^XA~TA000~JSN^LT0^MNW^MTD^PON^PMN^LH0,0^JMA^PR2,2~SD15^JUS^LRN^CI0^XZ

^XA

^MMT

^PW320

^LL0160

^LS0

^FT20,58^A0N,28,28^FH\^FDNalepka:^FS

^FT20,81^AAN,18,10^FH\^FDTESTLP00001^FS

^BY1,3,17^FT20,106^BCN,,Y,N,N,A

^FDTESTLP00001^FS

^PQ1,,,Y^XZ

To see how the label would be printed out, you can use for example the Labelary service. The above example can be rendered using this URL.

Giving a nice result like this:

Printed label

That's it, you are all set to explore this on your own further, and thanks to Boštjan again for providing this comprehensive description of the process.

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