Posted on behalf of Lars Frandsen.

Introduction

Many distribution centers are seeing order profiles trending toward smaller orders with fewer lines, and lower quantities per work line. This leads to distribution centers being tasked with the piece pick process, which is also known as broken case or less-than-case picking.

The piece picking process is one of the most complex and labor-intensive processes for picking orders. To reduce travel time in the warehouse, multiple orders can be grouped into small batches.

Usually the picker will use a multi-tiered picking cart, and maintain a separate tote or carton on the cart for each container on a sales order.

In Microsoft Dynamics AX 2012 R3, cluster picking functionality supported the piece picking operations described above.

To support a piece picking operation zone in the warehouse, the work order needs to match the content of a tote or carton

This blog describes how to utilize the containerization wave method to calculate the type of container that will be needed, the items and quantities that go into each container, and the number of containers needed for each sales order. This blog will also outline the process of combining the containers with work breaks to create picking work for each tote or carton on the cart, and then group the work into pick clusters.

Note:

Different piece picking methods can be selected to reduce the cost of each type of picking operation. This blog does not provide an exhaustive list of piece picking methods. They can be found by searching the Internet for piece picking methods.

Depending on the source, you will find that the terms cluster picking, batch picking, multi-order picking, and cart picking are used interchangeably.

This blog uses the definition of cluster picking that can be found in this publicly available white paper, on this website, and in this compendium.

Suggested reading

A blog post on containerization has been created, it is expected to be familiar with the area:

http://blogs.msdn.com/b/dynamicsaxscm/archive/2014/07/26/introduction-to-containerization-automated-packing-process-in-microsoft-dynamics-ax-2012-r3.aspx

Other details about the topics that are covered in this post can be found by using the following links:

Set up containerization [AX 2012]
Read: http://technet.microsoft.com/EN-US/library/dn553190.aspx

Create a wave template [AX 2012]
Read: http://technet.microsoft.com/EN-US/library/dn553177.aspx

Set up cluster picking [AX 2012]
Read: http://technet.microsoft.com/EN-US/library/dn553213.aspx

Create a work template [AX 2012]
Read: http://technet.microsoft.com/EN-US/library/dn553184.aspx

Set up filters and filter groups [AX 2012]
Read: http://technet.microsoft.com/EN-US/library/dn553176.aspx

Scenario overview

Contoso DC distributes goods directly to a chain of retail stores. The retail stores must order full cases.

However, Contoso DC also manages the fulfillment of orders received from the chain's Internet shop. The typical customer in the Internet shop is a consumer, and the order profile is typically a sales order with a few lines and less-than-case quantities. Therefore, Contoso DC has dedicated an area of the warehouse to the picking and packing of these orders. The cluster picking method is used in this area.

Contoso DC sells electronic parts, including computer parts that are easily damaged. Computer parts need to be picked with care into separate boxes.

At the same time, Contoso also sells other products that are packed into standard cardboard boxes.

Setup

Before starting the scenario, make sure that you have a warehouse that is set up to use Warehouse management processes, and all related setups are in place so that a sales order can be released to warehouse and work can be created. Entities such as a wave template, work template, mobile device menu structure, and so on, will be updated in this scenario.

The setups for this scenario include the following:

1. Set up filter codes
2. Set up a set of items, including physical dimensions
3. Set up a container layout and container build structure
4. Set up a wave template and a work templates
5. Set up a cluster profile for the mobile device

We will complete these steps, and then test that we can create a sales order and that work is created as expected (step 1 through 4). Then we'll create cluster picking structure using the mobile device and to complete scenario (step 5 and 6).

Step 1: Setup Filter Codes

To open the Filters form, use the following path: Warehouse management> Setup> Filters> Filters.

Items must specify physical dimension as well as filter codes. Add two codes to the Code1 filter field, as shown in the following illustration.

Note: Remember to set up a filter wildcard in Warehouse management> Setup> Warehouse management parameters before attempting to set up filter codes on products.

Filter codes for products are set up under Product information management> Common> Released product> Warehouse management FastTab.

Step 2: Set up a set of items, including physical dimensions

We then find or create products accordingly. You will start from the Released products list page. To open the list page, use the following path: Product information management> Common> Released products.

We will need to configure three products for the scenario, as described in below table. You can use existing products or create new products as appropriate.

The filter codes for the products are set on the Warehouse Management FastTab.

The physical dimensions button to open the dialog is located on the Manage Inventory tab.

Finally, add on-hand quantities of these items in your warehouse.

Moving on to set up the boxes to pack goods in, the packing container will use following settings.

Step 3: Set up the container layout and container build structure

All of the boxes used in this example have the same size and weight properties. We define one type of container to represent this.

The tare weight of the container is 1, and it can hold a maximum weight of 21. Note that when entering data on the form the "Containerization maximum volume" field is not auto-populated. For this example we'll enter the maximum value of 21 (LxWxH). To open the Container type form, use the following path: Warehouse management> Setup> Containers> Container type.

Containers are logically grouped into container groups. We'll need one container group for this example. A piece pick container can only be filled to 50%. Transportation is hard on the items, and they want to make sure they have plenty room for bubble wrap and other forms of protective packaging.

To open the Container groups form, use the following path: Warehouse management> Setup> Containers> Container groups.

Enter the values as shown in the illustration above, and then click Close to close the form.

Container build templates are used as rules for the containerization process when creating work. For example, they're used as inventory mixing rules and other packing strategies. To open the Container build templates form, use the following path: Warehouse management> Setup> Containers> Container build templates.

Again, we need only one template for this scenario. The setups are the same for all items.

Note the Wave step code (1). This is a crucial value for linking this template to the wave template that we use to create work.

Sorting on this form is used to group the sales lines before applying the settings on the container build template. The temporary work transactions are correctly grouped when the wave is processed, which is the key to success when working with containers.

For this simple example, we will first sort the temporary work transactions using the field Code 1 in the warehouse item table, the field Shipment ID on the temporary work transaction, and then by Location. The sorting controls the optimal creation of containers.

In the Container build template form, click Edit query. Configure the query as shown in the illustration below. Do not change the default values on the Range tab.

We can now specify how we want the containers to break. Because we need to place the sensitive items in separate containers, we need to break by Filter Code.

In the Container build template form, click Mixing Logic Breaks to open the and create a new break by assigning filter Code 1, as shown in the illustrations below.

Close the dialog boxes and the form. We have now completed our setups for containers.

Step 4: Setup wave and work templates

To invoke the wave containerization logic you need to add the containerization method to the wave template. This is where the Wave step code (1) assigned to the Container build template above is put to use. Select the shipping wave template for your warehouse, and update it as shown below. To open the Wave template form, use the following path: Warehouse management> Setup> Waves> Wave templates.

Now we can update the work template. As with the container build template, we will group and break the work that is created so that each contanier is linked to one work order header. In other words, we must break work into each seperate container.

First, find the work template that you use for sales orders in your warehouse. To open the Work templates form, use the following path: Warehouse management> Setup> Work> Work templates.

Click Edit query and create sorting by Container ID, as shown in the illustration below. Do not change the default values on the Range tab.

After the sort order is defined and the query is saved, the Work Breaks button is available on the Work template form.

Set up the grouping as shown in the illustration above. Make sure to select the Group by this field check box.

Step 5: Setup cluster profile for the Mobile Device

We're almost there! We now only need to configure a menu item for the mobile device so that we can use the device for cluster picking processes in our warehouse. To open the Cluster profiles form, use the following path: Warehouse management> Setup> Mobile device> Cluster profiles.

First we'll create a cluster picking profile using the values shown in the illustration below. You can define sorting for the cluster profile by clicking Set up cluster.

Close the Cluster sorting and Cluster profiles forms.

This cluster profile must be associated with a mobile device menu item that is configured to use existing work. To open the Mobile device menu items form, use the following path: Warehouse management> Setup> Mobile Device> Mobile Device Menu Items.

Create a menu item for Cluster Picking. Use the cluster profile that we just created, and the remaining settings as shown in the illustration below.

Finally, we need to add this menu item to the main menu for the mobile device. This will enable the warehouse worker to perform cluster picking. To open the Mobile device menu form, use the following path: Warehouse management> Setup> Mobile Device> Mobile Device Menu.

Execute the scenario

Now we can test the setup and execute the scenario. The sequence is as follows:

1. Create a sales order and release to warehouse to create work.
2. Verify the created work and containers.
3. Build a cluster picking structure by using a mobile device.
4. Verify the cluster picking structure and view the status of work.
5. Execute picking work.
6. Repeat step 4, and validate that the work is complete.

After step 6 has completed, the cartons are ready to be shipped.

First, create a sales order with three lines, as shown in the following table.

Reserve and release the order to the warehouse. Here's a tip. If you set the reservation to 'Automatic' on the Accounts receivable parameters form, you don't have to reserve each of the lines manually. This will save some time when you test your setup.

So what should happen? Our containers can hold physical dimensions 10 and weight 10, so we expect the breaks to split this into four containers.

Let's verify that work and containers are created accordingly. First, open the Shipment details for the sales order. This can be done from any of the order lines, as shown in the illustration below.

The container structure is displayed on the Transportation tab.

We expect to have one work header for each container. You can view this on the Shipments form by clicking Work details on the Shipments tab.

Note: Because each item is stored in a different location, the last container must be picked from two locations. We want to optimize the picking process to avoid returning to the same location twice. In this case, we might have to revisit the location of product HDMI Cable 12', depending on how the work gets directed to the warehouse worker. To optimize this, we will use the Cluster picking feature.

Now we are ready to continue the next steps of the scenario. First we build the cluster picking structure (a set of boxes to pick to) and assign the work orders for each. Because you are trying this out in a test environment, you will have access to the work IDs directly in the rich client. You can copy the field value of the work ID and paste it into the mobile device.

Typically, the warehouse worker will not have access to the rich client. Instead, he or she will be using a handheld scanner to create the cluster picking structure. This can be done by scanning from a printed report, for instance the Work report.

Printing this report can be done via a batch job, so that all open piece picking work is available in the morning to start executing. Also, each of these reports can then be attached to or placed in the corresponding box and follow the goods throughout the remaining processes. To open the Work form, use the following path: Warehouse management> Reports> Work.

To print the relevant work on one page per container, use the Work report and set up the query to print only work that has not been started (work status: Open).

The report includes one page for each work order header.

With the work ID available, we can start building the clusters and performing the work. Open the mobile device and go to the menu item Cluster Picking. The steps in the cluster picking process are as follows:

1. Build the cluster structure.

1. Complete picking of all items.
2. Complete put work of all clusters in one action, and complete the work.

To build the clusters you enter or scan the work ID for each box. In our case we have four containers and work IDs.

Click Done after assigning all positions.

At this point the cluster picking structure is created and can be viewed by using the following path: Warehouse Management> Inquiries> Work clusters.

On the mobile device, the next screens will ask you to pick the items. Notice that the picking is done by location and not by work ID. In this simple example, we have sorted the locations by their ID in ascending order. This is highly customizable. Also notice that at some point we will be asked to pick all 7 of the HDMI 12' Cables and then sort them into two containers.

As the warehouse worker puts the items on the cluster pick cart, the positions must be validated to ensure that the correct quantities go into the correct box (this was enabled when configuring the cluster profile).

Notice that all picking work for this specific item is completed while the warehouse worker is physically at the location. The positions are in this case are equivalent to boxes that we pick items into. We confirm that five items go into Position 3 and 2 go into Position 5.

When we complete the rest of the picks, we will end up on the final put screen, where we are instructed to put all items at the Baydoor location.

After clicking OK, a message confirms that picking is completed for the cluster.

If you open the Work clusters form again you will see that it is empty. This is because all work has been completed. Click Show closed work to see the work we have completed.

THE END

Authors:

Lars Frandsen, Senior software engineer

Karina Normann Jakobsen, Senior program manager

The Transportation Management (TMS) module that shipped with Microsoft Dynamics AX 2012 R3 includes a number of engines that are essentially implementations of strategies for calculating rates, distance, transit time, and other data related to transportation of goods. Some of the most wanted implementations retrieve data from online services. Due to release policy management, it was not possible to ship these engines – even as examples – therefore none of these are included in Microsoft Dynamics Ax 2012 R3. In one of the earlier blogs I described how to create a mileage engine based on Bing Maps. In this blog I will describe a few more.

Part of the solution that we acquired contained rate engines that retrieve rates from the following service providers:

• FedEx
• UPS
• ConnectShip Toolkit (through Progistics AMP)

Additionally, the solution included a mileage engine that retrieves mileage data from the PCMiler system.

These engines won’t be available in an upcoming release, so to allow our partners to leverage existing work, we’re making them available to the partner community through PartnerSource. The source code can be downloaded for you to test to determine if it suits your needs. Please be aware that the code is not in production state, and will require customizations in order to work. In this blog post I will explain the steps that are needed for installing, debugging, and making the code ready for testing. Moreover, I will also explain how to retrieve and record the shipping labels directly from the provider (UPS) without the need to synthetize the label structure locally in AX.

Please follow the link below to download the source code from PartnerSource:

https://mbs.microsoft.com/partnersource/northamerica/support/hot-topics/msdax2012R3transtmgmteng 

Disclaimer

• These private projects are not an officially supported fix from Microsoft. This is an as-is proposal intended for customer test purposes only.
• Customers must deploy and test these private projects in their test own environment. These private projects should never be deployed in a customer’s production environment.
• Customers must ensure that these private projects and related code be removed from their test environment after testing is finalized.
• Microsoft is not liable for any consequential damage from the deployment of any of these private projects.

Installing the initial third-party integration code to AX

