Changing Reservation hierarchy when tracking dimensions are involved

The Reservation hierarchy in Dynamics AX is the thing that enables two-level inventory reservation. Essentially, we get to choose if we want to reserve inventory at Batch and/or Serial level, or not. Once set, changing a Reservation hierarchy has been particularly difficult, especially because often this is being done in combination with a Tracking Dimension Group change.

I knew for an upcoming project that I was going to need to change Items that were set as Batch-only to become Batch & Serial enabled. I had already dabbled with it, and found that you hit a catch-22; you can’t set a serial-enabled Tracking Dimension Group if your item has a Reservation hierarchy which does not have Serial in it…. and, well, the periodic job that exists for changing an item’s Reservation hierarchy did not seem particularly interested to do that for item’s which already have a Reservation hierarchy. (Rather, it worked for items which did not. This might be fine if you’re enabling warehouse management functionality in an environment for the first time, but was no good for me).

It was whilst reviewing a list of recently released hotfixes (as I’m sure you all do) that I spotted KB4022327: ‘You cannot change Tracking dimension group (and Reservation hierarchy) for WHS enabled items’. It’s like it was written for me; how did they know! Although it was released in May, I only just got round to checking it out.

After installing it, I rushed to change the Tracking dimension group of one of my items, and find I am presented with an updated error message:

'use the Change tracking dimension group for items periodic task'

‘You can change the tracking dimension group and reservation hierarchy simultaneously by using the ‘Change tracking dimension group for items’ periodic task’

Change both the Tracking Dimension Group and the Reservation hierarchy at the same time? You spoil me! But where is this periodic task? It’s been added in the Warehouse module (alongside the ‘Change item hierarchy’ job), and you’ll now also find both of these jobs in the Product Information Management module:

The 'Change tracking dimension group for items' periodic job.

The ‘Change tracking dimension group for items’ periodic job.

Opening the job reveals this shiny new dialogue:

ChgTrkDimGrpItm

There are some things that you need to do in preparation for running this job. Things that you would have to do anyway when you change a significant property of a Tracking Dimension Group….

  • You need to make sure that the Products (which are linked to your Released products) do not have a Tracking Dimension Group set. If they do, you can just remove it from the Product.
  • You’re going to need to remove all inventory for the items. After doing that, you might think about doing an Inventory close (and therefore, when you do this for real, you might need to do it at a period end).
  • The job will error if you have any open reservations. When you removed all inventory of the items, you would needed to remove all reservations anyway.
  • The job will error if you have any open receipt transactions. It’s odd that I’m allowed to make this change if I have open sales orders, but not if I have open purchase orders. The very first link I posted at the top of this post says, in relation to changing a Reservation hierarchy, ‘all items must be purchased or sold’. If you decide to leave open sales orders, I suggest that you test that they can still be released/picked afterwards.

After doing these things, the job worked for me on my test items. One less headache to worry about.

Advertisements

New in R3 CU9 – Display a list of open work on the mobile device

CU9 for Dynamics AX 2012 R3 was released last week. It contains a good number of fixes, more than a dozen of which I really need for AX implementations I am involved in. But it feels to me that, when compared to last year’s CU8, it does not contain so much new functionality. Many of the new features are in the Warehousing module, and although two of them are on my ‘must have’ list, they have been available already as hotfixes in their own right.

One enhancement, however, was available first in CU9, and is the topic of this blog post (it has subsequently been made available via hotfix KB.3062537). It is the ability to create a menu of open work on the mobile device, allowing the operator themselves to choose what to do next. To configure it, head into the ‘Mobile device menu item’ setup form. The eagle-eyed amongst you will notice two new buttons in the action pane (both greyed out) labelled ‘Edit query’ and ‘Field list’:

Two new buttons appear on the menu item setup form

Two new buttons appear on the ‘mobile device menu item’ setup form

If you create a new menu item, and set ‘Mode’ to ‘Indirect’, you’ll find a new ‘Activity code’, called ‘Display open work list’, is available:

WorkListMenuItem

A new Activity code is available

Selecting this activity code causes the two new buttons to become available. Let’s have a look at this on the mobile device, and then we’ll come back and look at how we can configure it. In the screenshot below, you can see seven instances of work are shown, along with a little information about each:

WorkList

The work list on the mobile device

The operator can select some work to do, by clicking on the relevant Work ID. They can also scroll the further down the list (only the first 7 of 14 work items are shown in my screenshot), and they can click on any column heading which is highlighted in grey to re-sort the list.

To configure what is displayed to the operator, we have four options:

1. The operator must already have permission to access any work shown by means of another menu item. This means if a user has access only to menu items which allow ‘Inbound’ type activities (Purchase order receiving and put away, for example) then they will not see any work related to replenishments or sales order picking. You don’t need to do anything particularly to configure this – it just works based on what menu items they already have access to. What’s more, these menu items must have ‘Directed by’ set to ‘User directed’. i.e. they must already be configured to allow the user to select what work to do next. If the operator has access to pick Sales orders, but the menu item is configured to System directed (i.e. it is configured so that AX is telling the user what to do next), they are not going to be able to come into this work list and decide for themselves what Sales order to pick next.

2. As with other menu items, you can select which class work that appears on the list must have (and selecting no class means the list is not filtered by work class):

WorkClasses

Menu item work classes