In this section I’ll describe how to retrieve the sources of the engines for integrating with the specific services that were mentioned earlier. We will make sure that the code is compiled and available for utilization by the AOS process.

1. Ensure that your AOS configuration allows debugging and enables hot-swapping of assemblies for each developer session.
   
2. Download the third-party engines sources from PartnerSource.
3. Unzip the sources in your working folder.
4. Ensure that you have Visual Studio tools for Microsoft Dynamics AX installed (depending on your upgrade state you may need Visual Studio 2010 or Visual Studio 2013).
5. Start Visual Studio and open the solution file for TMS.ThirdParty.Parcel (located under [working folder]\C Sharp Projects\TMS.ThirdParty.Parcel\TMS.ThirdParty.Parcel.sln). After completing this step, in your Solution Explorer you will see the following 5 projects.
   
   Note that the projects are originally developed in Visual Studio 2010. If you’re using Visual Studio 2013, the solution will be upgraded.
6. In your solution you will notice that for each of the projects there are project-to-project references to Microsoft.Dynamics.AX.Tms. These are broken because the referenced project is missing in the solution.
   
   In order to fix this, you need to add the missing project from the Application Explorer. To do this, follow these steps

• In Application Explorer navigate to the following project:
  \Visual Studio Projects\C Sharp Projects\Microsoft.Dynamics.AX.Tms
• Open the context menu and choose Edit.
• The project is now added to your solution, together with the 5 other projects. You can see that the references are now fixed.

• TMS.ThirdParty.Parcel
• TMS.ThirdParty.Parcel.Fedex
• TMS.ThirdParty.Parcel.Progistics
• TMS.ThirdParty.Parcel.Ups
• TMS.ThirdParty.Parcel.PCMiler

Deploy the solution to the AOS. Select Deploy solution from the context menu on the solution node in Solution Explorer.
When you start the AX client and open AOT, you will see that the following projects, together with updated project outputs (containing dll’s) are in the AOT under \Visual Studio Projects\C Sharp Projects).

Enabling the new engines in Microsoft Dynamics AX

In this section we’ll go through the steps needed to enable the new engines in AX, so that they can be utilized in the Rate shopping scenario (and other related scenarios as well). The goal here is to bring the environment to the state in which you will be able to start debugging and developing the missing pieces of code to make the engines fully operational.

1. Open the Rate engine form (Transportation management > Setup > Engines > Rate engine) and create a record for each of the rate engine classes that you installed.
1. The Engine assembly should have the full name (with extension) of the dll file specified for each of the rate engine projects.
2. The Engine type should contain the fully-qualified name with the namespace of the class that implements IRateEngine
   
   You can create the following records for the 3 rating engines deployed in the system.
   
   Rate engine: ThirdParty.Ups
   Rate base type:<empty>
   Name: UPS online
   Engine assembly: Tms.ThirdParty.Parcel.Ups.dll
   Engine type: Tms.ThirdParty.Parcel.Ups.UpsWSRateEngine
   
   Rate engine: ThirdParty.Progistic
   Rate base type:<empty>
   Name: Progistics online
   Engine assembly: Tms.ThirdParty.Parcel.Progistics.dll
   Engine type: Tms.ThirdParty.Parcel.Progistics.ProgisticsRateEngine
   
   Rate engine: ThirdParty.FedEx
   Rate base type:<empty>
   Name: FedEx online
   Engine assembly: Tms.ThirdParty.Parcel.Fedex.dll
   Engine type: Tms.ThirdParty.Parcel.Fedex.FedexWSRateEngine
   
   
2. For each of the rate engines created in previous step you need to define RateWSUrl, ShipWSUrl and VoidWSUrl parameters. Each of these parameters defines the URL, which points to the service endpoint specific to particular carrier operation (Rate, Ship or Void). You should be able to find the proper URLs on the particular carrier (for instance UPS) web site. In Rate engine form, for each of the engines open the Engine parameter form, by clicking the Parameters button. See the following screenshot for reference (you need to replace the values in the Parameter value column with appropriate URLs):
   
3. Open the Mileage engine form (Transportation management > Setup > Engines > Mileage engine) and create a record for the PCMiler mileage engine:

• The Engine assembly should have the full name (with extension) of the dll file specified for the PCMiler project, which is Tms.ThirdParty.PCMiler.dll.
• The Engine type should contain the fully-qualified name with the namespace of the class that implements IMileageEngine, in particular Tms.ThirdParty.PCMiler.PCMilerMileageEngine.

Now, let’s create a carrier that utilizes one of the new rating engines (Transportation management > Setup > General > Shipping carrier). For this example enable UPS engine. To do this, create a new carrier with one valid service record and one rating profile. The engine does not require any data from AX for rate calculation, therefore you do not need to associate any Rate master with your rating profile. Your carrier setup should look like the following screenshot.

You can also enable the Mileage engine for consumption. If you initialized the TMS module (by clicking the Initialize base engine data button on the Transportation management parameters form), you’ll find the P2PMileage rate engine in the list of the rate engines defined on the Rate engine form. Out of the box that engine uses the P2P mileage engine. For the sake of testing, you can swap the P2P engine with the PCMiler engine by modifying the MileageEngineCode parameter. The value of the parameter should be the value of the Mileage engine key specified when defining the PCMiler engine in step 3. In this case it was P2PMileage, and the setup should look like this.

You should now be able to exercise the engines that you just enabled, and start the debugging session. Attach debugger to ax32serv.exe process. Set a breakpoint on the first line of the Initialize method on UpsWSRateEngine class.

If you execute the Rate shopping operation, you should be able to hit the breakpoint. To do that, open the Rate route workbench form from a Sales Order and click the Rate shop button.

Updating the source code of the UPS engine

If you let the debugging session continue, you will end up with exception being thrown inside the UPSService class. The web request cannot be processed because a few things are missing. In this section I’ll explain the parts that we know are broken for the UPS engine and need to be fixed by you in order to get things working. Don’t panic. The changes are less complicated than it may seem. My advice is to fix one thing at the time and repeat the debugging session after each completed step. After you are able to retrieve rates, you may choose to close a container and see if you can make the Ship operation work (see the next paragraph). This section concentrates on the UPS engine, but a similar approach should be taken for completing the integration with the FedEx engine, and the two other remaining engines.

1. Authentication data needs to be provided. After obtaining the account for accessing the web services on the UPS website, you’ll receive an account number and access key. You will also note the user name and the password needed to access the service. If you look a little bit further in the Rate method of UPSService, you will find the following block of code.
   
   Here, we are passing the security related data, which is needed to authenticate the request to the UPS web service. In the current state of the sources, the SecurityInfo object is not initialized. You will need to ensure that proper security data is provided. In your development exercise you may simply hardcode the authentication data. However in the final solution it should probably be loaded from the UI/data base. You can implement your security data assignment in the SeedSecurityData method on the BaseParcelRatingEngine class. Remember to threat model this part of the system when you design your final solution.
2. You are now able to step through the actual request. Your first response from the UPS system will fail because you may be missing some basic information, such as phone numbers. The response object will contain the developer friendly error data, which you can use to complete a valid rating request.

Closing a container and printing shipping labels

If you set the Activate carrier rating flag on the shipping carrier, you will enable the special type or rating processing that results in calling the Ship method on your parcel service. After packing your goods on the Pack form (Warehouse management > Common > Pack), upon closing the container you will call the TMS managed system to update the rates and ship the package. In addition to assigning the tracking number, one of the most important outcomes of this call is the retrieval of the shipping label data. Out of the box the code is configured to retrieve the data in ZPL format. If your bar code printer can interpret this format correctly, you will be able to print the shipping labels recorded directly from the carrier service, without building their structure. In the AddPackageCharges method of the BaseParcelRatingEngine C# class, you will find a line of code that packages label data retrieved from the service into the XML response of the TMS managed system.

This data is interpreted by the TMSProcessXML_Container X++ class. In this class you will find a number of methods that record data based on the XML response from the TMS managed system. In particular you will find a readShipContainer method, which at some point updates the tracking numbers in the WHSContainerTable table. This is the point at which you should consider additional customization of X++ code:

1. Add a ShipLabel field to WHSContainerTable, of type string and set the StringSize to (Memo).
2. Assign the ShipLabel field to WHSContainerTable when processing data in \Classes\TMSProcessXML_Container\readShipContainer method. You can use following line of code to retrieve the label data:
   this.returnNamedNode(rateNode, 'LabelData');
3. Add a button on the Containers form to print the labels. You can call the following static server method to print labels:
   \Classes\TMSCommProxy\printLabel
   The first parameter identifies the printer available to AOS, the second parameter is the value of the ShipLabel table field on WHSContainerTable that was recorded earlier.
4. You may consider further modifications that will let you print the labels automatically when closing containers.

Conclusions

We’ve gone through some basic steps needed to initiate the development work related to the third-party carrier integration for TMS. We’ve also looked into the UPS integration. I will not go through the other engines in detail, but they should require similar conceptual work in order to get enabled.

The code that you are working with is not exactly in a plug-n-play state. It requires some developer skills in order to execute properly. However, we worked with a pilot team that followed the implementation process in this blog and within a few days they were able to enable the UPS rating with shipping label printing. We believe that similar effort is required to get the FedEx integration to work.

We have not had have time to assess the state and quality of ConnectShip and PCMiler integration. We are however including the sources as well, so that you can work on incorporating these into your systems if desired.

When working with the code, remember the following tips:

• If you see that you cannot hit the breakpoint, it may mean that your assemblies on the AOS are out of sync with the assemblies (and pdb files) in the build output folder in VS. In that case, you need to re-deploy the solution and restart AOS.
• Threat model your solution. Remember that URLs and security data need to be treated as secured resources.
• Always ensure that when debugging you are using test access to the actual web services. You definitely do not want to see a big UPS truck waiting in front of your software development offices the day after your debugging session, simply because you stepped over their service call a couple of times, while executing this tutorial.

Dear readers

The SCM-costing team in collaboration with SCM-Procurement team are happy to introduce a capability requested by customers for many years.

We introduce the capability of accounting for Misc. charges already at time of posting Product receipt.

This capability will provide customers with the opportunity to better estimate cost of purchase and avoid cost fluctuations at time of Invoice.

Configuration:

As this capability directly impact valuation of inventory assets and thus can be considered a change in accounting principle the feature will be controlled by a new parameter.

Path: Procurement and sourcing/Setup/Procurement and sourcing parameters

Note: In next major release of Microsoft Dynamics AX this capability will not have its own parameter but will be controlled by the Accrue liability on product receipt parameter on the Item model group.

We recommend the following parameter settings for accounting of inventories. Applying these recommended settings will make reconciliation to General ledger much simpler at end of fiscal period.

 Note: If you want to account for Misc. charges at time of posting product receipt and has checked marked “Generate charges on product receipt” you must as minimum also check mark “Post physical inventory” and “Post product reciept in ledger”

Defining Misc. charges:

Before the Misc. charge will be accounted at time of posting product reciept it has to fulfil certain requirements.

Misc. charge code:

The Misc. charge code has to be configured so it will be accounted as Inventory asset.

In Fast tab Posting under field group Debit the Type has to be Item. The Credit type can be either Ledger or Vendor.

Misc. charge calculation categories:

Not all Misc. charge calculation categories will post at time of Product reciept. The table below list the Misc. charge calculation categories applicable and how the value is calculated.

*Proportional: A new Misc. charge calculation categories delivered as part of the feature

Note: Misc. charge calculation category = Fixed. No cost will be accounted for at time of posting Product reciept. The cost will still be accounted for at time of Invoice.

Note: Sales tax on Misc. charges will not be posted at time of product reciept.

Auto charges:

Auto charges will now be applied on time of Product receipt if records correspond to the rules defined above.

Example:

Prerequisite for the example:

Item: Misc. charge D1

Valuation method: Moving average

Auto charge: 10.00 Category = Percent

Misc. Charge: 200.00 Category = Proportional

Indirect cost: 1.00 % on purchased price + Misc. charge cost

1. A purchase order of 10 pcs. is created. The unit cost is agreed at 100.00

2. Adding Misc. charge manually

3. Allocate the Misc. charges

4. Confirm PO

5. Post Product reciept.

• Because of insufficient stock at the supplier a
  partial delivery of 5 pcs will be received

• Select “Receive now quantity” in field Quantity

Press button Charge: The user can validate the Misc. charges calculated by the system for the specific Product reciept prior posting.

Line net amount = 5 * 100.00 = 500.00

Charge code 04: 500.00 * 10% = 50.00

Charge code INS: 5/10 * 200.00 = 100.00

Press OK to post Product receipt

6. Validating posting of Product reciept

Purchase cost transactions

Validating the voucher

Validating the physical cost amount on Inventory transaction

 
7. Post a Product reciept of the remaining 5 pcs.

• The postings are identical with the above

 8. Post Invoice of all 10 pcs and validate postings

1. The system will automatically reverse the Misc. charges postings done at time of
   Product reciept.
2. The system will automatically apply the same Misc. charges codes at time of Invoice
   1. New calculations will be performed as the base
      amount (Unit price) could have changed
   2. Additional Misc. charges code can be added

For simplicity in this example no change in unit price or additional Misc. charges are added

Voucher of Invoice

Note: You will see a few 0.00 postings in the voucher. These are related to a current limitation in posting engine and will be addressed at a later time. The postings are not effecting any balances in General ledger.

Inventory transactions after invoice

Released versions:

The feature will be made available for following releases of Microsoft Dynamics AX.

• Microsoft Dynamics AX 2012 R3
• Microsoft Dynamics AX 2012 R2 (This will beavailable at later time)

Posted on behalf of Karina Normann Jakobsen.

Introduction

Many industries require the shipper to provide documentation to the carrier and the customer about the packing structure of the items that are being shipped. It is also common to receive items packed in shippable cases and distribute them to customers without adding any value other than the labelling of the case.

However, in Microsoft Dynamics AX 2012 R3 there's no record of how a quantity of an on-hand inventory item has been packed. AX only records the inventory quantity in the unit of measure associated with the inventory item, and not in the unit that is used to pack an item.

AX does support the recording of inventory on-hand quantity in packing units like a case if a separate license plate is recorded for each case. However, such detailed record keeping of cases may be impractical for many companies.

This blog post explains how AX can support a case picking operation in companies where no record is kept of license plate information for the inventory on-hand of an item, by creating a container per case. It also explains how the packing structure for a shipment can be mimicked by the creation of a nested container structure for a shipment or load during wave release, and how a label can be printed per case with correct configuration of work break.

Suggestion reading

This blog post does not describe wave containerization and label printing in detail because this is already described in previously published blog posts. To understand the details behind the flow described in this blog post you should also read the following blog posts:

http://blogs.msdn.com/b/dynamicsaxscm/archive/2014/07/26/introduction-to-containerization-automated-packing-process-in-microsoft-dynamics-ax-2012-r3.aspx

http://blogs.msdn.com/b/dynamicsaxscm/archive/2014/07/27/how-to-build-a-multi-level-container-structure-using-containerization.aspx

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

Scenario

Background

Contoso Juice distributes orange juice. The supplier of the orange juice packs the juice into shippable cases, which Contoso Juice receives and puts away directly.

Contoso Juice wishes to record the inventory on-hand quantity in eaches. They do not want to record a license plate ID for each case of juice.

Contoso Juice's power position in the supply chain is relatively weak. Their main customers are large retail chains and these retailers dictate that the order unit for juice is eaches, and they will not restrict themselves to order quantities which can be directly converted into full cases. This means that Contoso Juice sometimes needs to break a shippable case to support single piece picking.

Contoso Juice has a very strict division of zones in the warehouse. Separate zones are used for storage of cases and eaches. Different types of equipment are needed for picking in each of the zones and warehouse workers are assigned to work in one zone at the time.

Therefore, Contoso Juice wants the following rules applied:

1. Cases are picked from the case zone.
   1. The worker will pick one case at a time.
   2. A label will be printed per case.
   3. The worker puts on the label on each case.
2. Quantities that are less than a full case are picked from the broken case zone.
   1. Workers pick directly into a shippable container.

Story

Contoso Juice has received a sales order for a quantity of 21 eaches of orange juice. They will deliver the shipment in 3 containers:

• 2 cases will be picked from the case zone, and each of these will have a label added during picking.
• 1 each will be picked from the broken case zone and put into a shippable container during picking.

All 3 containers will be finally placed on a pallet, and wrapped and shipped as 1 unit.

The steps carried out in AX

The sales clerk has registered the sales order in AX:

The sales order is confirmed with customer and released to the warehouse.

One load line is created, then one shipment, then one load, then one wave, and then the wave is released.

The expected packing structure of the entire shipment/load is represented as one container structure:

To print a label per picked case, 2 work orders are needed for the case picking zone:

To be able to assign the pick in the broken case zone to a worker assigned to work in that zone, one work order needs to be created for that zone:

The warehouse worker working in the case zone logs into the mobile device and starts the picking.

Now the 2 work orders for the case picking zone are closed:

This is also represented in the container structure for the load:

Every time a license plate label is printed a record is stored:

This makes it possible to reprint the labels.

In principle, the work order for the piece picking area will need to be performed as well, but it is not relevant for this example.

Behind the scene.

This steps described in this blog use the content of the Directive unit (DirectiveUOM) and Directive quantity (DirectiveQty) fields in the Temporary work transactions (WHSTmpWorkLine) table to create a container (WHSContainerTable) per quantity 1 of the Directive unit.

What determined the value in Directive unit and Directive quantity?

The Directive unit and Directive quantity are populated in the temporary work transactions after the wave method allocateWave has completed.

The sequence of the methods is fixed. AllocateWave is always completed before containerization is performed.

AllocateWave consults the location directives in order to analyse the demand quantity of an item from a load line so that it can determine the location(s) to pick the demand quantity from. Depending on where the current on-hand of the item is placed in the warehouse, the setup of the location directives and the setup of policies for handling of units for a released product, the outcome of the AllocateWave can be one or more temporary work lines (WHSTmpWorklines), or an error.

When evaluating if a location directive line is valid for a demand quantity of an item, and Restrict by unit is set for the line, AX attempts to convert the demand quantity into quantity in the unit that restricts the line. The unit can be converted successfully if the unit restricting the line is included in the Unit sequence group associated with the released product, and Unit conversion is found between the Inventory unit of the relased product, and the unit restricting the line.

If it is possible to convert this into a positive quantity having respected the decimal precision of the unit, the line is valid and location directive actions are consulted to find out where to locate the quantity from. If available on-hand is found, the locating succeeds.

With the input quantity of 21 eaches we had in the scenario, location line 2 would have failed if we had not allowed the location directive to split the demand quantity. Allowing the split, divided the temporary work transaction for the demand quantity into two lines. The line, where we have managed to locate 2 cases (line 1) and the one that still needs to be located (line 2).

Because the location directive line that succeeded for line 1 was restricted by a unit, this unit becomes the Directive unit for the Temporary work transactions, and the Directive quantity is in the Directive unit.

Line 2 still needs a pick location. The next line that was in the location directive was un-restricted by any units and available on-hand was found.

Therefore it also succeeds.

The location line that succeeded for work line 2 was not restricted by any units. Therefore the Directive unit for the Temporary work transactions and the Directive quantity is in Inventory unit of the item.

How could a container be created for a quantity of 1 Directive unit?

The wave method containerization is an optional method that you can add to the wave template. The value in the Wave step code field connects this method with one or more container build templates.

And here is the trick. If Pack by unit = true a container will be created for a quantity of 1 Directive unit. This logic, combined with restricting the template to Temporary work transaction with the correct Directive unit, ensured that a container was created for each of the cases.

An additional Container template was added.

The advanced containerization logic described here: http://blogs.msdn.com/b/dynamicsaxscm/archive/2014/07/26/introduction-to-containerization-automated-packing-process-in-microsoft-dynamics-ax-2012-r3.aspx caused the creation of container(s) for all "less than a full case item quantities" for the shipment.

Temporary work transactions were split again per container ID, and the container ID was recorded on the temporary work transaction.

Please note that the Zone ID from the location is also stored per line in the temporary work transactions.

Why was a label printed per container and why did we see 3 work orders in the scenario?

After wave method containerization was completed, the method createWork used the temporary work transitions to determine which work template to use.

The company wanted a different workflow for picking in the 2 different zones. Therefore Zone ID was added to the range in the advanced query:

This is the work template for Case zone:

Work type print was added to the work template, and then a Work line of type Print was used to print a license plate label. A work line of type Print is only carried out once per work order. To mimic the printing of a label per case, one work order had to be created per case.

To ensure a work order was created per case instead of just one big work order 2 additional tricks were needed:

1. The Container ID was added to the sorting in the query. Any field from the temporary work transactions table that is used for sorting is inserted into the work break table.
2. Group by container ID was set to True.

The same tricks were used for both work templates.

You can read more about work break (or grouping) in this blog:

http://blogs.msdn.com/b/dynamicsaxscm/archive/2014/08/27/combining-wave-containerization-work-break-and-cluster-picking-to-support-a-piece-picking-operation.aspx

This is the work template for piece picking zone, which in this example is floor.

The work classes of the templates are deliberately different to be able to direct work for a given zone to a user. You can read more about that specific detail in this blog: http://blogs.msdn.com/b/dynamicsaxscm/archive/2014/08/20/how-to-direct-work-for-a-specific-zone.aspx

Sorting and work break per container was also configured for this Work template.

The only difference to the configuration mentioned in the blog post above was the setup of the mobile device menu item. In the current scenario, the Directed by method was set to System group and Grouped by was set to Shipment ID. This was the reason why the work line pick for all the work orders for the shipment was pushed to the mobile device one line after another.

Summary

This simple example has showed how it's possible to support an operation where both piece picking and case picking are needed. It used advanced queries in AX in combination with new business logic that was released for the advanced warehouse management functionality in AX2012 R3.

Known limitations

There are still some known limitations in the scenario described above, so don't spent time searching for them.

1. License plate labels are recorded when the Print workflow step is performed. Therefore it is not possible to print labels before that step is performed and you cannot print all the labels before the worker starts the work.
2. A work line of type Pick will be created per container. Unless cluster picking functionality is used for picking it is not possible to group the pick of multiple work order lines for the same item on the same location into 1 work instruction on the mobile device.
3. The outbound ASN delivered with Dynamics AX 2012 R3 does not contain the container information.
4. It is not possible to add new containers or change the content of the item for a planned container to a different container ID.
5. Containerization cannot be used together with the Pack station functionality.

One of the major innovative features we introduced with the R3 release of Microsoft Dynamics AX 2012 was the advanced warehousing system with the warehouse mobile devices portal and the subsequent support for using embedded devices for efficient warehouse workflows. The key assumption with this technology was that warehouse workers would be scanning barcodes for various tasks, including, but not limited to, item identification, license plate selection, location verification, etc.

Specifically for item identification, whenever an ItemID field is presented in the mobile device screen, we allow the user to scan (or manually enter if necessary) a barcode. That barcode is then used to lookup several different values to try to identify which product has been scanned. However – this simple functionality did not support product variants and was not very extensible for other product identifiers or barcode types. As such, in the CU8 release we re-imagined this barcode scanning framework and came up with a solution that supports product variants and partner/customer customizations in a more robust way. This blog post will discuss this framework and show how it can be extended.

Purchase Order Receiving with Barcodes

First let's walk through two common scenarios. In the first you have a Purchase Order with multiple items you want to receive, such as the following:

When you receive this Purchase Order in the warehouse using the mobile device interface you will be asked which item you are receiving. To ensure productivity we want the warehouse worker to scan a barcode and not key in data on the device.

So how can we ensure that the warehouse worker can scan a barcode and have the system recognize the appropriate item? As you will see shortly, there are multiple identifiers that can be used here, but let us first examine how the actual barcode functionality within AX would be used. Within the Product information management module we can configure barcodes for our items. In the image below you can see that I have setup a barcode for each of the items we are concerned with.

With this configuration I can now scan (or manually enter) the barcodes and the system will know which item I am receiving.

Note that this process would also work with a product variant, and the barcode can be used to identify exactly which product variant I am receiving.

Product Confirmation with Barcodes

Another scenario that we have enabled is the ability to perform product confirmation through the mobile device interface. This is detailed in a blog post here. The basic idea is that you want the warehouse worker to be forced to scan something to ensure they have picked the correct product and/or from the correct location. This can help reduce errors in the warehouse – but we still want to ensure productivity is as high as possible. In this vein we have enabled the same barcode scanning framework discussed above into this process – allowing the warehouse worker to scan a barcode which is then used to lookup the product in a variety of contexts.

For example, if we have product confirmation enabled and we have some Sales Order picking work to complete on the mobile device, we would see the following screen:

In that second Item field, we could scan the barcode we defined above (even if this was a variant), to proceed with the pick. However – we are not just limited to the barcodes defined with AX, we actually have other identifiers which might make more sense to uniquely identify this product.

Item Scanning Framework

To enable the above scenarios, and others like it, we released a set of classes as part of CU8 that manage our item identification search process. This is designed as a flexible and extensible framework – with individual search processors chained together, each one looking for data in a particular area. Once one of them finds matching data, a "SearchResult" object is returned to the caller.

On a CU8 box, if you look at all the classes that start with InventInventItemSearch* you will find this small framework:

• InventInventItemSearch
  • Main entry point to the search functionality – also creates the child search processors and iterates through the chain
• InventInventItemSearchProcessor
  • Base class for creating new search processor functionality
• InventInventItemSearchBarcode, InventInventItemSearchExternal, InventInventItemSearchGTIN, InventInventItemSearchItemAlias, InventInventItemSearchItemId
  • Search processors we ship in CU8 for looking up item identifiers in various locations in the application
• InventInventItemSearchResult
  • Rich object used to return the data found

When the search method is invoked on the InventInventItemSearch class, the following sequence of SearchProcessors is used to look for a matching item (I have also included the field used to lookup the data):

1. InventInventItemSearchItemId
   • InventTable.ItemId
2. InventInventItemSearchItemAlias
   • InventTable.NameAlias
3. InventInventItemSearchBarcode
   • InventItemBarcode.ItemBarCode
4. InventInventItemSearchExternal
   • CustVendExternalItem.ExternalItemId
5. InventInventItemSearchGTIN
   • InventItemGTIN.GlobalTradeItemNumber

When a warehouse user scans a barcode to lookup a product, we don't simply look in the barcode table. Instead we iterate over the set of defined search processors and look for a matching record in the various defined tables. Practically speaking, this means the warehouse worker could scan/enter identifiers such as the Item Alias or External identifier – which may be more appropriate for certain items.