3. The ‘Field list’ button allows you to define which columns are shown on the screen of the mobile device. Up to eight fields can be shown. The first is always ‘Work ID’, and is mandatory. The other fields that you can select come from WHSWorkTable and WHSLoadTable. WHSWorkTable contains the Work header, and can be seen on the ‘All work’ list page. WHSLoadTable contains the Load header, and can be seen on the ‘All loads’ list page. Any field that you think is useful from the Work or Load can be shown on the list. In addition, two ‘display method’ type fields can be added. These show either the location on the first Pick line of the work header, or the location of the last Put line. Since these two fields are display methods, they cannot be filtered or sorted on. The data actually comes from the work lines, and any intermediate locations (e.g. staging locations) cannot be displayed.

FieldList

Select which fields should be displayed

4. The ‘Edit query’ button has two uses. It can be used to filter the records shown in the list. Any field on the Work and Load headers can be used. It also allows you to define the default sorting order of the list (and if you do nothing, the list will be sorted by Work ID in ascending order).

Two more fields exist on the menu item setup form. The first allows you to define how many work headers should be shown on each ‘page’. If there is more work than can fit onto the page, the operator will be able to click on ‘Previous’ and ‘Next’ buttons to scroll through the list. This field, in combination with the number of columns that you choose to display, allows you to configure the data that is displayed to fit onto the screen of your mobile device, although Microsoft themselves recommend displays which are at least 7″ in size.

The ‘Allow users to filter by work transaction type’ tick box adds a drop-down above the list, which allows operators themselves to filter the list (beyond any filtering you may have already created for them):

FilterWorkList

The work list can be filtered by the operator

When the user chooses some work to do, the mobile device switches to the relevant menu item (that the user already has access to) to complete the work. If the user has more than one menu item which could do the work, they are asked which they would like to use:

ChooseMenuItem

The user may be asked to select which menu item to use

Although not particularly suitable on the traditional hand-held barcode reader type devices, I am sure that users in some warehouses will find this functionality useful: where system directed cannot be used, it eliminates the need for printing Work lists and scanning Work IDs. As is the case throughout the Warehouse management module, so much of this functionality is configurable. In that way, it is limited partly by your imagination. In my example, I showed only and small number of fields on the list. It is possible to allow the operators to see (and perhaps crucially, sort or filter on) any number of fields. For example, the scheduled ship time (from the Load) can be used to ensure orders which are to be delivered first are picked first. The Sales order number can be shown, which, to my knowledge, allows the operator to select work by sales id for the first time.

If you want to read more about it, the TechNet site has been updated here (under ‘Setup a menu item for activities and queries’). And the product team have written about it on the AX SCM blog.

Location directive failures in Warehouse management module

This is a quick post about ‘Location directive failure’ functionality in the Warehouse management module in AX 2012 R3. It’s not covered in the Warehouse management implementation guide, and is not mentioned on the TechNet pages either, and therefore worth writing about.

The functionality can be configured in the Warehouse management parameters form, or using it’s own setup form at Warehouse management -> Setup -> Work -> Location directive failures. It doesn’t matter which one you use; you’re setting up the same thing.

LocationDirectiveFailures

Setup Location Directive Failures

It is possible to configure Location directives for several different Work order types. Location directive failure functionality can be enabled or disabled separately for each of these Work order types. Ticking the ‘Stop work on location directive failure’ tick box enables the functionality. Un-ticking it disables it, and is the same as not creating the record in the form.

To demonstrate the effect of this functionality, I will create some Work for a Sales order with ‘Location directive failures’ for Sales orders turned off.

LDF_Off

Location directive failure is disabled for Sales orders

In the scenario, there is 209 of item A0001 in inventory, but only 100 in the picking location (FL-001).

ScenarioStock

The scenario with item A0001

I have configured the location directive to use only the Picking location, and Wave demand replenishments are not enabled. Therefore, AX can only create picking work for quantity 100. A sales order for quantity 150 is created, and released to the warehouse. The Wave is processed and released. The work that is created has two pick lines and one put line. One pick line is for quantity 100 from the picking location (FL-001). The other pick line is for the remaining quantity, and has no pick location. The put line is for the full 150.

WorkWithBlankPick

Pick work with a blank location

If I roll back the scenario, and re-run it with Location directive failure enabled for Sales orders, we get a different result. The first indication comes from the Infolog produced when the order is released to the warehouse: ‘Shipment was not fully allocated’.

InfoLog

Shipment was not fully allocated

If we look at the generated Work, we can see the effect.

NoBlankPick

Effect of Location directive failure

This time, only one pick is created. It has the quantity 100. The put also has the quantity 100. What of the remaining 50? If the Work is processed through, 100 become Picked and 50 remain on the Load/Shipment. It would be necessary to add the 50 to another wave, and in my scenario I would need to do something (i.e. replenishment the Pick location) before the wave could be processed.

So we can see that the Location directive failure determines what happens when the location directive fails to find a valid location. If the functionality is disabled, work with a blank location is created. If the functionality is enabled, work is only created when a location can be found. Obviously, it’s up to you whether to enable it in your environment, and on which work order type to enable it.

In the case of a sales order, you might want to switch it off. You know the sales order can’t be released to the warehouse unless the inventory is available for reservation. Therefore, a Pick instruction with no location will force the warehouse worker to hunt down the required inventory knowing it is available somewhere.

But in this post on the AX Community forum, you can see a scenario where the functionality is disabled, and a Min/Max replenishment is created to replenish a pick location with a quantity that does not exist in the warehouse. In this scenario, isn’t it better that the replenishment will only use inventory that is available?