This is utilized on the mobile device within the WHSRFControlData::processControl method:

    case #ItemId:
        if (_data != "@WAX402")
        {
            localInventItemSearch = InventInventItemSearch::construct();
            localInventItemSearchResult = localInventItemSearch.search(_data);

            if (localInventItemSearchResult)
            {
                itemId = localInventItemSearchResult.parmItemId();
                itemInventDim = InventDim::find(localInventItemSearchResult.parmInventDimId());
            }
            else
            {
                errorMessage = "@SYP5070015";
                hasError = true;
                break;
            }

Note that if a barcode has been scanned that supports identifying the product dimensions the InventDim will also be returned – and thus can be used to determine the exact variant being scanned.

Extension and Customization

While this is interesting in itself, what I really want to discuss is the ability for our partners and customers to extend this framework to suit their specific business needs. We will cover two areas of customization that are available to you: 1. adding a new search processor to handle a specific barcode format, and 2. Extending the search result object to enable more information to be retrieved from barcode formats.

Creating a New Search Processor

A common request we see is the ability to read out product identifiers from within the GSI-128 barcode format. In these cases the barcode could be encoding a lot of other information related to the product, such as batch, expiration dates, etc – and we may only want to extract the product identifier out of a fixed location within the barcode format. This is a perfect example of something that is easy to add to AX via a custom search processor.

Let's say that our products have long barcodes such as the following example: 02050450004144213736922724210090801. Perhaps the 13-character product identifier is embedded within this barcode format starting at the 4^th character (5045000414421). How would we build a processor to parse this data correctly?

We would first add a new class to AX extending the InventInventItemSearchProcessor base class. We would then need to implement the search method, which is what is invoked by the search framework as it iterates over the available SearchProcessors. The actual code for performing the string slicing is very simple – and the entire SearchProcessor is below:

publicclass InventInventItemSearchBarcodeEAN128 extendsInventInventItemSearchProcessor
{
    publicInventInventItemSearchResult search(InventInventItemSearchItem _searchValue)
    {
        InventItemBarcodeinventItemBarcode;

        if (strLen(_searchValue) > 16)
        {
            inventItemBarcode = InventItemBarcode::findBarcode(subStr(_searchValue, 4, 13), false, true);
        }
 
        returninventItemBarcode.RecId == 0 ?
            null :
            InventInventItemSearchResult::newFromParams(inventItemBarcode.ItemId,
                InventDim::find(inventItemBarcode.InventDimId),
                inventItemBarcode.UnitID);
    }
}

The other change that is required is to add our new SearchProcessor to the list of available SearchProcessors. This is done in the InventInventItemSearch::createSearchProcessors method. Note that when you customize this list you can choose where in the sequence your new SearchProcessor should process the data – and if you want to remove SearchProcessors that might not be relevant to your specific scenario. In this case I am adding our new SearcgProcessor to the head of the list:

protectedvoidcreateSearchProcessors()
{
    searchProcessors = new List(Types::Class); 
   
    searchProcessors.addEnd(new InventInventItemSearchBarcodeEAN128());
    searchProcessors.addEnd(newInventInventItemSearchItemId());
    searchProcessors.addEnd(newInventInventItemSearchItemAlias());
    searchProcessors.addEnd(newInventInventItemSearchBarcode());
    searchProcessors.addEnd(newInventInventItemSearchExternal());
    searchProcessors.addEnd(newInventInventItemSearchGTIN());

    return;
}

Extending the Result Data

Another common scenario customers ask for is the ability to extract more information from a barcode than what we currently support. Barcode formats such as GS1-128/EAN128 can encode a cavalcade of data, such as batch number, expiration dates, physical dimensions, etc. We have some support in the system for these format in our BarcodeEAN128 class – which includes a decode method to parse this barcode format. We will use this functionality to perform the parsing of the barcode.

It all starts with the InventInventItemSearchResult class. This is a small class that is returned from the search framework when matching data is found. Currently this class contains the following fields:

• ItemId
  • Always filled in by the SearchProcessors when a matching item is found within AX
• InventDimId
  • Filled in when a matching variant is found for a GTIN/Barcode lookup
• UnitOfMeasureSymbol
  • Filled in when a matching variant is found for a GTIN lookup

In our simple example we will have a barcode that encodes the batch information after the product identifier. The product identifier will be a fixed 14-character field followed by the batch identifier. For example, product 0000000161_202, batch number B123 would have a barcode such as the following:

0000000161_202B123

The human-readable format for this barcode would be the following (in the GS-128 format):

(01) 0000000161_202 (10) B123

And the actual scanned text of this barcode would look something like this:

]C1010000000161_20210B123]C1

In the AX BarcodeEAN128 implementation the character string "]C1" is designated as the Function Code 1 or FNC1. This is used in the GS-128 spec to indicate application identifiers and variable length fields (such as the batch id). There is much more to GS-128 parsing than can be covered in this blog post – for more information start here.

To get the batch information extracted, first we will add the new data to the InventInventItemSearchResult result object. Using the same pattern as the existing parameter fields gives us the following code:

/// <summary>
/// Class used to return data from the <c>InventInventItemSearch</c> search functionality.
/// </summary>
publicclassInventInventItemSearchResult
{
    ItemId               itemId;
    InventDimId          inventDimId;
    UnitOfMeasureSymbol  unitOfMeasureSymbol;
    InventBatchId        batchId;
}

publicInventBatchIdparmBatchId(InventBatchId _batchId = batchId)
{
    batchId = _batchId;
    returnbatchId;
}

Now I can make a new SearchProcessor to extract the embedded Batch and ItemId information. This might look something like this:

publicclassInventInventItemSearchEmbeddedBatchextendsInventInventItemSearchProcessor
{
    publicInventInventItemSearchResult search(InventInventItemSearchItem _searchValue)
    {
        InventTable                    inventTable;
        InventInventItemSearchResult   result = null;
        BarcodeEAN128                  barcode = BarcodeEAN128::construct();

        barcode.decode(_searchValue);
        inventTable = inventTable::find(barcode.itemId());

        if (inventTable.RecId != 0)
        { 
            result = InventInventItemSearchResult::newFromItemId(barcode.itemId());
            result.parmBatchId(barcode.batch());
        }

        return result;
    }
}

Consuming the returned batch information is done by checking for the batch parameter data and processing the data as if the user has entered it directly into the batch text control. This can be done by simply modifying the code we saw earlier in the WHSRFControlData::processControl method:

case #ItemId:
    if (_data != "@WAX402")
    {
        localInventItemSearch = InventInventItemSearch::construct();
        localInventItemSearchResult = localInventItemSearch.search(_data);

        if (localInventItemSearchResult)
        {
            itemId = localInventItemSearchResult.parmItemId();
            itemInventDim = InventDim::find(localInventItemSearchResult.parmInventDimId());

            if (localInventItemSearchResult.parmBatchId() != '')
            {
                this.processControl(#BatchId, localInventItemSearchResult.parmBatchId());
            }
        }
        else
        {
            errorMessage = "@SYP5070015";
            hasError = true;
            break;
        }

To make this work I also had to modify the processData method to not overwrite the Batch information.

case #BatchId:

    if (inventBatchId == '')
    {
        if (mode == WHSWorkExecuteMode::AdjustmentIn)
        {
            if (licensePlateId)
            {
                if (WHSLicensePlate::exist(#LicensePlateId))
                {
                    inventBatchId = this.getBatchId();
                }
            }
        }
        elseif(workLine.WorkType != WHSWorkType::Count)
        {
            inventBatchId = this.getBatchId();
        }
    }

    fieldValues.insert(#BatchId, inventBatchId);
    break;

This will now allow our users to automatically select the batch by scanning one of our specially formatted barcodes. As an example, suppose we have a location containing a number of batch-controlled items and we want to move some items from the location using the mobile device. Using the standard functionality, we would need to scan or enter the location, then scan or enter the product identifier, and then enter the batch number. Using the embedded batch barcode we defined we can skip one of these steps.

Note that I ran into a slight implementation problem with this example due to the ItemId EDT length definition. When we build the mobile device UI we use the EDT definitions as the maximum length of allowable input. Since the ItemId is only allowed to be 20 characters long, I was not able to scan these barcodes that could end up much longer than 20 characters. Instead of modifying every page in the mobile interface, I updated the WHSWorkExecuteDisplay::buildControl method to extend the maximum allowed length when building an ItemId-related field.

containerbuildControl(str             _controlType,
                       str             _name,
                       str             _label,
                       int             _newLine,
                       str             _data,
                       ExtendedTypeId  _inputType,
                       str             _error,
                       int             _defaultButton,
                       boolean         _enabled = true,
                       str             _selected = '',
                       WHSRFColorText  _color = WHSRFColorText::Default)
{
    container      ret         = conNull();
    int            length      = -1;
    str            typeStr     = #TypeUndefined;
    SysDictType    sysTypeDict = newSysDictType(_inputType);
    Types          type;

    if (_inputType == extendedTypeNum(ItemId))
    {
        length = 100;
    }
    elseif (_inputType != #WHSRFUndefinedDataType&& sysTypeDict)
    {
        type = sysTypeDict.isTime() ? Types::Time : sysTypeDict.baseType();
        typeStr = enum2Symbol(enumNum(Types), type);
        if (type == Types::String)
        {
            length = sysTypeDict.stringLen();
        }
    }

Conclusion

Hopefully this gives you an idea of some of the things that are possible with our new item search functionality framework in the mobile device. Using this effectively will be key for enabling truly modern and effective workflow processes in your warehouse.

We have recently released Cumulative Update 9 (CU9) for Microsoft Dynamics AX 2012 R3. This update packs a ton of great updates and fixes we have released since CU8, and there is one notable new feature that I want to call out and discuss here. The warehousing team has received feedback from customers that the advanced warehousing functionality needs a way for some users to see a list of available work in the warehouse and to give them the ability to select and operate on this work through a mobile device interface. We are pleased to announce that we have released this functionality as part of CU9 and through KB3062537. This blog post will attempt to describe this functionality and show some of the ways we envision it being useful in your workflows.

Setup

We have implemented this functionality as a new menu item. Like all advanced warehouse menu item configuration, this can be configured by navigating to Warehouse management -> Setup -> Mobile device -> Mobile device menu items. From here create a new menu item, set the Mode to Indirect and select the (new) activity code "Display open work list." For a detailed description of configuring Menu items see this blog post: http://blogs.msdn.com/b/dynamicsaxscm/archive/2015/02/23/warehouse-mobile-device-portal.aspx.

As you can see, this will display several options available to configure.

• Records per page: Setting this to non-zero will ensure only a set number of work items are displayed in the grid at one time. This will enable forward/back buttons and paging logic within the work list page itself. Setting this to zero will disable the paging logic and show all work lines within the grid.
• Allows users to filter by work transaction type: If this is set to true, it will display a filter option on the work list page, allowing users to quickly select the subset of work items matching a specific transaction type.
• Work classes: This grid allows you to limit the work items displayed to a specific subset of work classes. This will be discussed in more detail later as part of filtering.

In addition to these options, there are two buttons enabled at the top of the window when this activity code is selected: "Edit query" and "Field list." These allow you to tailor the work selected and the data displayed.

Work selection

By default, the work list will display all Work items in the current warehouse that are available to execute on (WorkStatus = Open or In process, and Frozen = No). By using the query functionality, a more specific list of work items can be selected and displayed in the list. For example, the following query will select the work items that are assigned to the Webshop Work pool and have a specific mode of delivery. This could, for example, be used to give a certain segment of users a specific list of work assigned to them for the day. Note that any sorting applied to this query will also carry over and apply to the generated work list.

Field List

Once you have determined the work query used to select the data, you will need to decide exactly what to display on the work list. This is done through the Field List button; when selected it opens a new window allowing you to configure up to seven columns of data for the work list screen.

We always display the WorkId in the first column (as you will see soon, this is how work is selected to operate upon). Each of the other columns can be configured by selecting one of the available fields in the dropdown. We have exposed all of the fields from the Work table, the Load table, and two display methods we thought would be highly useful. Note that you don't have to fill in all seven columns – you should test the configuration and final display with the devices you plan to deploy to the warehouse to ensure the functionality works as expected.

The two display methods exposed on the third tab are the "displayFinalPutLocation" and "displayStartLocation." These are used to provide some overall context to a work line – as sometimes it can be important to understand where the work will start and end before selecting it.

• displayFinalPutLocation: This will iterate over all the remaining work lines after the specific work line row (which could include multiple pick/put pairs depending on the work template configuration) and display the final put location. This can be helpful to understand when different orders are directed to different loading bays and the user needs to quickly identify all work items belonging in this bundle.
• displayStartLocation: This will show where this work will direct the user immediately upon selecting it. This can be very useful for a user to see available work that is located physically close to them in the warehouse.

In the screenshot below I have configured the work list based on a typical setup. I selected the Order Number, Work Status, Work Priority, Start/End locations, Created date/time, and the Work Template Code – all from the Work table. I could have added information from the load table as well – you will have to decide if this provides value to your warehouse employees.

Work Filtering

Since we are showing a list of work to the user, it is very important that the right set of work is displayed for that specific user. As such, we have two filtering options in place that you will need to be aware of in case you are not seeing the expected set of work for your users.

Work Class filtering

Like any work mode menu item, it is possible to associate a set of work classes to this menu item through the grid on the menu item setup form. If no work class is specified, then no filtering is performed – however, if one or more work classes are configured here, the final work list will be filtered to only include matching work classes. Note that this is in addition to any query filtering capabilities added as part of the work query process discussed above. The screenshot below shows how we could limit the work list to only show work associated with Sales orders.

Note that it would also be possible to further refine this list, and separate out the Sales picking work from the Sales loading work. In a large warehouse you might not want to show the combined list and instead show the targeted list of work applicable to the separate teams responsible.

Menu Item Filtering

We have another area where we trim results from the final work list displayed to the end user, and I anticipate this could be an area of confusion for some. Since we are displaying a list of work, we need to ensure that the user has access to a valid menu item that can process that work if they click on it to execute. As such, for each work row we do a check to ensure the current user has access to a User-Directed menu item that can process that row. This is very important to remember – if there is no User-Directed menu item for that specific work class then the work will not be displayed to the user. For example, in the base demo data set you will not see any PO Putaway work because the standard menu item is classified as User Grouping, not User Directed. Changing this (or adding a new Menu item) to User Directed will allow this work to be displayed.

Also – the user must have access to the menu item, meaning it must be accessible from their top level menu, as defined in the warehouse user setup. In does not need to be at the top level – we will iterate through the menu structure looking for a match, but it does need to be available for this user somewhere in their menu structure.

These choices were implemented to ensure we don't show work to users that they are not allowed to process. The choice of only using the User Directed menu items stems from the fact that we are now allowing the user to select the work to execute – so it seemed the best match. Depending on feedback we will likely expand these options and offer more choices in a future release.

Work List Runtime View

Now that we have all the configuration options out of the way, let us take a look at what this screen will look like at runtime. Unlike the previous mobile device screens, this interface is targeting tablet devices and will require more screen space than we typically see in the embedded barcode scanning devices. As such we anticipate this interface being a power user view of the system, or something deployed for forklift drivers who often have a larger mounted display in their cabs.

Based on the configuration defined above, this would be the view we would see running locally in a browser:

Note that we have enabled the Filter work – which allows us to automatically restrict the list of a specific transaction type. This can be enabled/disabled at the menu item configuration screen. We have also set the paging size to 10 – which means we can only see ten records at a time and have access to the Previous/Next buttons.

All of the top level columns are sortable by clicking on them, except the Start Location and Final put location columns.

Finally – clicking one of the Work ID buttons will cause the system to load that work line and start executing it using an available user-directed menu item. In the case of multiple menu items available for processing this work class, we will first show a list of menu items and ask the user to select the specific menu item to use. We will then directly navigate to the screens responsible for processing the work and the user can continue as they typically would.

We did also receive questions whether this work list could be shown on a mobile phone or RF device with a smaller screen. As this is still outputting the same basic HTML structure as discussed in previous blogs the answer is yes, but you will obviously run into screen real-estate issues. Limiting the selected columns to only show 1 or 2 columns would be our recommended way to enable this in these scenarios.

Final Thoughts

I hope this overview of this exciting new feature was useful. The work list feature was driven directly from our interaction with customers and partners and we look forward to hearing more from the AX community.

By Lennart Conrad,  Microsoft

This blog posting describes how you can make small code modifications to control how reservations will be handled.

The WHS reservation system makes it possible to do reservations on different levels which represents how specific inventory dimension are used. By associating a reservation hierarchy with an item, the hierarchy levels are used to control which inventory dimensions will be used for a reservation and when these dimensions needs to be assigned to the inventory transactions.

Readers are assumed to be familiar with the WHS reservation system and have knowledge about the reservation hierarchies and the new ways of calculating on-hand. If a brush up on the details about the reservation system is needed, the below resources can be useful:

• White paper - Reservations in Warehouse management AX 2012 R3: http://www.microsoft.com/en-gb/download/details.aspx?id=43284
• Upgrading code that relies on available and reserved inventory quantities in AX 2012 R3: http://blogs.msdn.com/b/dynamicsaxscm/archive/2014/05/05/upgrading-code-that-relies-on-available-and-reserved-inventory-quantities-in-ax-2012-r3.aspx

We have received several different questions around how the rules about which levels the reservation should include, can be changed. Here are some of the scenarios we have heard of and replied to:

• I always want my production orders to reserve on all the dimensions IF the location is specified 
• I am rolling out WHS processes one warehouse at a time and want to have a WHS setup but  I want to control if the reservation includes all dimensions or not based on the warehouse in order to use the old WMS picking system for the transition period
• I want my sales order taker to be able to reserve on all dimensions IF they specify the serial number for an item that has serial below location

The good news is that these requirements can quite easily be supported with minor modifications.

This blog post will describe how the WHS reservation strategies are determined and explain where in the code changes need to be made to achieve a different behavior.

Reservation strategies Currently the below strategies are supported. The ‘Above Location’ and ‘All’ are the main ones that impact most scenarios. The following table gives a short description of all the strategies.

The system will use the reservation strategy ‘Above Location’ when the following criteria’s are met:

• The line for which the reservation is made can have reserved work. This is for example production lines, sales lines and transfer order lines.
• The warehouse is either not specified or it is a warehouse enabled for Warehouse management processes

The reason for choosing the ‘Above Location’ strategy when the above criteria are met, is that a reservation above location is needed in order to create work.

If the reservation includes any dimensions at or below the location,the work cannot be created. This is to avoid a double reservation since work has its own inventory transactions. This subject is described in more details in  White paper - Reservations in Warehouse management AX 2012 R3 (http://www.microsoft.com/en-gb/download/details.aspx?id=43284).

If the system does not choose the ‘Above Location’ strategy, it will choose reservation strategies that can results in a reservation on all the physical dimensions. 

If batch number is active in the items storage dimension group and above the location in the hierarchy the Batch level strategy is applied. 

Modifying code to change the above behavior

In order to change the decision on whether to reserve above location, different methods can be changed.

The main decision is made in the determinePhysicalStrategyTypesMovement method which looks as below

\Classes\WHSReservationHierarchyLevelStrategy\determinePhysicalStrategyTypesMovement

privatestatic containerdeterminePhysicalStrategyTypesMovement(
    InventMovement _movement,
    InventDim _inventDimReservationCriteria)
{
    container strategyTypes;
 
    if (_movement.canHaveReservedWork()
    && (!_inventDimReservationCriteria.InventLocationId
    || InventLocation::find(_inventDimReservationCriteria.InventLocationId).whsEnabled))
    {
        strategyTypes = [WHSReservationHierarchyLevelStrategyType::AboveLocation];
    }
    else
    {
        strategyTypes = [WHSReservationHierarchyLevelStrategyType::All,
                        WHSReservationHierarchyLevelStrategyType::AllNotAllowedBlank];
    }
 
    return strategyTypes;
}

If the goal is to have a specific movement type do a reservation on all dimensions one option is to override the canHaveReservedWork() method on that movement type.

The below is an example where the method is overridden for the sales lines movement to control that reservation occurs on all dimensions, if any dimensions below or at the location level is specified. E.g. if the location is specified on the sales line then the reservation will happen on all dimensions. 

public boolean canHaveReservedWork() 
{ 
    return this.isItemWHSEnabled() && salesOrderLine.inventDimAllowsWHSProcessing(); 
}

If the desire is to have a change that affects all movements types, then the first If block could be extended.

Two other methods are important to pay attention to if a modification is done:

\Classes\InventMovement\getInventDimForIssueTransFromReceipt

This method is called when a receipt is updated and a related issue transaction needs to be updated as a consequence. An example could be a sales order line that is reserved ordered against a purchase line.

When the purchase order line is updated with dimensions, only dimensions above the location will be transferred if the movement is one for which work can be created.

\Classes\InventMovement\getInventDimForReservedTransPhysChange

This method is called when a receipt is updated to a status that impacts the physical inventory and a related issue transaction needs to be updated as a consequence.

An example could be a sales order line that is reserved ordered against a purchase order lines transactions. When the purchase order line is registered with all the physical dimensions, only dimensions above the location will be transferred if the movement is one for which work can be created.

With modifications to one or more of the above mentioned methods it is possible to control if the reservation will be made on dimensions above the location or on all dimensions by using the existing reservation strategies.

It is also possible to introduce new reservation strategies and thereby get different control on the levels that the reservations are made on. An example could be a reservation strategy that only reserves on the Site level. Such modifications will be covered in future blog 

As a final comment, then remember that the code is "alive and breathing", so changes can and will occur as new hotfixes and updates are released. Hence, you should always verify if the usage of the methods covered here have been extended which means that other updates could be needed.

Please don't hesitate to provide us feedback on this posting and the reservation system in general! 

The purpose of this blog post is to define the main technical implementation requirements needed for a customer installation running Microsoft Dynamics AX with the WMSI/WMSII (configuration key WMSBasic/WMSAdvanced) functionality, wanting to migrate to the new warehouse management functionality released as part of the Microsoft Dynamics AX 2012 R3, WHS (configuration key WHSandTMS).

The blog post will not address the functional requirements during this migration, but focus on the processes needed to migrate the data.As part of this migration, it is important to understand that we recommend that you don’t run WMSII and WHS on the same partition within the same installation instance. Therefore, both a migration of data as well as the warehouse management enabling processes must be executed.

It is strongly recommended that you execute the migration on top of an already upgraded Microsoft Dynamics AX 2012 R3. In other words, you would upgrade the existing implementation, for example AX2009 to AX2012 R3 CU9 (the latest cumulative update as of this writing) and then use the processes in this blog post to migrate the AX2012 R3 WMSI/WMSII to the new warehouse management capabilities in R3.

Information about the new warehouse management and transportation management modules can be found under the ‘What’s new in Dynamics AX 2012 R3’ links section.

Migration of the warehouse management database information

One of the needed migration tasks is to upgrade the current data from the WMSI/WMSII database structure to the new WHS database structure.

This blog posts describes two different migration processes, depending on whether you:

• Migrate data supported out of the box with as minimal scripting as possible.

or

• Migrate data based on script recommendations and keeping transactional data as is.

But, to start with, the following section will describe some of the key entities in both warehouse management solutions to give some background about the data migration tasks that are needed.

Warehouse layout

An important change made between the WMSII and the WHS data models is a new warehouse layout. The following overview can be used to get an understanding of the differences between the two database models.

Both the ‘Warehouse’ and the ‘Inventory location’ entities are the same for both WMSI/WMSII and WHS. It is though important to understand that the use of these entities is different in the two systems.

To enable a new warehouse layout for WHS processes the ‘Use warehouse management processes’ parameter must be checked on the ‘Warehouse’ form.

Updating an existing warehouse to become active for the WHS processes is not supported out of the box. This setting can only be enabled when creating a new warehouse entity, making it necessary to execute custom code or manually update the data if an existing warehouse ID must be reused within the new warehouse management module.

Zone Group and Zone

Conceptually the following warehouse layout is used for WMSII:

Warehouse–> (StoreZone -> StoreArea) -> Aisle -> Rack -> Shelf -> Bin

The StoreZone entity is part of the WMSII, and can’t co-exist with the WHS processes.

The conceptual WHS warehouse layout includes:

Warehouse -> ZoneGroup -> Zone -> Location

A migration option could be to migrate the WMSII Store Zone one to one with the WHS Zone Group and the WMSII Store area one to one with the WHS Zone. But it might also be that the whole warehouse layout needs to be revised.

In WMSI, the aisle, rack, shelf, and bin position define the inventory location and the physical dimensions and capacities are defined directly on the location.

In WHS this is different and more details will follow about how to migrate capacity constraints.

Location type

The location is defined with a user defined type (Location type) which can be mapped to the fixed AX location type.

As part of the definition of the location entity, the location type (bulk, picking, etc.) holds a fixed coding concept in WMSI. In WHS, this does not drive any business logic – but is controlled by different queries as part of the module.

The existing WMSII location type, based on the WMSLocationType enum, can as well be migrated one to one with the WHS location type. But please do note the conceptual difference in the two implementations. In the WHS the location type entity does not in itself drive any warehouse management processes, this must be enabled by setup and query logic, so again it will make sense to evaluate if all the location types will be needed in the new WHS implementation.

Make sure to add the location types for ‘Staging location type’ and ‘Final shipping location type’ as part of the ‘Warehouse management parameters’ as well. This will be needed to drive the WHS processes.

Location names

The location names used in the WMSII are primarily used for the location wizard. The same conceptual design goes for the user defined location formats in the WHS.

At least one location format is required. Depending on whether the WHS location wizard will be used or not to create new location entities, the Location formats can be migrated by simply only creating a single ’default’ entity. Otherwise, a one to one migration might make sense for each of the existing location name definitions.

Physical dimensions (Location)

As part of the Inventory location entity, WMSI/WMSII holds values for the physical dimensions, as well as capacity restrictions.

Location profiles

In WHS a new entity called ‘Location profile’ stores the physical dimensions and capacity of the locations. This entity will then be assigned to one or more locations.

As a migration concept, the Location profiles could be created with one unique profile for each of the combinations of the created Location types - Example:

• Allow negative inventory: Unchecked
• Use license plate tracking: Yes (WMSII) In case pallets are, or have been, used on a location within the warehouse, the location needs to be license plate controlled.
• It will not be allowed to have a mixed mode of locations both with and without license plates with on-hand.
• Allow mixed items = Yes
• Allow mixed inventory statuses = Yes
• Allow mixed inventory batches = Yes
• Allow cycle counting = Yes
• Generate check digit = No
• Overrule rules for batch days = Yes
• Dimensions (group of fields)
• Storage unit = [Blank]
• Usable dimensions = (Depends on the below conditions)
• Actual physical dimension values from existing locations

If WMSII locations exist with the use of ‘Max. weight’/‘Max. volume’:

If volume is set, it is recommended to use the “Use location volume” functionality as part of the Location profiles. The actual values (height, width, depth) and maximum weight from the locations can be migrated directly to Location profiles (with one unique Location profile per combination of all the needed existing setup combinations).

Location stocking limits

Besides the Location profiles a new entity called Location stocking limits has been introduced in the WHS implementation.

The Location stocking limits entity can be used to limit the storage capacity within the warehouse in multiple ways and levels. If an existing WMSII implementation exists with the use of ‘Max. pallets’ for one or more locations, the Location stocking limits can be used to migrate this setup by, for example, limiting the capacity of possible quantities of ‘Pallet unit’ to be stored. Please do note that the Location profile ID can also be used as part of this setup to limit the number of records to define.

To enable location stocking limits, you might also need to use the WHS Unit sequence group ID, as well as unit conversions. The validation of the released product can be used to ensure this is correct.

Inventory location

The new warehouse management module will use the same location entity as legacy warehouse management

If check text is used, it can be migrated as well.

Storage dimension group

As part of enabling the WHS processes a ‘Storage dimension group’ record must be created with the parameter ‘Use warehouse management processes’ checked.

This will enforce the use of Site, Warehouse, Inventory status, Location, and License plate as ‘Active’ and ‘Physical inventory’ tracked inventory dimensions.

For a ‘Storage dimension group’ with the parameter ‘Use warehouse management processes’ checked, the Location inventory dimension must have both ‘Blank receipt allowed’ and ‘Blank issue allowed’ unchecked.

The ‘License plate’ must have ‘Blank receipt allowed’ and ‘Blank issue allowed’ checked.

All ‘Released products’ associated to a ‘Storage dimension group’ with an active ‘Pallet ID’ inventory dimension would need to use a WHS enabled ‘Storage dimension group’ or be changed to another ‘Storage dimension group’ without the ‘Pallet ID’ active. The reason for this is that the configuration key associated with this inventory dimension is a child of the WMSII configuration key, and running WMSII and WHS on the same partition is not recommended.

‘Released products’ which are assigned to a ‘Storage dimension group’ with an active ‘Location’ dimension and using consolidated picking output orders, or other capabilities from the WMSII will also need to be associated with a new WHS enabled ‘Storage dimension group’.

Please do note – that if Released products are using other WMSII processes, e.g. random storage put-away based on item arrival journal postings and input pallet transports – you also need to think about migrating these processes to WHS.

If the Storage dimension group is associated on the shared product entity the current design is that this setting is inherited to all products released to legal entities.

If you assign a 'Storage dimension group’ with the ‘Use warehouse management processes’ parameter enabled, you need to consider the use of the ‘Reservation hierarchy’ for the product. Please refer to linked information about this topic.

License plate

In addition to the new storage dimension group, there’s a new inventory dimension called ‘License plate’ and related new entity with the same name. The WMSII ‘Pallet ID’ should be replaced with this new WHS ‘License plate’.

We recommend that you copy existing pallet entities to the new license plate entities and update the affected InventDim records. The process is described in more detail later in this blog post.

Inventory status

Besides the new ‘License plate’ inventory dimension, a new ‘Inventory status’ dimension is introduced. It is recommended that you use a default value and that at update, you assign all the current on-hand inventory that’s being enabled for WHS. The process is described in more detail later in the blog post.

On-hand, Inventory transactions, and Inventory dimensions

The biggest and most risky part of the migration is the on-hand inventory and all the related information in this area…

This is where a decision about the two main migration concepts (might be a combination) must be taken! You can choose: 

• A migration process based on as much out of the box logic as possible. This requires you to:
• Close all open orders
• Issue out (Sold update) all on-hand inventory
• Enable the new WHS processes
• Process an inbound on-hand update

And/or

•  A migration process based on a custom script where open orders and on-hand inventory can remain as part of the migration

The next section of the blog post will go into more details about this. 

WMSI/WMSII to WHS migration – process using out of the box support

The following is a description of a process that will enable migration of an existing WMSI/WMSII implementation in Microsoft Dynamics AX 2012 R3 to a new warehouse management implementation (WHS), based on using as many out of the box processes as possible.

To get the most value out of this information it is a good idea to have looked into some of the existing information related to the WHS functionality and to have viewed the recording and Power Point deck from the Microsoft Dynamics Technical Conference 2015 event where a session about this migration process was held.

Microsoft Dynamics Technical Conference 2015 presentation:

http://mediadl.microsoft.com/mediadl/www/d/dynamics/partners/BSAX22.wmv

https://mbs.microsoft.com/Files/customer/AX/Downloads/15TechConference/BSAX22_Lynnerup_v02.pptx

The process will not describe the migration of the warehouse layout, but focus on the product and on-hand migration. 

High-level migration process steps when using out of the box processes

To migrate transaction data it is recommended to use a staging concept. Basically:

1. Make sure you have zero on-hand and everything is financially closed:
1. Cancel or finalize all open source documents
2. Issue all on-hand inventory (Sold updated)
3. Run the Inventory closing procedure
2. Enable the required settings for the product (Define and assign):
1. Storage dimension groups
2. Unit conversion definitions
3. Unit sequence group ID definitions
4. Reservation hierarchies
5. All the product reference data policies that are needed (More information can be found from 16 slide in: https://mbs.microsoft.com/Files/customer/AX/Downloads/15TechConference/BSAX22_Lynnerup_v02.pptx
3. Receipt update all inventory on-hand again
1. If the inventory pallet dimension has been used it might be a good idea to reuse the value as part of the new license plate rather than create new IDs. If this is the case, example code exists at slide 26 in: https://mbs.microsoft.com/Files/customer/AX/Downloads/15TechConference/BSAX22_Lynnerup_v02.pptx
2. Please do make sure the locations where license plates exist get enabled to track license plates via the location profile grouping and vice versa.

WMSI/WMSII to WHS migration – process to keep transaction data

The following information is a description of a process that will enable migration of an existing WMSI/WMSII implementation in Microsoft Dynamics AX 2012 R3 to a new warehouse management implementation (WHS), without reverting all open orders.

To get the most value out of this information it is a good idea to have looked into some existing information related to the WHS functionality as well as the migration process described above about using as much as possible of the out of the box functionality. It is clear that when you migrate with open on-hand inventory (reserved ordered or even physically reserved) it will become more technically challenging to migrate the data. If on-hand reservations exist, they must be ‘moved’ to new reservation logic during the data migration.

High-level migration process steps when keeping existing orders

Listed below are the most important process steps needed to perform a WMSI/WMSII to WHS migration when keeping existing orders in the system. Starting out with probably the most risky part of this migration process…

1. Update all InventDim records that require the new inventory status value (default inventory status value is recommended).

a. It is also recommended that you limit the number of InventDim records that get updated to only the ones used for inventory transactions for the products that are going to be migrated. This will lower the risk of updating too much. Make sure you make a proper analysis about which records to update.

b. Re-hashing might be needed if a unique index is not adjusted (please see the blog post about this: http://blogs.msdn.com/b/dynamicsaxscm/archive/2015/08/13/microsoft-dynamics-ax-r3-new-warehouse-management-solutions-impact-on-inventdim-extensibility-and-migration-scenarios.aspx

c. If the inventory pallet dimension has been used it might be a good idea to reuse the value as part of the new license plate rather than create new IDs. If this is the case, example code exists at slide 26 in: https://mbs.microsoft.com/Files/customer/AX/Downloads/15TechConference/BSAX22_Lynnerup_v02.pptx

2. Assign a WHS enabled storage dimension group to the item:

a. Use the existing Storage dimension group and WHS enable it and get the missing entries for license plate and status created

Or

b. Create a new WHS enabled storage group and assign it to the item and product by updating \Data Dictionary\Tables\EcoResStorageDimensionGroupProduct and \Data Dictionary\Tables\EcoResStorageDimensionGroupItem

c. Make sure you do NOT to break the rules when assigning new Storage and tracking dimension groups as part of the script. The groups MUST use the same physical and financial settings and you need to pay attention to the ‘Allow blank issue’ and ‘Allow blank receipt’ settings.

d. Make sure that a record is created in the WHSInventEnabled and TMSInventEnabled tables for the items that should be WHS enabled (having the new or updated storage dimension group assigned). Additional documentation about this can be found at slide 22 in https://mbs.microsoft.com/Files/customer/AX/Downloads/15TechConference/BSAX22_Lynnerup_v02.pptx

3. Assign correct reservation hierarchies to the items – populate the relationship table WHSReservationHierarchyItem. (Additional documentation about this can be found at slide 24 in https://mbs.microsoft.com/Files/customer/AX/Downloads/15TechConference/BSAX22_Lynnerup_v02.pptx)

4. Recalculate on-hand using the On-hand consistency check. This step automatically updates the WHSInventReserve table. If you’re not doing your migration on the AX2012 CU9 version, you need to install additional hotfixes.

We recommended you read the blog post: http://blogs.msdn.com/b/dynamicsaxscm/archive/2015/08/13/microsoft-dynamics-ax-r3-new-warehouse-management-solutions-impact-on-inventdim-extensibility-and-migration-scenarios.aspx

5. Addition steps in order to get to a good working environment after the actual migration:

a. If open source document lines (e.g. sales and production) exist with the location dimensions assigned, these must be removed – as well on the related transactions. Otherwise, it will not be possible to process the outbound process by using WHS work. If the pallet dimension is used on the source document lines this must be handled as well. If not, the legacy outbound processes must be used without the creation of WHS work.

b. Assumptions:

• For physical reservations all dimensions are assigned
• Use of blank issue and receipt follows the more limited possibilities for WHS

c. All the physical warehouse layouts and processes must be enabled in the new WHS module.

Links to addition material:

Video recording from the Microsoft Dynamics Technical Conference 2015:

http://mediadl.microsoft.com/mediadl/www/d/dynamics/partners/BSAX22.wmv

Power point presentation from the Microsoft Dynamics Technical Conference 2015:

https://mbs.microsoft.com/Files/customer/AX/Downloads/15TechConference/BSAX22_Lynnerup_v02.pptx

Blog post – Microsoft Dynamics AX R3 – New Warehouse Management solutions impact on InventDim extensibility and migration scenarios:

http://blogs.msdn.com/b/dynamicsaxscm/archive/2015/08/13/microsoft-dynamics-ax-r3-new-warehouse-management-solutions-impact-on-inventdim-extensibility-and-migration-scenarios.aspx

Blog post - Controlling reservations for warehouse management enabled items (WHS) – Part 1:

http://blogs.msdn.com/b/dynamicsaxscm/archive/2015/07/01/controlling-reservations-for-warehouse-management-enabled-items-whs-part-1.aspx

Blog post - Upgrading code that relies on available and reserved inventory quantities in AX 2012 R3:

http://blogs.msdn.com/b/dynamicsaxscm/archive/2014/05/05/upgrading-code-that-relies-on-available-and-reserved-inventory-quantities-in-ax-2012-r3.aspx

Blog post- Warehouse and Transportation management vs. the “old” Advanced warehouse management

http://blogs.msdn.com/b/dynamicsaxscm/archive/2014/06/26/warehouse-and-transportation-management-vs-the-old-advanced-warehouse-management.aspx

Reservations in Warehouse management AX 2012 R3:

http://www.microsoft.com/en-gb/download/details.aspx?id=43284

Data migration tools:

http://technet.microsoft.com/EN-US/library/aa548629.aspx

Technical Conference 2013 presentation:

http://mediadl.microsoft.com/mediadl/www/d/dynamics/customersource/TC2014_BRK458-R.wmv

Cumulative Update 10 for Microsoft Dynamics AX 2012 R3 is now here! We are as usual happy to say that this release includes several improvements for warehouse and transportation management. Microsoft Dynamics AX 2012 R3 CU10 is available for download on Lifecycle Services, PartnerSource and CustomerSource. For detailed information on the release of Microsoft Dynamics AX 2012 R3 CU10, please refer to the Dynamics AX In-Market Engineering blog. The build number for Cumulative Update 10 is 6.3.3000.111 and the knowledge base article is KB3102920.

In this blog post we’ll take you through some of what is new for WMS and TMS. The following information is also available as part of the What’s new in Microsoft Dynamics AX 2012 document found here.

In short, within WMS and TMS the following enhancements are made available:

• It is now possible to use warehouse management processes with purchase, production and sales orders linked to projects.
• A new field has been introduced to the On hand by location form called Available physical on exact location.
• Wave demand replenishment now recognizes existing unallocated min/max replenishment work as supply.
• Cancelling wave demand replenishment work will now unblock sales orders automatically.
• Demand replenishment will now consider all lines in the replenishment template.
• The directive code on work templates with the work order type Replenishment is now editable.
• Picking of sales serial items is now possible using warehouse management processes.
• You can now postpone the registration of serial numbers on a serialized component in a manufacturing process up until production consumption.
• Picking partial license plates for raw material picking is now possible.
• During Report as finished and put away it is now possible to change inventory status on the mobile device.
• It is now possible to overproduce with back-flushing when using a scrap factor on the Bill of Materials line.
• You can now separate the receiving and put away process when doing license plate receiving on the mobile device.
• Added functionality for splitting put away lines to several locations, consolidation of license plates and skipping put lines.
• You can now cancel a put away on the mobile device at any place in the process.
• During purchase receiving using the mobile device, the unit of measure will be defaulted to the UOM setup on the GTIN number.
• When using the Delivery schedule form on a purchase order line to split the delivery of a purchase order to different days, the load lines will also be updated.
• You can now over pick during sales or transfer order picking on the mobile device.
• You can now use the Full button any time during picking to indicate that you can’t pick any more lines.
• It is now possible to block release to warehouse and creation of work for sales orders that exceeds customers credit limit.
• Work can now be split depending on Work header maximums specified on the Work template form.
• You can now create scheduled routes for transportation planning and use Load building workbench to create optimal loads for the routes.
• The auto release to warehouse process for transfer orders can now consolidate orders into shipments based on their origin and destination warehouse.
• Purchase and sales order linked to a project can now be added to loads and used with transportation management processes.
• Performance: Improvements to the on-hand stored procedure that is used to calculate on-hand inventory.
• Performance: A new clean up job for deleting closed on-hand entries in InventSum and WHSInventReserve has been introduced.
• Performance: Registering product receipt and querying for a put away location has been improved when using Volumetric and Stocking limits constraints for locations.
• Performance: Closing of containers during pack operations have been improved by avoiding some client/server calls.
• Performance: Containerization as part of wave posting have been improved and optimized when scaling number of sales lines per order.
• Performance:Queries during processing of large waves with many allocation errors has improved.

The following table shows an excerpt from the What’s new document for CU10 on a more detailed list of the enhancements for CU10 in warehouse and transportation management. Please note that all linked TechNet pages will be updated in the coming weeks to reflect the new content added.

As part of the planned enhancements around serial number functionalities, the capability of picking sales serial number items is now possible when using the AX 2012 R3 CU10 warehouse management processes. You can also find it on LCS with KB 3072929.

This functionality enables the process of capturing serial numbers during the mobile device sales order picking or packing process, without making unique inventory transaction records holding this information.

The benefit of this logic is that AX can handle many serial number records without needing to create the time consuming logic around the “inventory transaction framework”.

Conceptual data model for serial number registration

As it can be seen from this conceptual model, the sales serial number tracking will be linked to the inventory transaction origin and it is important to understand that the actual validation of unique sales serial numbers is done against this entity.

Existing information regarding sales serial numbers in AX

The following blog post describes the overall concept of Sales serial number tracking:

Serial Number Tracking for Service and Warranty in Microsoft Dynamics AX R3

TechNet information about registration of serial numbers in AX2012 can be found here:

Register serial numbers for a sales order [AX 2012]

Enable the sales serial number tracking

Because the sales serial number tracking is not done at the inventory transaction level the released product will not use a reservation hierarchy with serial number tracking. For this blog post example, a new product is created using an Inventory reservation hierarchy as shown below:

The released product has been associated with a Tracking dimension group using the Active in sales process parameter for the Serial number dimension, and as it can be seen the Capture serial is now possible to specify. For the first example the Capture serial is set to “Picking”, which means that the actual registration of the sales serial number will be done during the mobile device picking process.

In case enabling the Capture serial to “Packing” the sales serial number recording will be requested done during the manual packing station process.

Recording of sales serial numbers during the picking process

The concept of using the sales serial number capability is that the recording of serial numbers only happens for the outbound sales process. So the inbound receive process and all internal transfers of inventory on-hand will be done as other released products without serial number tracking.

For this blog post example, a license plate of the quantity of 100 of the product has been received and put-away into the warehouse and the serial number dimension is not part of the inventory on-hand:

A sales order line has been created for the quantity of 3 and released to the warehouse and work has been created.

When processing the work, the mobile device will prompt for identification of each of the sales serial numbers because of the Capture serial set to “Picking” on the Tracking dimension group.

It is possible to access the sales serial recording done against the sales order line through the Load details form.

During the sales serial number recording, validation is done to ensure unique capturing of sales serial numbers against the sales line.

In case of a not readable serial number the function of using Not readable can be used which will register the serial number as not readable.

When all serial numbers have been registered and the inventory has been put on a final shipping location, the related inventory transactions for the sales line will get the status picked and the sales order packing slip can be processed.

Recording of sales serial numbers during the packing process

In case the released product is associated with a Tracking dimension group enabled for Capture serial at “Packing”, the mobile device picking process will behave as for products without serial numbers. Instead, the serial number will be registered when using the pack station.

Validation is run ensuring the correct quantity of unique sales serial numbers gets registered during the packing operation and it is possible to view and maintain the recorded serial numbers from the Containers form.

Recording of sales serial numbers during the sales order return process

Besides the outbound sales order serial number tracking, it is now supported to capture the serial numbers being part of a sales order return process through the mobile device.

The flow will request registration of the serial numbers being returned.

Recording of sales serial numbers via Picking list registration form

For simpler/small warehouses, it is also possible to record sales serial numbers during the warehouse picking process from the Picking list registration form, making it easier to record the serial numbers during the actual picking process.

This blog post describes how to process warehouse management activities related to project management when having warehouses and products enabled to Use warehouse management processes in MicrosoftDynamics AX 2012 R3 CU10. This functionality is also available from LCS with KB 3096930.

Processing of item requirement sales orders

When using the item requirements form it is now possible to directly Release to warehouse and access the Load planning workbench form.

Item requirements sales order processing in the warehouse management area will be done the same way as for regular sales orders. Even the capability of mixing item requirement sales orders with regular sales orders on the same load is possible. The only differences seen will be as part of the physical cost updates done through the packing slip update process. Here the packing slips will be split and the updates related to the project transactions will be directly updated to Sold.

Let’s try looking into a quick example based on the demo data for the company USMF.

A new item requirements sales order has been created and via the new menu it is possible to Release to warehouse directly from the Item requirements form.

After processing the outbound warehouse work, which will result in getting the inventory transactions updated to status Picked, and having done the confirmation of the Outbound shipment, it is time to process the sales order packing slip update.

During the actual posting, the related item requirements inventory transactions will be updated to Sold.

Processing of purchase order related to project

When processing a purchase order registration for lines referencing a project, the project inventory transactions will become physically reserved with the same dimension values as registered for the purchase order line transactions. During the purchase order product receipt posting the project issue transactions will become updated to Sold.

Let’s look at an example based on the demo data for the company USMF.

A new purchase order line gets created with reference to a project.

Before processing the inbound registration, the related project issue transactions will be Reserved ordered.

As soon as the inbound purchase order transactions gets Registered, the related issue transactions for the project will be updated with the same inventory dimension values and updated to physically reserved on all inventory dimension levels.

It is important to note that inbound ‘put-away’ work will not be created when using the mobile device purchase order receive processes. The reason for this is that during the following purchase order product receipt update, the issue transactions will become Deducted and thereby immediately removed from the inventory and therefore internal transfers between locations within the warehouse cannot be done.

Processing of production order related to project

When processing a production order linked to a project, conceptually the same will happen as in the previous scenario with the purchase order process. One key difference is with the mobile device inbound processing. When doing the Report As Finished process the receipt inventory transactions becomes updated to the status of Received and thereby the related project issue transactions will become Deducted. As for the purchase order inbound processing no ‘Put-away’ warehouse work will be created when using the RAF mobile device functionality for production orders referencing to projects.

Posted on behalf of Simon Juul.

Many companies have agreements with customers to deliver their orders on a regular basis, for example weekly deliveries. In order for TMS in AX to be able to support transportation routes executed regularly, a new feature for “scheduled routes” have been introduced with CU10 or separately from LCS with KB 3107317.

A scheduled route is a predefined route with predefined hubs (that being vendors, customers or warehouses) you execute regularly on a given schedule.

The new functionality for scheduled routes consists of:

1. You can set up route plans on a defined schedule and build scheduled routes based on it.
2. Use Load building workbench to propose loads based on the orders, using customer address and delivery date and the corresponding scheduled route.
3. Use the Rate route workbench to manually assign loads to an existing scheduled route.

This blog post will take you through the necessary setup and how to create, process and use these route schedules.

Set up scheduled routes

First of all, we need to create a route plan starting from the warehouse where we ship from and with hubs that have the same zip code as the customers we are going to visit on the route:

Transportation management > Setup > Routing > Route plan

The route plan for scheduled routes is a bit different than normal route plans as you need to specify “Origin hub” and “Destination hub” on each segment, as this is a fixed route and the customers are found by the zip code match. The route plan starts from our warehouse 61 and stops at a customer in the first sequence. A hub master has been setup with the same zip code as the customer in question. In the next sequence it goes to the next customer hub and so on until all customer hubs have been visited.

For this route plan we then need to setup the schedule for when it’s going to take effect. You do this by clicking Create route schedule. A new form is opened where you can specify on which dates and time the route is visited and with what mean of transportation (load template):

Transportation management > Setup > Routing > Route plan > Create route schedule

On the Route schedule form, you have to specify the “actual start date and time” and “actual end date and time” as the period you want to have the scheduled routes generated for. You can specify the “Load template” which is being used as default on the Load building workbench and when you push the “Generate Routes” button a batch job will start generating routes based on the setup.

To be able to use scheduled routes a route guide has to be set up. For scheduled route plans you should use one Route guide and specify only the route plan, because the route plan used for scheduled routes is not open for any other criteria such as “Origin hub” and “Destination hub” as they are specified on all segments.

Transportation management > Setup > Routing > Route guide

Use Load building workbench with scheduled routes

In the Load building workbench you are now able to select a scheduled route and build a load with all sales orders matching the zip code in any of the destination hubs in the route plan.

Transportation management > Inquiries > Load building workbench

The Load building workbench has a new dropdown named Scheduled Route. You can only select scheduled routes that does not yet have any loads associated.

Selecting a scheduled route will disable the other criteria for Origin and Destination except the shipping from date, so you are able to find sales orders with an earlier ship date. You still have to select a load building strategy and have the possibility to use filter codes. The Load template will be defaulted to the one you selected on the route plan schedule or else you will have to specify one.

When proposing the load, the zip codes of each hub on the route will be matched to the zip codes of the Sales orders and the range of the “shipping date from” and “shipping date to” dates will be matched to the shipping date of the sales orders. There has been no change as to how selected load building strategy and load template will be used, it will work as in previous versions.

When pushing “Propose loads” you will see only one load with the sales orders matching the above criteria and the allowed quantity prescribed by the load building strategy and the assigned load template.

If you select to create the load it will be assigned to the already created scheduled route and the transport is planned.

If you have sales lines in the “Not included” you have to either choose a bigger truck (Load template) or arrange another transport (maybe use load planning workbench for the remaining lines).

Use Rate route workbench to manually assign loads to a scheduled route

If you want to manually assign a sales order to a scheduled route in the Load planning workbench, you can either create a new load if you want the first (date wise) Scheduled Route that does not have a load or you can “add to existing load” that already have a Scheduled Route assigned. When creating a new load and put it on a scheduled route:

Transportation management > Inquiries > Load planning workbench > Rating and routing > Rate route workbench

There is a new menu saying “Scheduled Route”, which will show the first Scheduled Route without a load and with the shipping date closest to the sales order ship date. You can use the “assign” button to pick the actual Scheduled Route with the rates calculated. But you can also select “Add to existing route” to choose a scheduled route further out in future.

 In this blog post you can read about how to use the Work audit template functionality to automatically process an Outbound shipment confirmation for a Load as soon as all the related work has been processed.

The screenshots in this blog post are taken from the new version of Dynamics AX, but all the content applies to AX2012 R3 as well.

The scenario described below is used to illustrate the process and setup for using a work audit template.

Process

A load has been created containing two load lines that are going to be delivered.

The load will be outbound processed within the warehouse via two work headers.

After a mobile device has been used to complete the first work item, the status of the load is updated to In process. And as soon as the second work item is completed, the status of the load is changed to Loaded. And with the use of the Work audit template, the system will immediately update the load to the status of Shipped.

Setup

To enable the scenario above, a Work audit template record has to be created to trigger the event of running the Shipping confirmed update as soon as the status for a load is updated to Loaded. This can be achieved with the setup seen below.

The mobile device menu item that’s used as part of the outbound warehouse work processing has been enabled to use the defined Audit template ID.

Conclusion

The work audit template is used in this case to trigger a ship confirmation update when the status of a load is updated to Loaded. It’s possible to define other triggers, and to define triggers for other events too. We think that work audit templates are a great tool for extending custom logic and triggering automatic events and custom code with specific set of rules, and would love to hear about your experiences with it.

In the recently released CU10 update we are introducing a new over picking feature. It is also available with KB 3107010 on LCS. This blog post will take you through the details of feature and for which scenarios it is aimed for.

Background.

In the warehouse operations we are handling goods in different ways and in different unit of measures.

Inventory can be stored in barrels, pallets, boxes, pieces and many other units. Same item can be stored in different handling units and can be picked from those handling units as requested in the quantities specified in source documents like sales orders and transfer orders.

What is important in warehousing processes is to be as fast and as lean as possible in order to save time and effort, when picking and shipping items.

So in a normal picking scenarios we can easily end in a situation where e.g. the sales order line tells us to pick 50 L of water due that customer requires that, but our packaging is maybe in 60 L barrels. In order to pick the 50 L, picker will need to open 60 L barrel and basically use time and effort to move 50 L in another barrel in order to be able to ship correct quantities.  That requires extra time and effort.

Same experience could be with pallets, as for example, where customer ordered 98 and the pallet contains 100, saving time will be to ship 100 instead of opening the pallet to restructure to 98 pieces.

The other example could be if the picker cannot define how much is picked until later in the process.

Let’s assume that we need to pick corn, customer ordered 30 Tons of corn, machinery will be used to fill the truck with the corn or bags might be loaded instead. Normal process is that when truck is loaded, it will go to the weight scale and employees might experience that measurements shown more than 30 T, let’s say 30 T and 500 Kg. if the customer needs to pay for delivered goods and not what is on order, there is a need to record over picked quantity. Going back with truck or unloading those extra 500 Kg is for many organizations not possible due to extra time and effort needed. You will just want to send that truck to customer as soon as possible with correct information but with no extra effort and time needed.

In many organizations this kind of situations can be avoided if the system supports possibility in the Warehouse for controlled over picking scenarios.

Functionality can be used, as for example, for following business scenarios in the warehouse:

• Compensation for shrinkage during picking or shipment
• Ability to avoid to unpack certain packaging material in picking process
• Compensate for the item damages during transportation
• Be able to ship quantity or unit of measure variance
• Minimize breaking of quantities on License plates
• Avoid material waste, scarcity of the expensive materials.
• Post pick measurement of the picked quantity (example with a lorry weighting).

What was our goal?

In the new Microsoft Dynamics 2012 R3 CU10 update, we have introduced possibility to process controlled over picking on the mobile scanner during the picking work.

We have decided to do that for both Sales order and Transfer order picking and processing.

Our goal was to enable the possibility to choose if a customer should be invoiced for picked quantity or for the quantity specified on the source document line “The ordered quantity”.

Our goal was as well to be able to control who of the picking workers can do the over picking and if that is for both transfer and sales order to make system as flexible as possible.

At the same time, we wanted to enable visibility of the over picking feature on the bar code scanner to be configured separately for mobile device menus, regardless if the worker has permission to over pick or not.

Minimizing maintenance and keeping flexibility of the setup was the goal.

How did we do it?

We have used already existing functionality for over delivery on Sales order and Transfer order source documents, where we can define how much in percentage do we allow to be over delivered.

In order to enable over picking on the mobile device, we have added a check box on the menu item itself, to enable over picking for that particular menu item. However even if the worker has the barcode scanner menu that includes the menu item for sales order picking where we have enabled over picking, worker setup for over picking must be enabled same time on worker form as well.  Only if both enabled, over picking can be processed using the mobile device.

Please note that flexibility is kept in the sense that if we have many mobile device menus and we do not know exactly where we have enabled over picking, and we want to disable possibility for a certain worker to over pick, we can simply switch it off on the worker setup without changing the menus and menu items.

However, if we want to disable over picking for all, we can go to menu item for example sale order picking and disabling it there all of the workers who have that menu item in their menu setups for barcode scanners will not be able to over pick anymore.

Setup on the worker form:

Go to Warehouse management > Setup > Work users > Worker > Users.

Please note above that you can setup sales order and transfer order over picking separately on each worker setup.

Setup on the menu item:

Go to Warehouse management > Setup > Mobile Device > Mobile device menu items.

Please note: When over picking is enabled it will fully respect limits set for over delivery on the line level of the transfer orders and sales orders. If the limit is exceeded, employee will be notified on the mobile device that they are exceeding the limit.

Step by Step use:

When work has been generated, and above setup is enabled we are ready for over picking.

Here we will give an example of how we can over pick quantity on the sales order line respecting the limits for over delivery that are given.

We will create a sales order for item A0001 with a quantity of 10, and enable over delivery of 10 percent on the delivery tab on the sales order line itself.

We will then reserve and release quantity as we usually do and work to pick 10 will be generated.

After that we can start the sale order picking menu item on the RF gun (make sure that user that is logging on the mobile device is the one with enabled over picking configuration).

We enter work ID and we can see that we have a new button for over picking.

If we decide to over pick we will select “Over Pick” and following screen will show. Please note that we have entered 14 which exceeds over delivery limits set of 10%. Our limits allow us to over pick 1, so 11 in total.

If we try to do with 14, the system will generate a message on the RF gun that limits are exceeded:

Entering the right quantity of 11 we can proceed with over pick and later put.

If we look what was updated behind the scenes, we look first at the work line that is not closed. We can see that work has been updated to 11 pcs as that was the total quantity picked during over picking.

Looking at the shipment and load, we have updated line of 11 pcs as well.

However, if we are looking at the source document line itself, in this case sales order line, we can see that we still keep original quantity of 10. We do not update that on purpose in order to be able to invoice the customer on either ordered or picked quantity.

Please note, that if you invoice the ordered amount the “non-invoiced” quantity remains in a Deducted status (physical update, no financial update).

Please see below from another sample where we have ordered 3 ea, picked 5, and invoiced 3.

Thanks for reading, and if you have any comments or feedback about this feature, please leave a comment below.

Please note: Similar functionality for raw material picking called “Round up work for raw material picking” will be released with KB number 3120530. This feature will round to  the UOM, and thereby enable over picking for raw material picking through the rounding concept.

Posted on behalf of Karina Normann Jakobsen.

Introduction

In Dynamics AX 2012 R3 CU10 we have introduced additional capabilities to change license plate, split quantity, skip or override location on the mobile device while doing inbound put away. These features can also be downloaded from LCS with KB 3103960.

Issues

The workflow used when performing inbound work had some limitations when it came to the ability to:

Split put quantity: When the warehouse worker walks down to a location and can visually see, that the item does not fit into this location, the warehouse worker cannot split the item onto multiple locations. This is especially an issue if the location directive does not resolve a specific location and the location of the put instruction on the work order is blank.

Consolidate items on license plate already on a location: When the warehouse worker walks down to a location with ½ a pallet of items and the location already contains ½ pallet, the warehouse worker cannot register the item on the pallet originally on the location.

Cancel button missing in flow: When executing inbound work, there were many places, where the user couldn’t cancel out of the flow. If the user wanted to cancel out, the only option was to end the flow from the rich client.

Skip: When executing inbound work for multiple items at different put locations, the user is forced to execute the put lines if a fixed order.

Mobile device menu item with Group put = true: When performing work using a mobile device menu item, where Group put = true, the warehouse worker could be lead into strange flows on the mobile device. The mobile device menu item parameter Group put was not available for work creation flow …and put away.

Use unique check digits: Scanning a check digit in the location field on the mobile device menu item would resolve the first location with that check digit independently if Use unique check digits on warehouse was Yes or No.

Disposition code: The mobile device disposition code was not used when suggesting a new location as part of executing a put. The reason was that the disposition code was not saved in the system.

Solution

The solutions described in this blog post about the above issues are implemented for the work order type Purchase order, Finished goods put away, Co-product and by product put away, Transfer receipt, Inventory movement, Return orders and Kanban put away using a mobile device menu item with the settings in the below table.

An exception is Work order of type Replenishment which has uptake only of the ability to consolidate items on an existing license plate and the missing cancel button.

The below table describes the supported flows on the mobile device where these solutions have been enabled.

The next section of this blog post will present each issue and how the solution work.

Cancel button missing in flow

On the mobile device a Cancel button will be available in all steps of the flow. Click Cancel will interrupt the processing of the work order for the work order line in focus, when the Cancel button was clicked.

Split put quantity and override location

An open work order of work type Purchase order exists.

Mobile device flow

As a result of changing the location, the work put transaction was split.

Pay attention to the fact that Split Put is NOT supported in combination with grouping of work lines of type put.

Consolidate items on license plate already on a location

When performing the work with a mobile device a new parameter on the mobile device menu item has to be configured. The name of the parameter is Override license plate during put.

An open work exists for item M9200. The put location in this example is Bulk-001.

Bulk-001 is a license plate controlled location. There is already ¾ pallet on Bulk-001 on license plate LP920001.

Mobile device flow

Skip

Using the Skip button will mark the work order line as skipped and the next put operation will be presented to the user.

It works as following. A work order exists with multiple put lines.

Mobile device flow

Mobile device menu item with Group put = true

Some unintended flows were observed when performing work using Mobile device menu items, where Group put was set to Yes.

Group put will function if the put location is resolved for all work order lines of type put and if the put location is the same for all work order lines grouped.

Here are a few examples to illustrate the above.

Example 1 – Multiple work orders are grouped – all work order lines of type put have blank Location

The previous behavior was inconsistent depending on the work flow and the work order.

The rule is now consistent. If the location is blank, work order lines of type Put will not be grouped.

If we have two work orders where location field on the last work order line for each work is blank.

Work order where location is blank:

You have a mobile device menu item that is configured to perform existing work.

Directed by = User grouping.

Group put away = Yes

Mobile device flow

Example 2 – Multiple work orders are grouped – some work order lines of type put has same location, some has not

The previous behavior was inconsistent depending on the work flow and the work order.

The rule is now consistent. The location on work order line of type put has to be the same for all work orders grouped.

First work order has 2 work order line of type put with 2 different locations.

Second work has 2 work order lines of type put with 2 different locations. It is the same 2 locations as on the first work order.

Mobile device menu item is configured to perform existing work.

Directed by = User grouping.

Group put away = Yes

Mobile device flow

Example 3 – Multiple work orders are grouped – all work order lines of type Put have the same location

Two work orders exist.

First work order has 2 work order line of type put with location FL-001.

Second work order has 2 work order lines of type put with location FL-001.

Mobile device menu item is configured to perform existing work.

Directed by = User grouping.

Group put away = Yes

Mobile device flow

Pay attention to the fact that Split Put is NOT supported in combination with grouping of work lines of type put.

Example 4 – Group put away is now available on work creation flows …and put away

You can set Group put on all work creation processes that ends with … and put away.

For example:

Use unique check digits

The parameter Use unique check digits is found on the warehouse setup.

When Use unique check digit is No, this means that check digits on many locations can share the same check digits. When many locations shared the same check digit, scanning of check digits in scenarios where location was blank or the user was overriding a location was not supported. This didn’t function in all work flows. All inbound flows have been changed, so that scanning of a location check digit will not be accepted if Use Unique check digit is No.

Example 1 – Use unique check digit is No, user scans location check digit on mobile device

Use unique check digit = no on warehouse 24.

Warehouse 24 bulk locations has check digits.

Mobile device flow

Example 2 – Use unique check digit is Yes, user scans check digit on mobile device

Use unique check digit = yes on warehouse 24.

Warehouse 24 bulk locations has check digits.

Mobile device flow

Disposition code

Mobile device disposition code is now saved on the work order header. The mobile device disposition code is used to find the correct location directive if user clicks Override Loc on the mobile device.

In the recently released CU10 update we are introducing a few new replenishment features that will increase warehouse productivity and save effort and time. This blog post will take you through the details of the features and for which scenarios they are aimed for.

In this blog we will cover following:

• Relation between replenishment work, demand, and cancelation of the demand.
• Directive code capabilities on work template for replenishment

How did it work previously, and what was the challenge?

In Microsoft Dynamics AX 2012 R3, min/max replenishment and demand replenishment did not recognize one another, and both types of replenishment did not recognize existing replenishment work that was in progress or not started yet. Sales demand and existing replenishment work generated for the demand, did not know each other’s status.

That resulted in the following 3 problems and possible obsolete replenishment work transactions and waste of time in the warehouse facility:

1. If we had let’s say sales demand work of 10 each, and demand replenishment setup has generated replenishment work of e.g. 1 Pallet (100 each) due to setup and that replenishment work is not yet processed. If new sales demand of 10 each comes, what will happen is that demand replenishment setup will again generate the new replenishment work of 1 Pallet (100 each) due that there is no increase in quantity. In this case we will end with 2 work with 1 pallet on each that in total is 200 each and in total sales demand is only 20. This tells us that second sales demand could have been covered with the first replenishment work due to that there was 90 each not yet reserve.
2. Many customers will run min/max replenishment in the morning as a batch job, and generate a series of replenishment work to fill up their locations. Before CU10, what was happening is that if min/max replenishment work was not processed before demand is sent to the warehouse, demand replenishment as the exception management will create new replenishment work for the demand. Result will possibly be, that we will have two replenishment work generated using two different strategies, min/max and demand replenishment. However, if the demand replenishment was aware that there was the existing min/max replenishment not started with free unreserved quantities of item with same dimensions there would be no problem.
3. The other problem was that if e.g. sales demand triggers generation of replenishment work, and replenishment work has not been processed, but sales demand work is cancelled and sales order line deleted, replenishment work will still stay open. This challenge potentially resulted in replenishment work being open that are not needed or even will not fit at the locations due to that demand being cancelled.

All of the above was potentially creating noise and unnecessary open work transactions, overload of the items on the target replenishment locations, or a huge manual workload to synchronize demand and open replenishment work. For any warehouse facility with large number of locations that are either being replenished with min/max or/and demand replenishment, the above challenges are not acceptable. 

What was our goal?

• Create awareness and link between different types of open replenishment work.
• Cancel the existing demand replenishment work that has not been started if the demand has been cancelled and there is no other demand work related to replenishment work.
• Deduct new demands from existing min/max or demand replenishment work in order to minimize amount of work transactions, if there are unreserved quantities on the existing replenishment work. First after all available quantities is deducted new replenishment should be created.
• Make setup flexible

How did we solve above challenges?

In the new CU10 update, the replenishment setup for both demand and min/max replenishment, we have added the ability to define if the replenishment template, from generated work, will allow unreserved quantities to be used and deducted from by new demand quantity.

In the same setup we have added the ability, to define if the replenishment work should be cancelled if the demand has been cancelled (please note that if there is any existing work that is related to that replenishment work it will not be cancelled).

In the above setup all of the replenishment work generated and not processed will include new demands if the unreserved quantity allows. After all is used and deducted, new replenishment work will be created if needed. 

In same way, if there is a min/max replenishment template that is configured to allow demand to use unreserved quantities, and has generated work, even if demand replenishment method is enabled it will first see if any of the quantity from existing work can be used.

This minimizes amount of the work lines created, where quantities can be deducted from existing replenishment work.

Please note that setup is template centric, which means that we can allow deduction and cancellation on one, but not the other template. 

Directive code enabled on work templates for replenishment work order type!

In CU10, we have also enabled configuration of the directive code for replenishment work order type.

Continue to second replenishment template sequence capability if put location is not resolved in previous sequence line!

Before the CU10 update, having several sequence lines in the Replenishment template lines where first one could not solve the demand, system was not continuing to another line sequence. This only counts if PUT location could not be resolved due to a location failure or stocking limits.

Now if the first sequence line fails to resolve put location and fulfil replenishment, next line in sequence will be processed.

Please note: In order to proceed to another replenishment template line, you need to setup Location directive failures to stop work on Replenishment failures,  as shown below. If not set, it will end with an empty put location, and will not proceed to next sequence line in Replenishment template.

This feature is useful if we e.g. have stocking limits on a locations or locations fail for some reason due to other restrictions or setup. In that case system will proceed to another template and use put from location directives connected, that could be as for example an overflow location.