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)

Dear readers,

The SCM-costing team is happy to announce that an update for the "Post to charge" accounting principle is finally ready.

The update includes a significant change in the ledger accounting logic consumed by the "Post to charge" accounting principle. This change might require that customers reconfigure their posting profiles in order to get the correct accounting entries in the general ledger.

Configuration

The "Post to charge" accounting principle is still enabled through parameter configuration.

Path: Accounts payable> Setup> Accounts payable parameters

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

Note: The "Post to charge" accounting principle now has a dependency on the Post product receipt in ledger parameter. The system will validate the current settings and warn customers in case of a conflicting configuration.

Accounting for material

The "Post to charge" accounting principle originally used two designated posting types:

• Charge
• Stock variation

The new accounting logic will make the Charge posting type obsolete.

Instead, the Purchase expenditure, un-invoiced and Purchase expenditure for product posting types should be used for accounting charges of the Material type in General ledger.

The Stock variation posting type will act as stock variation for direct material cost.

Accounting for purchase overhead

The Estimated indirect absorption and Indirect absorption posting types will now act as stock variation for overhead cost.

Accounting for Miscellaneous charges

The patch for "Post to charge" has intentionally been delivered after the release of the "Post Misc. charges on product receipt" feature. You can read more about this feature in this blog post: http://blogs.msdn.com/b/dynamicsaxscm/archive/2014/11/11/post-misc-charges-at-time-of-product-receipt.aspx

The reason for the delayed release was that miscellaneous charges that are accounted for at the time of product receipt are now correctly treated by the posting logic of the "Post to charge" accounting principle.

Miscellaneous charges on a purchase order can affect the valuation of inventory assets under two configurations:

• Debit item - Credit Ledger account
• Debit item - Credit Customer/Vendor

In the case of Debit item - Credit Ledger account, the ledger account selected as the absorption account now acts as a stock variation account.

In the case of Debit item - Credit Customer/Vendor, the miscellaneous charges will be accounted as material cost, and the stock variation account of the item will be used.

Example 1

Prerequisites for this example:

• Item: #mq-1
• Valuation method: FIFO

1. A purchase order of 1 piece is created. A unit cost of 100.00 is agreed on.

1. Confirm the PO.
2. Post the product receipt.
3. Validate the posting of the product receipt.

   Validating the ledger accounting entries in the voucher

Validating the physical cost amount on the inventory transaction

1. Post the invoice, and validate the postings.

   The unit price has changed since the product receipt was posted. The unit price is now 110.00

   Voucher of the invoice

Validating the financial cost amount on the inventory transaction

Example 2

Prerequisites for this example:

• Item: #mq
• Valuation method: FIFO
• Misc. charge 1: Debit item - Credit Ledger account 10.00%
• Misc. charge 2: Debit item - Credit Customer/Vendor 10.00 Proportional
• Indirect cost: 2.00% on top of purchase price

1. A purchase order of 1 piece is created. A unit cost of 100.00 is agreed on.

1. Assign the miscellaneous charges codes, and allocate them to the lines.

1. Confirm the PO.
2. Post the product receipt.
3. Validate the posting of the product receipt

   Validating the miscellaneous charges amount calculated and accounted on the product receipt

Validating the ledger accounting entries in the voucher

Validating the physical cost amount on the inventory transaction

1. Post the invoice, and validate the postings.

   For the sake of simplicity, there is no change in unit price in this example, and no additional miscellaneous charges are added.

   Voucher of the invoice

Validating the financial cost amount on the inventory transaction

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 be available at a later time.)

The Advanced Warehousing functionality introduced in Microsoft Dynamics AX 2013 R3 includes a brand new Warehouse Mobile Device Portal (WMDP). This portal serves HTML pages which drive the work executed within the warehouse. We have designed the portal to generate HTML that is widely compatible on a variety of devices, and although we do not recommend any specific devices – any device that supports a basic Internet browser or browser emulator will operate with the new warehouse functionality. This is further explained in this blog post: http://blogs.msdn.com/b/dynamicsaxscm/archive/2014/07/18/which-devices-can-you-use-for-warehouse-mobile-device-portal.aspx

The devices we see deployed with the advanced warehousing solution are often rugged industrial equipment, designed to work within the hostile environment of the warehouse. These often support integrated barcode scanning and can survive the occasional accidental drop. With an often significant investment in these devices we wanted to ensure the Microsoft Dynamics warehouse solution works across the widest possible distribution of devices. We also wanted to ensure the workflows and capabilities exposed by the mobile device interface were flexible enough to match the business processes of your warehouse. Thus the entire interface that is built and rendered on the mobile device is extremely flexible – with the entire menu system and workflow exposed and extensible both from within core AX and through partner code.

This blog post is the first in a two part series that will cover customizing the mobile device portal. This post will cover the options exposed in Microsoft Dynamics AX 2012 R3 to build custom mobile workflows for your workforce and how to build different mobile experiences depending on user and device criteria. The next blog post will cover the deeper code underpinnings of the mobile device portal and how it can be extended to expose additional workflow options.

Menu

At the heart of the mobile device portal interface lies the concept of Menus and MenuItems. These are configured in AX by navigating to Warehouse Management -> Setup -> Mobile device. The high level concept of a Menu is simply a flexible container that can contain both MenuItems as well as other Menus (i.e. it is a nestable structure). Thus it is possible to construct an interface for your users that provides exactly the capabilities required for the role they are assigned. For example, it is possible to build a Menu that only exposes the outbound picking operations for a certain segment of warehouse workers, and have a separate menu structure used by the forklift operators for replenishment operations.

The menu item interface can be seen below. Menus can be defined in the top section, and MenuItems can be added to the selected Menu in the lower section from the list of all available MenuItems in the bottom right list.

MenuItem

Defining a MenuItem is done in the Mobile device menu item screen – and there are a lot of options available for configuring the workflow exposed to the end user. A complete description of all fields available on this screen can be found at the following TechNet article: https://technet.microsoft.com/en-us/library/dn553216.aspx. This blog post will try to simply touch on the high-level functionality of MenuItems – please see the TechNet article for more details regarding the options available.

MenuItem - Mode

When creating a new MenuItem, you first must decide the Mode that this activity will be operating under. This can be "Indirect" or "Work." This defines if the MenuItem will interact and operate on Work in the warehouse (i.e. Work mode), or if it will support some sort of ancillary process in the warehouse not directly related to a Work line (i.e. Indirect mode). Selecting the Indirect mode will cause the UI to display the list of "Activity codes." This allows the user to select the non-work related workflow that will execute when this MenuItem is selected on the mobile device.

Again – the complete list of activities can be found in the TechNet article, but the following are a sampling of the possible workflows:

Changing the Mode to "Work" will change the UI significantly. It will now be possible to select the checkbox "Use existing work." This will configure the MenuItem workflow to either consume an existing Workline (checked) or to generate a new set of Work (unchecked). By leaving the checkbox unchecked (i.e. not to use existing work) the user will be able to define the exact work creation process required to generate new work through this MenuItem. This is often used when receiving items and/or starting putaway work.

There are various options available when defining the work creation process that will get initiated by this MenuItem. These will differ depending on the exact work creation process workflow selected – all of the various options are described in detail in the TechNet article referenced above. All of them are available to allow you to customize the exact business process that is enabled by the mobile device user.

Changing the selection to "Use existing work" will indicate that this MenuItem will process existing Work lines – and thus must be configured define exactly how that work should be processed. Again there are a multitude of options available to configure exactly how the workflow should proceed. In addition, two very important settings must be configured: how this work is directed, and the work classes available to process.  The Work classes section defines the valid work that this MenuItem can process; this can be used to restrict access to certain user roles or to separate processing logic for different types of operations.   

The "Directed by" setting defines exactly how the work will be selected for the mobile device user. This is a very important setting – as this is how the system will know what work to assign to a particular user. All of the options are defined in the TechNet article – these are copied here for convenience:

Work Users

In order to access the WMDP one needs to create at least one warehousework user, which has a user name, password, default warehouse, and available mobile menu. In order to create a warehouse work user, a worker will first need to be defined within the HRM module. The HRM worker is typically associated with an AX user mapped to an active directory identity (through user associations defined in the administration module).

After creating the HRM worker, one can assign a number of warehouse work users to it through the "Worker" form accessed under Warehouse management -> Setup -> Work users -> Worker. You can think of the warehouse work users as a number of logins for the selected HRM worker – each one which can provide a default warehouse and targeted workflow exposed by the menu. Obviously it is also possible to simple define all your warehouse work users under a single HRM worker, but this is not the recommended pattern.

A warehouse work useris defined very simply with a user ID, user name, default warehouse, and a menu. This menu is loaded when the user logins into the portal, and is how different experiences can be tailored to different logins. For example, in the screenshot below we have created separate menus for the UPS drivers, the Forklift operators, and the primary warehouse workers. Each have a different set of MenuItems available, specifically only the ones required for them to perform their jobs effectively.

Mobile Site Customization

CSS Customization

The site that is created by the configured Menu and MenuItems can be further customized through a variety of options exposed through Microsoft Dynamics AX. These options are available through the work user mobile device display settings form – seen below. This screen allows a CSS file, display settings view, and keyboard shortcut settings to be defined for a set of criteria. This allows different displays to be rendered for different types of devices or browsers.

The most obvious way to customize the mobile site is through CSS customization. The default css file shipped with the mobile device portal (defaultrf.css) can be found at <AX Installation directory> \6.3\Warehouse Mobile Devices Portal\<WMDP Instance folder>\Content\CSS\RFCSS. This file defines the basic look and feel of the UI and includes things like the background color, text font and size, and the width and behavior of the rendered buttons. The default login screen is rendered in the following manner:

The overall look of the interface is defined by the default css file, which includes the following settings:

Note the background color and button colors have been customized, as well as the layout (100%) of the button and the hover behavior of the buttons. By removing all of the default css and replacing it with the following simple css, we can dramatically change the look of the UI:

This is achieved with the following css file:

body
{
    background: #777777;
    text-align: center;
}

.whsLabel
{
    font-size: 15pt;
    color: #FFFFFF!important;
}

.whsTextLabel
{
    color: #FFFFFF;
}

.whsPasswordLabel
{
    color: #FFFFFF;
}

Note the requirement for the important keyword in the .whsLabel class definition. This is because all whsLabels are generated with an embedded color component defined in the "mobile device text colors" form (or defaulting to black). This form can be found at Warehouse management -> Setup -> Mobile device -> Mobile device text colors. Unfortunately this form does not allow criteria based filtering or customizing on the generated colors, so utilizing the css styling is the recommended way for updating the text colors.

The ability to change the look and feel of the generated HTML is more important than simply wanting a different background color or text color may initially appear. Different devices used in the warehouse may impose strict limits on what can or should be displayed for optimal visibility and usability. The need to specify a specific width or a specific format for buttons may be a requirement for the specific device utilized in the warehouse, in which case the css styling is a must for enabling the workflow.

Keyboard shortcuts

Another facility exposed in the "Work user mobile device display settings" form are keyboard shortcut definitions. These allow you to customize what hardware keys trigger different MenuItems. It is possible to map specific buttons to MenuItems such that when the MenuItem is visible users can press the hardware button to trigger the functionality on the device. This is often useful for warehouses when devices are used that have obvious keyboard mappings to specific functionality in the portal.

The format for setting up keyboard shortcuts is very specific, and the entered string must match the required format exactly so as to be registered into the client-side JavaScript correctly. The required format string for each shortcut is (note they can be appended together with a semi-colon):

<control name>(<key name>)=<javascript key code>;

The control name is the value of the "id" attribute in the generated HTML. This can be easily found by examining the generated HTML in a browser or developer tool. The key name is a string value displayed to the user in the button text – this is designed to help the user understand the available hardware button options. The JavaScript keycode is the value exposed from the JavaScript onKeyDown/onKeyUp methods.

An example keyboard shortcut string is:

Login(L)=76; Full(F2)=113

This would cause the "L" hardware button to execute the Login button automatically, and the "F2" hardware button execute the Full button. The generated HTML would inject the key name values into the button text, so the above string would result in the following pages:

Display Settings View

The last option available on this form is the "Mobile device display settings view." This describes the name of the ASP.NET view file used to render the mobile site in the server-side ASP.NET application. This file controls how the overall structure of the HTML is laid out and customizing this functionality is only recommended if you have serious structural issues with the HTML and JavaScript that need to be changed for your specific devices. Note that, like the CSS files, there is a specific directory where these files need to be located so the IIS application can load them - <AX Installation directory>\6.3\Warehouse Mobile Devices Portal\<WMDP instance folder>\Views\Execute.

Criteria

All of the above settings (CSS file, Keyboard shortcuts, and Mobile device display settings view) can be customized in order to render a different mobile experience to different devices and/or users. The system uses the criteria column to determine exactly which settings to load. The criteria column allows the following attributes of the incoming request to be used to qualify the different settings rows:

• Requestor IP address
• Requestor Host name
• Request User Agent string

Each of these values can be examined using a regular expression – any successful match will cause the specific display settings row to be loaded for that particular user session. The criteria string must match a specific format, and must include all three of the criteria options, even if you are only examining one of these values (wildcards must be specified for the others). The format of the criteria string must be:

Request.UserHostAddress=<user host address>|HostName=<user host name>|Request.UserAgent=<user agent>

Here is an example of the criteria used to differentiate between two browsers (Opera and Internet Explorer) based on the UserAgent field. Note the wildcard settings for the other two criteria options.

The above settings will enable us to display a different css file to different browsers – perhaps we are operating with two different classes of machines in the warehouse each with a different browser and different capabilities. We want to be able to target a different UI experience to each to ensure our users can be productive with their specific devices.

Mobile Device Portal Tools

There are two tools included with the mobile device portal that aim to make the processes describe above easier to configure. These tools can be found in the initial screen for the portal (i.e. go to the root URL of the portal).

The "View codes for keyboard shortcuts" will take you to a simple page that will display the JavaScript keycode for the hardware key pressed. This would allow you to test the specific hardware buttons for your devices in order to configure the keyboard shortcuts described above.

The "View server configuration for display settings" will show you the current display settings view selected, as well as the IP address, Host name of the requestor, and the full User agent string. As described above, these three fields are what is available to be queried against in the criteria string – so this page can be used to see exactly what the different values might be for the different devices in use in your warehouse.

Further Information    

For more information about the ways to customize the mobile device interface, please see the following TechNet article: https://technet.microsoft.com/en-us/library/dn553175.aspx.

Hopefully this was a useful overview of some of the configuration options available out of the box with the Warehouse Mobile Device Portal. In our next post we will cover customizing the portal in a deeper way, showing how the X++ code builds the portal workflows and how partner code can be injected to build new workflows.

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.

Introduction

Calculation of the on-hand are used from many forms but also during many business processes, the latter being less obvious to end-users. Therefore, it is always of interest to us to improve the performance of these operations since the overall impact on many processes can be quite significant.

The nature of the queries used to calculate the on-hand involves joins and aggregation and the performance is affected by the number of records in the tables involved. One way to improve the performance of such operations is to reduce the number of records that SQL server has to consider.

In this posting we will cover the Warehouse management on-hand entries cleanup job which deletes records in the InventSum and WHSInventReserve tables. These tables are used to store on-hand information for items enabled for warehouse management processing (WHS items). Cleaning up these records can lead to significant improvements of the on-hand calculations.

The cleanup job is available for the new Dynamics AX and also for the in-market version of AX 2012 R3 with KB article 3063513 – Performance improvement of On-hand queries by running new clean up job for on-hand entries for WHS enabled items.

Running the clean up

The cleanup job is available under Inventory Management>Periodic tasks>Clean up>Warehouse management on-hand entries cleanup.

The cleanup job can be ran during normal business hours but it is recommended to run it outside of working hours to avoid collisions where a user is updating a record that is also being cleaned up. By setting the Delete if not updated for this many days parameter in the dialog to an appropriate value, the risk of deleting used on-hand entries can be reduced.

If the job ends up trying to delete a record for an item while it is used by another user, a deadlock error will be experienced by either the cleanup job or the user impacting the on-hand of the item.

The job is running with a commit size of 100 meaning it will try to commit for every 100 deletes. However, since some deletes are set-based, there might be scenarios where more than 100 records can be deleted in the same transaction, hence there is no guarantee that lock escalations will not occur.

What is the clean up job actually doing ?

That is a fair question that we were asked by our colleges in the field so we wanted to share the answer with you.

The overall idea is that the cleanup job is deleting records in the WHSInventReserve and InventSum tables where all the field values are 0, since these should not contribute to the on-hand. The job only deletes records below the Location level.

If negative physical inventory is allowed then we might not be able to delete all entries with all zeros, since we need to account for a special scenario where a license plate has multiple serial numbers and one serial number has gone negative.

For this special case we will do a breadth-first delete, trying to delete from lower levels first.

If we don’t allow negative physical inventory we will delete upwards the hierarchy. This approach means that for a scenario were we had serial number 1 and 2 on the same license plate and the job is stopped, we might still have a record in WHSInventReserve on the lowest level, e.g. for serial number 2 but not one on the level above that. This is ok, since no record, is semantically the same as “nothing available or reserved”.

If we should get on-hand again after records have been deleted, the records will just be re-created as part of the normal business logic.

Possible user impact

A possible user impact is that if we have deleted all records for e.g. the license plate level, then the functionality where we can see that we at some point had on-hand at a license plate does not work as expected, simply because we have no on-hand entries to represent that.

This is the functionality where Quantity <> 0 is checked in the Dimension Display settings when viewing on-hand.

We decided that this was an acceptable loss of functionality compared to the performance improvement that customers should experience from cleaning up the records.

In this blog post you will be able to read about how to use mobile device menus to record physical movements of inventory on-hand, both within a warehouse as well as between warehouses.

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

Mobile devices menu items

Conceptually three different mobile device menu item processes exist:

– Movement

– Movement by template

– Warehouse transfer

Below you can read about the difference between the three mobile device menu items.

Movement

When using the work creation process Movement (Use existing work = No), the warehouse worker will need to define what is going to be moved and from where, as well as specify where to put the inventory on-hand.

This process is designed for a manual movement of inventory on-hand between locations and/or license plates within a warehouse, and the movements must be processed immediately by the same warehouse worker.

Because the inventory on-hand gets updated via work, it will be possible to transfer the inventory on-hand between locations, even though the on-hand might be reserved on a higher level (e.g. by a sales order line on the warehouse level, or reserved inventory because of a blocked inventory status).

In this process the inventory status value can also be updated during the physical movement of the inventory. If movement functionality is used to update the inventory status within the same location the setup must allow for mixed inventory statuses as part of the Location profiles settings. If this is not the case the Inventory status change work creation process must be used.

In the example below a new inventory status value named QMS is used.

Movement by template

When using the work creation process Movement by template (Use existing work = No), more options exists than for Movement. The biggest difference is that both work templates and location directives will be used to find a put location when using this mobile device menu item.

The parameter Create movement can be enabled if the mobile device menu item only should create the movement work, but not process the actual movement. Another mobile device menu item that has the Use existing work option selected can then be used to process the actual movement work at a later point in time.

Because the inventory on-hand gets updated via work, it will be possible to transfer the inventory on-hand between locations, even though the on-hand might be reserved on a higher level (e.g. by a sales order line on the warehouse level, or reserved inventory because of a blocked inventory status).

In this process the inventory status value can also be updated during the physical movement of the inventory.

Please be aware, that with the current functionality the inventory status value will be updated at the point in time of the creation of the planned inventory movement work.

In order for the system to be able to create work, a work template must be defined for the work order type Inventory movement.

And before the system can find a valid put location during the work creation process, Location directives must also be defined for the work order type Inventory movement.

Warehouse transfer

The mobile device menu item for Warehouse transfer is designed for a manual movement of inventory on-hand between locations and/or license plates between two warehouses. As for the manual Movement option, this operation must be processed immediately by the same warehouse worker and the worker will need to define what is going to be moved and from where, as well as specify where to put the inventory on-hand.

In order to be able to process this kind of transfer, the warehouse user must have access to both the from-warehouse and the to-warehouse.

Because the inventory on-hand does not get updated via work, but via the inventory transfer journal, it will not be possible to transfer on-hand which is reserved on a higher level (e.g. by a sales order line on the site level, or reserved inventory because of a blocked inventory status). The transfer journal issue transactions will be reserved on all inventory dimension levels.

When using the Warehouse transfer process, it will not be possible to change the inventory status value either – as it can be done when using the Movement and Movement by template functionality.

 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.

Introduction

In our scenario, a pallet of mixed items arrives at warehouse A. The receiving clerk is asked to identify and register the items on the pallet, before the pallet is moved from receiving location to next location.
The vendor didn’t issue an inbound ASN, but the vendor attached a pallet manifest to the pallet. The pallet could consist of items from different purchase orders.

This scenario with receiving and registering the full pallet has not been supported using the mobile device so far.

With KB 3152837, the ability to receive multiple times against a license plate is now supported for purchase orders.

Setup

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

Two new work creation methods have been introduced:

• Mixed license plate receiving
• Mixed license plate receiving and put-away

When either of these work creation methods is selected, a new field, Source document line identification method, becomes available.

The Source document line identification method determines the flow that will be presented to the user on the mobile device until a source document line is uniquely identified.

The three methods supported correspond to the flow that will be presented to the user on the mobile device for the Work creation methods Purchase order item receiving, Purchase order line receiving and Load item receiving.

The difference being that the user can continue to register on 1 license plate until all items on the license plate are received.

Auto-generation of license plate is NOT supported for this work creation method.

License plate grouping is NOT supported for this work creation method.

Receive multiple times on 1 license plate on mobile device

Two purchase orders exist for one or more items.

The supplier decides to ship all 4 purchase order lines in 1 shipment on 1 pallet. Now the receiving clerk needs to register this on 1 pallet.

Mobile device flow

Open mobile device menu item. In this example the source document line identification method is Purchase order item receiving.
Enter license plate. Click OK.
Enter Purchase order number. Click OK.
Enter item number. Click OK. Note: Now the purchase order line number is uniquely identified.
Enter quantity. Click OK.
Click OK. Note: This new work creation method expects the user to continue to receive items for the same license plate and purchase order number. The flow will continue like this until the user clicks the button LP Complete. This is the signal to create the work.
Leave the mobile device menu as is and open the rich client. Go to Warehouse management > Inquiries > Mixed license plate receiving. Note: This is a new form. It captures detailed information about all the license plates, where receiving has started using one of the 2 new work creation methods. For license plate BLOGPOST1 we can see, that user 51 is currently working with this license plate. Therefore, we cannot change anything for license plate BLOGPOST1 as the license plate is locked by user 51. Close the form.
Find the purchase order line, just registered. Look at the inventory transaction behind. Note: The Receipt status of the inventory transaction is still ordered.The state of the inventory transaction will be lifted when the work is created.
Pick up on the mobile device, where you left before.
Enter item number. Click OK. Note: Now the purchase order line number is uniquely identified.
Enter quantity. Click OK.
Click OK.
Now we want to receive items referencing a purchase order line on another purchase order. Click Change PONum. Note: Based on the feed-back received it is a common user mistake to clear the value of a field by pure mistake. Therefore the purchase order field is not editable unless the user specifically declares that the purchase order number should be changed.
Enter Purchase order number. Click OK.
Enter item number. Click OK. Note: Now the purchase order line number is uniquely identified.
Enter quantity. Click OK.
Click OK.
Enter item number. Click OK. Note: Now the purchase order line number is uniquely identified.
Enter quantity. Click OK.
Click OK.
The receiving of the 2 purchase order lines is now completed. Click LP Complete. Note: A list is presented to the user with the details of the items received for this license plate.If the user sees a mistake, this mistake can be corrected by clicking the button Modify.
The user does not wish to modify the receiving. Click OK. Note: If Display disposition code is set on the mobile device, the user will be asked to provide a Disposition code.
Click OK. The flow is now completed.
Go to Warehouse management > Inquiries > Mixed license plate receiving. Note: License plate BLOGPOST1 is completed. Therefore, we do not see this when the form is open.
The receiving supervisor wants to see the history captured for the receiving of this license plate. Set Show completed license plates to Yes. Note: Completed license plates can be deleted, when the information is no longer relevant. Close the form.
Find the purchase order line just registered. Look at the inventory transaction behind.Note: The status of the inventory transaction was lifted to registered, when the work was created. Close the form.
Open work from the purchase order line. Note: 1 work order with target license plate BLOGPOT1 is created for all lines. Close the form.

Variations and exceptions

This new feature supports a number of variations over the main flow and support handling of exceptions. The following variations and exceptions will be explained in this section:

• User mistakenly cancels out of flow and want to start the flow again.
• A second user tries to receive items on a license plate the first user is working on.
• A second user tries to receive items for a purchase order line, where there is nothing left to receive.
• User receives items on a faulty license plate ID.
• User mistakenly cancels out of flow and forget to complete license plate. Supervisor wants to complete the license plate from the rich client.

User mistakenly cancels out of flow and want to start the flow again.

If the user mistakenly cancels out of the flow, before completing the receiving of all the items on the license plate. Any user with access to a mobile device menu item with this work creation method can start the flow again.

Example:

One purchase order exists

Mobile device flow

Open mobile device menu item. In this example the source document line identification method is Purchase order item receiving.
Enter license plate. Click OK.
Enter Purchase order number. Click OK.
Enter item number. Click OK. Note: Now the purchase order line number is uniquely identified.
Enter quantity. Click OK
Click OK
Click Cancel.
Open mobile device menu item again.
Enter license plate. Click OK. Note: The flow is restarted.

A second user tries to receive items on a license plate the first user is working on.

Example:

One purchase order exists

Mobile device flow

User 51 has logged into the mobile device.Open mobile device menu item. In this example the source document line identification method is Purchase order item receiving.
Enter license plate. Click OK.
Enter Purchase order number. Click OK.
Enter item number. Click OK. Note: Now the purchase order line number is uniquely identified.
Enter quantity. Click OK.
Click OK
User 52 logon to the mobile device and tries to start the receiving of items on license plate Blogpost1.
Scan license plate. Click OK. Note: User 52 will receive an error message, because license plate BLOGPOST1 is locked by user 51.

 A second user tries to receive items for a purchase order line, where there is nothing left to receive.

User 1 has started the receiving of a purchase order line and there is no quantity left to receive.

User 2 tries to start the receiving of the exact same purchase order line using a different license plate.

Example:

One purchase order exists

Mobile device flow

User 51 has logged into the mobile device.Open mobile device menu item. In this example the source document line identification method is Purchase order item receiving.
Enter license plate. Click OK
Enter Purchase order number. Click OK
Enter item number. Click OK. Note: Now the purchase order line number is uniquely identified.
Enter quantity. Click OK
Click OK
User 52 logon to the mobile device and tries to start the receiving of items on license plate Blogpost2.
Enter license plate. Click OK. Note: This is accepted, because license plate Blogpost2 does not contain on-hand inventory on any locations and no other user has started the receiving of this license plate.
Enter Purchase order number. Click OK.
Enter item number. Click OK. Note: The user receives a message that there is no quantity left to receive.

User receives items on a faulty license plate ID.

If a user for example by mistake scans the item number in the license plate field and discovers this after the first item is received, the supervisor can delete the entry and the user can start again.

Example:

One purchase order exists

Mobile device flow

User 51 has logged into the mobile device.Open mobile device menu item. In this example the source document line identification method is Purchase order item receiving.
Enter license plate. Click OK
Enter Purchase order number. Click OK
Enter item number Click OK. Note: Now the purchase order line number is uniquely identified.
Enter quantity. Click OK
Click OK. Now the user realizes that the license plate should not be blog post number 1.
Super user will open form Mixed license plate receiving. Select the correct record. Click Delete.
Confirm deletion by clicking Yes.
The entry is deleted and the user can start again.

User mistakenly cancels out of the flow and forgets to complete the license plate. Supervisor wants to complete the license plate from the rich client.

The user receives all items for a license plate, but forgets to complete the license plate before going home. Supervisor wants to complete the license plate from the rich client.

Example:

1 purchase orders exist for 2 items.

Mobile device flow

Open mobile device menu item. In this example the source document line identification method is Purchase order item receiving.
Enter license plate. Click OK.
Enter Purchase order number. Click OK.
Enter item number. Click OK. Note: Now the purchase order line number is uniquely identified.
Enter quantity. Click OK.
Click OK
Enter item number. Click OK.
Enter quantity. Click OK.
Click OK
Click Cancel

Supervisor opens the form Mixed license plate receiving.

Position cursor on the correct license plate.

Click the button Complete license plate.

The policies set for the mobile device menu item used by the last user will be applied. In this example, the mobile device menu item used for the last receiving has Display disposition code = Yes.

Supervisor can apply a disposition code or ignore this.

Click OK

License plate receiving is now completed and work is created.

User ID stamped on the header in this case is the user ID from the warehouse parameters Default work user ID.

Circulating license plates

Circulating license plates are supported using these 2 new work creation methods.

Capturing of tracking dimensions

Tracking dimensions’ batch and serial numbers are captured for each individual receiving on the license plate. The pattern applied is the same pattern applied for the work creation method Purchase order item receiving.

Vendor catalogs import

In Microsoft Dynamics AX, purchasing professionals can create and maintain catalogs for company employees to use when they order items and services for internal use. When you create a procurement catalog you can add the items and services that you make available to employees, either by importing the vendor catalog data or by adding the vendor catalog data to the product master manually. If you use the catalog import process the vendor can send you the product catalog data and you can upload it by using the Microsoft Dynamics AX client.

The product data that the vendor submits to you, in the form of a catalog maintenance request (CMR) file, must be in XML file format. The CMR file should contain all of the details for the products that the vendor supplies to your company.

Importing vendor catalog data

To import vendor catalog data, you must complete the following tasks:

1. Set up a project in data management workspace. Here you have to define your data mapping rules.
2. Set up a procurement category hierarchy, and assign your vendors to procurement categories. If you use commodity codes, add the commodity codes to the procurement categories.
3. Configure the vendor for catalog import.
4. Configure workflow for catalog import.
5. Create a CMR file template and share this with your vendor.
6. Create a vendor catalog. The catalog maintenance request (CMR) files that you receive from your vendor are grouped in this catalog.
7. Upload the CMR file.
8. Review, approve, or reject the products in the vendor catalog. Details that can be reviewed include the product name, description, pricing, or order quantity requirements. Approved products are added to the product master and are released to the selected legal entities. Only approved products can be added to the procurement catalog. The products are now automatically mapped to the procurement categories in AX.

Overview

For the current version of Microsoft Dynamics AX, we are using the Data Import/Export Framework and a predefined composite entity (you can read more on data entities here).

The product data that the vendor submits to you, should still be in the form of a catalog maintenance request (CMR) file, must be in XML file format.

Set up the system to import vendor catalog data

You will need to set up the system to support the vendor catalog import scenario, by creating an import job for vendor catalogs.

1. On the main dashboard, click the Data management tile to open the data management workspace.
2. Click the Import tile to create a new data project.
   
3. Enter a valid job name, source data format, and entity name.
   Do note for data source we support only XML-element or XML-attribute. Entity name should be “Vendor catalogs”.
   
   Upload an XML mapping data file for vendor catalogs data entity. The XML mapping data file defines which fields you expect to import from your vendor CMR files. These fields will appear as your source and you will need to map these fields to Dynamics AX internal schema reflected by the staging schema.
   

In this way you have the possibility to map the XML schema template that you provide to your vendors, to the internal schema defined in Dynamics AX. There can be only one mapping defined at a time.

The internal schema we currently support you can also see it below and it reflects a catalog maintenance request entity which includes product details entities with the associated product pricing, order quantity requirements and detailed product descriptions entities.

This is how the initial XML file should like:

<?xml version="1.0" encoding="utf-8"?><Document>
			<CatVendorCatalogMaintenanceRequestEntity>
				<UploadDateTime></UploadDateTime>
				<CatVendorProductCandidateEntity>
					<ProductCategoryHierarchyName></ProductCategoryHierarchyName>
					<ProductCategoryName></ProductCategoryName>
					<ActionType></ActionType>
					<ProductNumber></ProductNumber>
					<ProductSubtype></ProductSubtype>
					<SearchName></SearchName>
					<BarCode></BarCode>
					<ProductColorId></ProductColorId>
					<ProductConfigurationId></ProductConfigurationId>
					<ProductSizeId></ProductSizeId>
					<ProductStyleId></ProductStyleId>
					<CatVendorProductCandidatePurchasePriceEntity>
						<CurrencyCode></CurrencyCode>
						<UnitSymbol></UnitSymbol>
						<Price></Price>
					</CatVendorProductCandidatePurchasePriceEntity>
					<CatVendorProductCandidateSalesPriceEntity>
						<CurrencyCode></CurrencyCode>
						<UnitSymbol></UnitSymbol>
						<Price></Price>
						<SuggestedPrice></SuggestedPrice>
					</CatVendorProductCandidateSalesPriceEntity>
					<CatVendorProductCandidateDefaultOrderSettingsEntity>
						<UnitSymbol></UnitSymbol>
						<LeadTime></LeadTime>
						<OrderQuantityMultiples></OrderQuantityMultiples>
						<MaximumOrderQuantity></MaximumOrderQuantity>
						<MinimumOrderQuantity></MinimumOrderQuantity>
						<StandardOrderQuantity></StandardOrderQuantity>
					</CatVendorProductCandidateDefaultOrderSettingsEntity>
					<CatVendorProductCandidateTranslationEntity>
						<ProductName></ProductName>
						<Description></Description>
						<LanguageId></LanguageId></CatVendorProductCandidateTranslationEntity>
					</CatVendorProductCandidateEntity>
</CatVendorCatalogMaintenanceRequestEntity></Document>

In the mapping file you have to include UploadDateTime field at the level of CatVendorCatalogMaintenanceRequestEntity (see example above) . This field is used internally to track the upload time for the catalog maintenance request and it should not be included in the actual CMR files.

You can also include the field ActionType at the level of CatVendorProductCandidateEntity. This field can be used to explicitly specify the type of action you want to take for the product: add, update or delete. The values supported for these fields in the CRM file are: Add, Update and Delete.

If you will decide to use your own schema, you should get warnings when you upload the mapping file:

Go to the View map and here you will see the vendor catalog composite entity and also the individual entities defined in the composite entity: CatVendorCatalogMaintenanceRequestEntity, CatVendorProductCandidateEntity, CatVendorProductCandidatePurchasePriceEntity, CatVendorProductCandidateSalesPriceEntity, CatVendorProductCandidateDefaultOrderSettingsEntity, CatVendorProductCandidateTranslationEntity

Make sure that each entity is added, and that all errors are fixed.

You can click each entity data card to set up, review, or modify field maps, and to set up XSLT-based transforms that must be applied to inbound data.
o Source – These are inbound CMR files Typically data format includes – CSV, xml, tab delimited ; This will be the xml schema you will use for you CMR files.
o Staging – These are auto generated tables which map very closely with data entity. When “data management enabled” is true staging tables are generated to provide intermediary storage. This enables the framework to do high volume file parsing, transformation and some validations.

Note: important, mandatory fields marked with red star should be always mapped to a field.

To map your own field to an existing field in the fixed schema, you can do this by drag a drop from source field to destination field and pressing save.

For example in here, we use VendorProductCode instead of ProductNumber.

You can proceed when the import job mapping icon shows no error.

Note: The mapped fields are case sensitive, which means the CMR files should use exact field names.

Also if fields were defined in the mapping even they are not mandatory they are expected to be present in the input. That means if for example BarCode was presented in the initial mapping file, we expect to see it in xml file even though it doesn’t contain any value.

• Click Save. At this point your system is configured to support importing of vendor catalog files.Currently the product related data we support is: product name, description, translations. pricing or order quantity requirements.

NOTE: You should not import data directly from data management workspace. The vendor catalog maintenance request files should be imported in the context of a vendor catalog which also enforces a process of review and approval.

Set up a procurement category hierarchy

You won’t be able to import products from categories where the vendor is not approved for procurement. To approve the vendor:

1. Go to Procurement and sourcing > Procurement categories.
2. Select the category. Add the vendor to the list of approved vendors in the Vendors fast tab.

Configure the vendor for catalog import

In order to be able to import catalogs for a particular vendor it has to be enabled for catalog import. There are two ways to achieve that

• For a specific vendor go to Procurement > Set up > Configure vendor for catalog import
• If you don’t do this you will be prompted if you want to enable the vendor for catalog import when creating a new catalog for the vendor

Set up workflow

After a catalog maintenance request (CMR) file has been successfully uploaded, the purchasing professional can review the product details in the file. The vendor indicates whether the product is new, modified, or must be deleted. Information about the product pricing, product descriptions, product attributes, and order quantity requirements are also included in the CMR file. As an approver, you can indicate whether products are made available to selected legal entities and approve or reject the products in the file. Approved products are added to the product master and are released to the selected legal entities.

To support the approval process we are leveraging another powerful feature of AX: workflow processing.

You are allowed to set up rules for automated approval of vendor catalogs and specify one or more reviewers if manual approval is required. To enable the vendor catalog import functionality it is required to set up two types of workflows: Catalog import product approval (line-level), Catalog import approval (catalog-level). We should always define both workflows since the Catalog import approval will always require Catalog import product approval to approve products, either manually or automatically.

Catalog import product approval

This type of workflow processes all the products that are included in the CMR file. Completion of all of the individual line-level workflow completes the overall catalog import workflow. In order to create a product approval workflow:

1. Click Procurement and sourcing > Setup > Procurement and sourcing workflows.
2. On the Action Pane, click New.
3. Select Catalog import product approval and then click Create workflow.

General setup

The common catalog import product approval workflow should look like this:

Set up approvers

1. Double click the Catalog import product approval element.
2. Click the Step 1 element.
3. Click Assignment in the action pane.
4. The simplest assignment would be User->Admin.

Set up automatic actions

Automatic actions allow the workflow framework to automatically approve or reject the products in the imported vendor catalog which meet certain conditions. In order to set up an automatic action you need to:

1. Select the Catalog import product approval element.
2. Click Automatic actions in the action pane.
3. Click the Enable automatic actions check box
4. Setup the conditions for auto approval/rejectionThere is one type of condition which I would like to focus on. You can specify Product candidate.Price delta as a parameter of the automatic action. The price delta is calculated as a ratio: (new price – old price) / old price. So if you want to make sure that the price delta is within 20% you need to set the condition to Product candidate.Price delta <= 0.2
5. Select the type of automatic action (approve/reject)

You can also setup auto approval for condition that IsAutomatedApproval enabled,.

IsAutomatedApproval setting is controled directly on the vendor catalog page. On the Action Pane, on the Catalogs tab, in the Maintain group, click Enable automated approval. This sets the Automated approval field to Enabled.

Catalog import approval

This type of workflow is used for setting up the rules for approving the whole catalog. When you configure this workflow, you can reference the Catalog import product approval workflow that you configured earlier. The common setup would be to automatically approve the whole catalog import after all the products have been approved:

In the properties of the Vendor catalog lines (products) element you need to reference the catalog import product approval that you created earlier.

Import a catalog from a vendor

First you have to set up a catalog for your vendor. The catalog maintenance request (CMR) files that you receive from your vendor are grouped in this catalog. After you set up the catalog, you can upload CMR files for the vendor. You can also view the details and the event log for new or existing CMR files that have been added to the vendor catalog

Use this procedure to create a new vendor catalog. This is the catalog to which you upload a catalog maintenance request (CMR) file for a vendor. If you delete the vendor catalog, you can no longer import CMR files to it. If you still want to import catalog data from the vendor, you must create a new catalog for the vendor

1. Go to Procurement and sourcing >  Catalogs > Vendor catalogs and create new catalog.
2. In the New catalog form, in the Vendor field, select the vendor that you are creating the catalog for.
3. Enter a name and description for the catalog, and then click Save.

Upload a catalog maintenance request (CRM) file. Go to Catalog file history tab, click Upload file.

1. In the Upload file dialog box, browse to the location of the CMR file that you created. The maximum file size allowed to upload is 10 MB per file.
2. Enter an effective date and an expiration date. These dates define the date range in which the pricing for the products in the CMR file is valid. When trade agreement are created it will include these dates.
3. Select one of the following update types for the CMR file:
   1. Add updates to the existing vendor catalog – Add product updates to an existing catalog.
   2. Replace the existing vendor catalog with a new catalog – Add a new catalog, or replace an existing catalog with a new catalog.
4. If you are creating a new catalog to replace an existing catalog, all items and services that are in that catalog are overwritten by the matching items and services in the new CMR file. Any existing items and services that are not in the new CMR file are deleted. Any items and services that are included in the new CMR file, but that are not included in the existing catalog, are treated as new products
5. Select category hiererachy type you want to associate the product data. You can also select either procurement category hierarchy or commodity code hierarchy.
6. Click OK to start the upload process for the CMR file.

When you upload the CMR file, the file is validated against the category hierarchy type selected and the categories the vendor is allowed for procurement. If the validation fails and some of the data is invalid the catalog upload process will fail. You can view the details for the CMR file upload status in the event log. After the CMR file is uploaded successfully, you can review the details of the CMR file in the vendor catalog.

• Start processing – The CMR file has been submitted for import.
• Start catalog upload – The CMR file has been submitted and is in process.
• Catalog upload failed – An error occurred after the file was submitted for processing, and the CMR file was not imported.
• Catalog upload complete – The CMR file was successfully uploaded.
• Invalid CMR – The CMR file does not comply with the current schema for catalog import. If the CMR file was created by using an outdated schema, the CMR file must be recreated by using the current schema. You can also use advanced troubleshooting to narrow done the cause of the failure.
• Pending approval – The CMR file is in review and waiting for approval by the purchasing agent.
• Product rejections – Products in the CMR file were rejected for import into the procurement catalog. Product rejections are indicated by a warning during the import process, and the file continues to be processed for products that are approved.
• Approval complete – The purchasing professional has completed the review of the products and images that are contained in the CMR file.
• Finish processing – Approved products have been added to the product master in Microsoft Dynamics AX and trade agreement journals have been created. The data in the CMR file has been passed to the archive folder for the vendor.

After the products in the CMR file are reviewed and approved, you can release the approved products to the legal entities in which the vendor is authorized to supply products, and appropriate trade agreements can be created.

Validate and approve imported catalogs

1. Click Procurement and sourcing > Common > Catalogs > Vendor catalogs. On the Vendor catalogs list page, double-click a vendor catalog.
2. In the Update catalog form, on the Catalog file history fast tab, select a CMR file, and then click Details.
3. In the Catalog approval page form, review the product details for the products that are included in the CMR file. You can use the Item status field to view all items or only items that have a selected status. Select one of the following options:
   1. All items – View all products that are included in the CMR file. This is the default setting.
   2. Add – View only new products. After a new product is approved, it is added to the product master. When the product is released to the legal entity, the corresponding trade agreement is created and the product appears on the Released products list page.
   3. Update – View only existing products that are being modified. After a product is approved, the modifications are applied to the existing product in the product master. New trade agreements are created only if there are price changes for the product.
   4. Delete – View only products that are no longer offered by the vendor and should be deleted. After the product request is approved, the product is no longer available for purchase.
4. To filter product changes by legal entity, select a legal entity in the Buying legal entity field. You can view the price, name and description and purchase quantity changes by legal entity.
   

   Note

   A legal entity appears in the list only if vendor products that have been imported are approved and released to the legal entity. If no products have been released to a legal entity for the vendor, the list is empty.

5. In the lower pane, on the Price tab, review the pricing for a selected product. The current price and new price are displayed in the currency and unit of measure in which the product is offered.
6. On the Name and description tab, review the name and description of a selected product in specified languages.
7. On the Purchase quantity tab, review changes to the purchase order quantity requirements and purchase lead time for the selected product.
8. In the upper pane, select the products that you want to approve, and in the workflow message bar, click Actions > Approve. Approved products are added to the product master.
9. In the upper pane, select the products that you want to reject, and in the workflow message bar, click Actions > Reject. Products that are rejected are not added to the product master.
10. Click Release products to legal entity, and then in the Release products to legal entity form, select the legal entities in which the vendor’s approved products will be available. Corresponding trade agreements will be created for the products in these legal entities. Products must be added to the product master and be available in the legal entities before they can appear in the procurement catalog.
    

    Note

    If you do not release the approved products to the legal entities by using the Catalog approval page form, you can release approved products to legal entities by using either the Vendor catalogs list page or the Update catalog form.

Advanced troubleshooting

We have a first level of logs to see if anything failed during the import of a file.

However we don’t expose yet all the detailed information here in regards with data management framework processing.

For this now we have an advanced ways of seeing more details when import fails, by looking at execution details of the import job by going to data management workspace:

For the failed job, I can drill through and see more details

By going further into view staging data and viewing data you can identity there is a problem in this case in product data:

• Agile Software Development Engineer
• Software Development Engineer
• Senior Software Development Engineer
• Agile Senior Software Development Engineer

When using Warehouse management II, you can use different types of pallets to control storage policies. Similarly, when using the Warehouse management module in Microsoft Dynamics AX 2012 R3, you can now associate a container type with a license plate. This is available with the following KB articles:

• KB 3162642 – Need pallet type and groups support for inbound flow in WHS
• KB 3164382 – Locate put-away locations based on license plates (for purchase order mixed LP and LP receiving processes)

License plates

Warehouse management > Setup > Warehouse setup > License plates

You can use the License plate form to assign a container type to a license plate entity.

Container types

TechNet: https://technet.microsoft.com/en-us/library/dn553190.aspx

Warehouse management > Setup > Containers > Container types

The container types are used to define the physical characteristics of a tangible carrying unit, such as a cage, box, pallet, or a shipping container.

The following new fields have been introduced on the container type entity:

• Container length – The length of the container
• Container width – The width of the container
• Container height – The height of the container
• Container volume – The volume of the container
• Flexible volume dimensions – When selected, the volume depends on both the container volume and the inventory put on the container (open pallet). When cleared, the volume is considered fixed and doesn’t depend on what inventory is put into the container (fixed cage). Existing containerization processes will not be affected by this new setting.
• Unit – The unit of the container type is used as part of the stocking limit calculations where unit conversions between container types can be used as a ratio to calculate storage capacity within locations.

Units and Unit conversions

Organization administration > Setup > Units > Units

Organization administration > Setup > Units > Unit conversions

Unit conversions between container types describe a common unit when using stocking limits. For example, a location with the capacity to carry two full-pallets might be expressed as having capacity for four half-pallets.

To further illustrate this example, two Units must be created and assigned with two Container types.

Then Unit conversions between the units must be defined:

1-PL = 2 * ½-PL

Location stocking limits

Warehouse management > Setup > Warehouse setup > Location stocking limits

You can use information about the container types on the Location stocking limits form to find available capacity based on the available number of license plates (container types). The Container types section (tab) is evaluated first as part of the stocking limits functionality. If no constraints are found, the settings in the Product section are used. If you don’t want to use this functionality, you can create a record with the Allow unlimited quantity field selected.

The Unit cannot be selected, but is entered by default based on the unit assigned on the Container type field.

With using internal unit conversions between different container types, the storage capacity depends on the container type. In this example all locations that are associated with the Location profile ID being set to PDP have space for two full-size pallets. The way that the Unit conversions are defined means that the following combinations can be used:

The definition of the container type location stocking limit requires the Location profile ID that used has the Allowed container type group field defined. The associated container types must have units and unit conversions defined, as well.

Allowed container type groups

Warehouse management > Setup > Containers > Allowed container type groups

In case locations should be restricted from holding all container types, the new Allowed container type groups can be used. The records that are defined in this form must be associated with a location profile in order to restrict locations to holding only specific container types. When Allow unspecified container types is selected, license plates that are not associated with any container type are allowed to be put on the locations.

Location profiles

Warehouse management > Setup > Warehouse setup > Location profiles

To store only the license plates for the container types that are allowed by your business, assign the allowed container type group to a location profile. To use this functionality, you must select the Use license plate tracking field.

Note that when using the volumetric calculation functionality, the physical dimensions will be calculated based on the defined setup as part of the container types. Making a physical update resulting in emptying a license plate (no inventory on-hand associated), will remove the volume of the license plate (container) volume on the location load.

Container type defaulting

The logic of getting a container type assigned to a license plate can be controlled by defaulting. When enabled, the user can overwrite the default value during the mobile device processing.

Conceptually the defaulting will start from:

Existing License plate container type -> Mobile device menu items -> Unit sequence groups -> Warehouse -> Warehouse management parameters -> [Blank]

Warehouse management parameters

Warehouse management > Setup > Warehouse management parameters

You can specify default entries for container types that are assigned to license plates using the fields in the License plates section.

Warehouses

Warehouse management > Setup > Warehouse setup > Warehouses

You can specify default entries for container types in the Warehouse management section.

Unit sequence groups

Warehouse management > Setup > Warehouse setup > Unit sequence groups

The Default container type column is added as part of the unit sequence so you can specify the container type as a default entry, depending on the unit used as part of the receiving process.

Mobile device menu items

Warehouse management > Setup > Mobile device > Mobile device menu items

The Default data setup form is used to make the Default container type file active on mobile devices, as well as specifying the default container type.

Mobile device forms

If you select the Display container type field in the Mobile device menu items form, the Container type lookup is shown either when the license plate is generated automatically or the mobile device process displays an acceptance form after the license plate value is defined.

With Generate license plates selected:

With Generate license plates cleared:

Location directives (Purchase orders)

To support a put-away business process where all the content on a license plate gets put on one location, for ASN – License plate receiving and Mixed license plate receiving, we recommend using the Locate by field on the Location directives for the work order type purchase order.

When set the Locate by field to ASN or Mixed license plate, the query, as well as the line and location directive actions, will behave differently. When using the grouping concepts for ASN and Mixed license plate, the lines restrictions will not be used.

Outbound processes

Even though this enhancement mainly addresses the inbound warehouse management processes, some outbound processes can benefit, as well. One benefit is the capability to guide the work allocation for specific container types via the query on the Location directives.

On-hand inventory

The same filtering capabilities can be used when viewing the inventory on-hand. It will be possible to include the container types as part of the query due to the fact that the container types get associated with the license plates tracked during the receiving processes.

Microsoft Dynamics AX 2012 R3 Cumulative Update 11 is now available for download on Lifecycle Services, CustomerSource and PartnerSource. This release includes several improvements for warehouse and transportation management. For detailed information on the release of Microsoft Dynamics AX 2012 R3 CU11, please refer to the Dynamics AX In-Market Engineering blog.

In this post we’ll take you through some of the enhancements in SCM and specifically 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 SCM and for WMS and TMS the following enhancements are made available:

• Enable multi-threading on wave execution.
• Inserting records into InventTransOriginTransfer from the write TransferRefId method has been improved.
• Report actual consumption for production on a mobile device.
• Ability to round up work for raw material picking in the unit that the material is picked in.
• Ability to mark a production order as ended when you are reporting as finished on a mobile device.
• Ability to report items that have an active serial number as finished by using a mobile device.
• Receive a pallet that has mixed source document line, and register it by using one license plate (LP).
• Locate put-away locations, based on LPs for mixed LP and LP receiving processes.
• Associate LPs with a container type.
• New functionality has removed the need for the message that states that the load line is not valid when you try to release a load that is a partial quantity.
• All first expired, first out (FEFO)  batch reservation sales lines that are created have the same item.
• You can now change the unit of measure during sales order picking
• The Adjustment in and Adjustment out mobile device menu items now have the option to show or hide inventory status.
• You don’t need to enter the return merchandise authorization (RMA) for every line that is being returned when you process a return through a mobile device.
• The ability to allow negative physical and financial inventory for specific warehouses is now controlled by the LogisticsBasic configuration key.
• Combine sales orders and transfer orders on the same outbound load.
• Accrual posting of inbound freight charges at the time of product receipt
• The printed master bill of lading (BOL) gives summarized information for all attached underlying BOLs.
• You can go directly to the BOLs for a load from the Load planning workbench.
• Until now, it has been mandatory to use different items for the parent and child product. Otherwise, the user receives a warning message from the BOM check that circular reference is not allowed. If this warning is ignored, MRP might fail. This warning was caused by the fact that the level check and the BOM level calculation were done per item.
• Issues with multithreading, bill of materials (BOM) level calculation, and processing of items that have no demand cause high MRP run times.

The following shows an excerpt from the What’s new in Microsoft Dynamics AX 2012 document on a more detailed list of the enhancements for CU11 in SCM and for warehouse and transportation management.

This blog post applies to Microsoft Dynamics AX 2012 R3 CU11 and KB 3153040.

Wave processing is used to generate work for the warehouse. The processing can be time consuming and majority of the processing time is spent in the allocation step and in the work creation step.

It is now possible to run the wave allocation step in parallel, which can improve the performance of the wave processing, and allow for a larger throughput of waves in the same warehouse.

Previously it was only possible to allocate one wave at a warehouse at a time. This constraint was enforced by using a SQL application lock that basically locked on the warehouse ID. This constraint has now been removed. A new constraint has been introduced so the locking is done on the item and dimensions that are above location in the reservation hierarchy. Dimensions above the location always include product dimensions, so if an item is configured using Color, variants for Red, Blue, and Yellow could be processed in parallel.

This means that if the same item with the same dimensions above the location is being allocated by one wave, other waves will have to wait to acquire a lock on the same item and dimensions. If the lock cannot be acquired in a timely manner, an error will be thrown and the wave processing will fail.

In order to utilize parallel processing, the wave needs to run in batch.

Performance improvements – what can be expected

It is hard to predict how much the parallel processing can improve the performance.

The performance benefits fall in two categories:

1. Improved throughput: The throughput of waves should be improved even if parallel processing is not configured, especially for scenarios where there is no overlap of items within the waves.
2. Improvement of the allocation for a single wave: Testing on customer data on a 4 core environment using 8 tasks, resulted in almost a 50% improvement of the overall processing for larger waves with more than 700 different items and variants. The parallel processing is done per items and dimensions above the location, so the improvements depends on how many different items a wave contains, the infrastructure available, and the duration of the allocation vs the duration of the work creation.

Configuration

Warehouse management parameters

The following values on the Warehouse management parameters form are relevant. This form is found under Warehouse management > Setup > Warehouse management parameters.:

Wave process methods

The actual configuration of the parallel processing is done on the Wave process methods form found under Warehouse Management > Setup > Waves > Wave process methods.

A new button called Task configuration is enabled for the allocateWave method. This buttons opens the Wave post method task configuration form.

In this form you can configure how many batch tasks should be used for the allocation in a specific warehouse. If the number is set to 8, a maximum of 8 batch tasks will be used to process the allocation.

Note: The optimal number of batch tasks depends on the infrastructure available and what other batch jobs are being processed on the server. Tests done on a 4 core environment that was dedicated to wave processing showed that 8 tasks lead to good results.

Specific batch groups can be used for different warehouses in order to allow the allocation processing to scale out per warehouse.

If a configuration record does not exist for a warehouse, parallel processing will not be used.

Troubleshooting

Since the batch framework is used, errors that occur during wave processing will be captured as part of the batch jobs Infologs. The batch jobs related to a wave can be viewed using the Batch jobs button:

This is what a typical set of batch jobs would look like for a wave:

The first batch job is the one that was initially created when the wave processing began. If parallel execution is used, this job prepares data for the next job.

The second job is the one for the allocation. This job can have multiple tasks dependent on the number of batch tasks configured. The third job is for the rest of the wave processing and has information about the first step after the allocation. This is typically the createWork step or replenishment if that is enabled.

The wave processing is self-correcting so any error that’s detected during the processing should be handled gracefully and reported using the Infolog.

A typical error related to parallel processing could be that two waves try to allocate the same item at the same time and one does not complete so that the other wave is unable to acquire a lock within the specified time. If this situation occurs the batch jobs log will contain information stating that the lock for the item could not be acquired. If this occurs, the wave that failed needs to be processed again.

Since the processing is happening in parallel, data needs to be maintained in different tables to track the state of the processing. This means that the logs for the batch jobs might contain errors such as duplicate key errors. The screenshot below is an example of such errors where 8 tasks were created and all failed the allocation:

The errors from the batch tasks are also part of the batch jobs log. The most important information is typically at the bottom. In this example the log is telling us that the shipment was not fully allocated.

In rare cases, for example if the SQL connection is ended, it is possible for the wave processing to end up in an inconsistent state where the batch job appears to be running but the processing is stopped. The wave can’t handle errors like this, so an attempt to clean up failed waves is done when the next wave runs. Alternatively, you can use the Clean up wave data button to clean up the current wave if it is in an inconsistent state.

The pending allocation log

If the Pending allocation logging option is enabled data can be viewed in the Wave pending allocation log form by clicking the button. A log record is created every time allocation for an item and its dimensions begins and ends.

Logging should only be enabled if you need it, for example, during initial testing or for troubleshooting.

In this blog post we are going to go into details about how you can gain more control of your reservations by introducing a new reservation strategy.

If the reservation of warehouse management enabled items is not fresh in your memory, take a look at Controlling reservations for warehouse management enabled items (WHS) – Part 1.

The code snippets are written for Microsoft Dynamics AX 2012 R3 CU 11, but can be easily ported to the to the latest version of Dynamics 365 for Operations

The code in this blog is provided “as-is”. You bear the risk of using it.

The scenario

We are going to imagine that a company is selling an item in different qualities and is using the inventory status to reflect the quality.

Normally the company sells whatever qualities are available, but for a few special customers, the quality needs to be selected during order taking, which means the sales order taker needs to able to select the inventory status.

To have as much stock available for customers that request a specific quality the company wants to postpone the decision about which qualities are used for the orders were no special quality is requested.

The challenge is to postpone the reservation of specific qualities (inventory statuses) but still allow some orders to select specific qualities.

In order to create work all dimensions above the location must be specified on the load lines. Therefore the decision about what qualities to ship can only be postponed until the point in time where the load is released to the warehouse.

To achieve this, we are going to introduce a new reservation strategy. The purpose of this strategy is to ensure that we reserve all the dimensions above the Inventory status but not the inventory status itself.

The new reservation strategy

Our new strategy called AllAboveStatus will be added to the hierarchy by extending the WHSReservationHierarchyLevelStrategy class.

The instantiation of the class is done using the SysExtension framework (if you want to read more about SysExtension framework it is well covered here: The Microsoft Dynamics AX 2012 extension framework – Part 1.

All we need to do is to add a new value to the WHSReservationHierarchyLevelStrategyType enum and decorate our class with an attribute:

[WHSReserveHierarchyLvlStratAttribute(WHSReservationHierarchyLevelStrategyType::AllAboveStatus)]
class WhsReservationLevelStrategyAllAboveStatu extends WHSReservationHierarchyLevelStrategy

Important methods

There are a few methods we need to override. Here I am including the two complex ones.

public List getReservableHierarchyListTopDown()
{
    if (!reservationHierarchyListTopDown)
    {
        /* This should be on the cache but is kept here for illustration purposes */

        reservationHierarchyListTopDown = WHSReservationHierarchyListBuilder::construct().buildPartialHierarchyAbove(
                    inventTable.whsReservationHierarchy(),
                    WHSReservationHierarchySortOrder::TopDown,
                    fieldNum(InventDim, InventStatusId),
                    false);

    }

    return reservationHierarchyListTopDown;
}

The method must return a list that contains all the fields from the reservation hierarchy above the Inventory status.

public WHSReservationHierarchyLevel getReservationHierarchyLevel()
{
    return this.reservationHierarchyProvider().getDimLevel(inventTable, fieldNum(InventDim, InventStatusId)) - 1;
}

The method must return the level that we want to reserve against.

That takes care of introducing the new strategy.

Determining when to use the new strategy

Now we need a way to determine when the new strategy should be used.

We are going to keep it simple so this is done by adding a new No/Yes field to the SalesLine table. If the field is set, we will use the new strategy.

We just need to override the reservationHierarchyLevelStrategyList method on the InventMov_Sales class .

public List reservationHierarchyLevelStrategyList(InventDim _inventDimReservationCriteria)
{
    List ret;

    ret = super(_inventDimReservationCriteria);

    if (SalesOrderLine.WHSUseNonStatusSpecificReservation //new field
    &&  (this.canHaveReservedWork()))
    {
        // put our new strategy at the start of the list so it is picked first
        ret.addStart(WHSReservationHierarchyLevelStrategy::newFromStrategyType(WHSReservationHierarchyLevelStrategyType::AllAboveStatus, this.inventTable(),_inventDimReservationCriteria));
    }

    return ret;
}

Uptake the strategy in the Reservation page

To be able to use our new strategy in the Reservation page we need to make one more minor change to WHSReservationHierarchyLevelStrategy::newPrimaryStrategyFromMovement which controls what strategy is used for the Reservation page.

public static WHSReservationHierarchyLevelStrategy newPrimaryStrategyFromMovement(
    InventMovement  _movement,
    InventDim       _inventDimReservationCriteria,
    boolean         _isPhysicalReservation)
{
    WHSReservationHierarchyLevelStrategyType    whsReservationHierarchyLevelStrategyType;
    container                                   strategyTypes;
    WHSReservationHierarchyLevelStrategy       WHSReservationHierarchyLevelStrategy;

    ListEnumerator le = _movement.reservationHierarchyLevelStrategyList(_inventDimReservationCriteria).getEnumerator();

    // take the first one in the list since that should be the primary one
    if (Le.moveNext())
    {
        return le.current();
    }
    else // keep the old code in case some movements return an empty list
    {
        strategyTypes = WHSReservationHierarchyLevelStrategy::determineStrategyTypesFromMovement(_movement,_inventDimReservationCriteria, _isPhysicalReservation);

        whsReservationHierarchyLevelStrategyType = conPeek(strategyTypes,1);

        WHSReservationHierarchyLevelStrategy =  WHSReservationHierarchyLevelStrategy::newFromStrategyType(whsReservationHierarchyLevelStrategyType,_movement.inventTable(),_inventDimReservationCriteria, _movement.inventDimGroupSetup());


    }
    return WHSReservationHierarchyLevelStrategy;
}

Seeing it in action

Note: You should ensure that inventory status is not defaulted on your sales lines. This is controlled in the Warehouse management parameters: the Use default status for sales orders and transfer orders check box should be cleared:

When the new field is enabled on the sales line, the reservations looks like this:

When the reservation is done, it does not include the inventory status:

Changing the reservation so we can create work

If we have used the new strategy the Inventory status is missing on our reservations. Since it is a requirement that all dimensions above location are specified before we create work, we have a challenge.

So before we can create work we need to ensure that the Inventory status and all other dimensions above location are included in the reservation so it can be synchronized to the load lines.

We can choose different approaches for updating the reservations.

1. Re-reserve using a different reservation strategy so the reservation system determines the missing dimensions.
2. Update the dimensions using the InventUpd_ChangeDimension class . This option could be used if we wanted to change the reservations to some specific dimensions that we know.

For simplicity, we are going to use option 1. The code below illustrates how to change reservations for a single sales order.

public static server void main(Args _args)
{
    SalesId                 salesId = 'SO-101284'; //order we want to re-reserve
    SalesLine               salesLine;
    InventUpd_Reservation   reservation;
    InventQty               reserveQty;
    List                    strategyList;
    InventMovement          movement;

    ttsBegin;
    // go through the lines that used the new strategy
    while select salesLine
        where SalesLine.salesId == salesId
        &&    SalesLine.WHSUseNonStatusSpecificReservation == NoYes::Yes
    {
        //whatever was reserved before will be re-reserved
        reserveQty = salesLine.reservedPhysical();

        //Un-Reserve the entire reserved quantity
        reservation = InventUpd_Reservation::newMovement(
                                                InventMovement::construct(salesLine),
                                                reserveQty,
                                                true);

        reservation.parmAllowAutoReserveDim(false);//don't give the un-reserved quantity to other ReservOrdered transactions
        reservation.updateNow();

        movement = InventMovement::construct(salesLine);
        reservation = InventUpd_Reservation::newMovement(
                                                movement,
                                                -reserveQty,
                                                false);

        // Illustrating how to inject a list of strategies to the reservation
        strategyList = new List(Types::Class);
        strategyList.addEnd(WHSReservationHierarchyLevelStrategy::newFromStrategyType(WHSReservationHierarchyLevelStrategyType::AboveLocation, movement.inventTable(), movement.inventdim()));
        reservation.setWHSReservationHierarchyStrategyList(strategyList);
        // we could also take control of the queries used to find on-hand, for example adding some ordering on Status using :
        //reservation.setWHSInventReserveQueryBuilder(...);

        //now we are reserving with all dimensions above location
        reservation.updateNow();
    }

    ttsCommit;
}

After running the code the reservations for the sales line now includes inventory status:

Wrapping up

In this blog I showed how you can introduce a new reservation strategy that allows you to postpone decisions about which dimensions to reserve against.

If you wanted to start with reservations on a site level and then later distribute them to different warehouses you could follow a similar approach.

You could also replace Inventory status with Batch ID to achieve similar behavior for items that are batch controlled and have batch above location.

This would allow you to reserve the actual batches just before release. (What I have described here won’t work for batch below location items – that is a subject for a different blog post).

I hope this has given you some insight into some of the flexibility that the reservation system gives you.

Introduction

Previously it was not possible to start processing work header that were awaiting demand replenishment since the header and not the affected lines were blocked.

This is not optimal for all situations, e.g. if the work order contained many lines and only a few needed replenishments, the warehouse workers could not start picking but had to wait for replenishment of only a few lines completed.

In this posting we are going to cover the new functionality that allows you to start a work that has some lines awaiting demand replenishment and process the lines that can be picked.

This functionality is available in Dynamics 365 for Operations (1611).

Setup

A new policy for how to control the blocking of work that has lines awaiting replenishment has been introduced on the work templates. Blocking the entire order will result in the entire work being blocking, which is similar to the existing behavior.

If you choose to block individual lines, the work will no longer be blocked and non-blocked lines can be processed.

For this posting we have chosen to set the policy to Block individual work lines.

Scenario

We are going to release a sales order for 50 ea. of item T0100 from warehouse 61. We have 10 ea. on hand at two picking locations, therefore, we need a replenishment of 30 ea.

The location directives are setup in way that allows splitting and locating what ever quantities are available at the pick locations.

After releasing the wave the work for the sales order looks like below:

UI changes

You can edit and view the policy, the number of lines that are blocked and which lines are blocked on the Work form. The policy can only be changed when the work is Open.

Note: You can use the personalization feature and add fields to the grid if you want the information to be visible there.

Work report

The work report now also includes information about how many lines are blocked.

Work execution

To begin processing the work you can use one of the different work execution Mobile device menu items.

Here we will use the User directed to pick the first two lines.

After we have picked the first two lines we are presented with the below page; assuming that the replenishment has not yet taken place and therefore the worker needs to decide what should happen next.

Note that in the example the pick line with a “needs replenishment” is the last line – however, all these lines will just be skipped if there were additional lines on the header that could be picked.

Retry

This is to support a scenario where the worker can see the replenishment is just about to happen and just wants to wait until it is done and then continue picking after replenishment. Retry will just reread the lines and return the next pick line that is not awaiting replenishment if such line is found.

Cancel

Cancel allows the warehouse worker to exit the flow so he can do something else until the replenishment is finished. The work will be kept in its current state but it is no longer locked by the current user. Hence, another worker can process the work once the replenishment is completed.

Full

When clicking Full the lines that the worker has picked are added to a new work that the warehouse worker can then continue processing. The remaining lines that await replenishment remain on the original work header. This is consistent with the standard behavior of the Full button in other flows, which is also why we decided to keep the name of the button .

Wrapping up

In this posting we have shown how you can configure your work templates in a way that allows warehouse workers to start processing work that have one or more lines that await replenishment and some that are ready for picking.

We hope you will find the functionality useful and provide your feedback.

Introduction

In Microsoft Dynamics AX 2012 R3 you could short pick an item while executing the initial picking of an outbound work line using a mobile device. One of the challenges with that design is that after short picking, it was difficult to easily identify an alternative item location. This meant for the short-picked quantities to be part of the re-waving process, there needed to be additional processing time or goods were not always shipped in full, even if the alternative location had available items. With this new feature, we have designed both an automatic and manual feature for the warehouse user so that the user can select alternative locations (automatic) or select any location that has available inventory for that item (manual). This functionality is available in Dynamics 365 for Operations (1611).

You can set up the short picking work exception to do automatic, manual, or automatic and manual reallocation. These are the different options:

• Automatic reallocation – The location directives for the related work order type and warehouse will be queried. If there is available on-hand quantity at another location, the work will be updated and the user will be directed to pick the remaining items from the new location.
• Manual reallocation – A list with all the locations with unreserved quantity of that item will be displayed. The warehouse user can select one or more locations.
• Automatic and manual reallocation – The system will first try to automatically reallocate the quantity and if this is not possible, the warehouse user will see a list of locations. The location directives will not be queried and any location with available on-hand quantity will be displayed in the list.

Setup

Work exceptions page

Item reallocation dropdown

You can select the Item reallocation option on the Work exceptions page. This allows you to define several work exceptions with different item reallocation policies, so that the warehouse worker can choose one policy based on the guidance or on the needs of the shipment that he is processing.

Adjust inventory and adjustment type

Note, if the Adjust Inventory option is selected, all quantity for that the location and the dimensions above the item that is being short picked will be adjusted. This does not apply to items with tracking dimensions that are below the location.

You can also specify if you want to remove reservations.

Let’s say that there are 10 chairs available in your warehouse, all in one location and on one license plate. You release a sales order to pick all the 10 items from this location, and then set the work exception to adjust the inventory. When the warehouse user does short picking and only picks 2 chairs, the process might fail. To avoid this, select Remove reservations, so that the sales line reservation has a reservation on the 8 pieces and this reservation needs to be removed. Otherwise it is not possible to proceed, because the system cannot keep this reservation.

However, there can be other license plates at the same location or other locations that have 8 or more pieces available. In that case, regardless if Remove reservations is selected, the short picking will be completed sucessfully and the sales order line reservation for all the 10 pieces will be kept.

Note, the Remove reservations option does not apply to work reservations. Existing work reservations from the same orders or from other orders will be kept.

Work user page
Automatic reallocation is available for all users, while manual reallocation requires explicit setup for the user. This is because the visibility given to each user may be different because the items may be in a quarantine area or in a bulk area in which only trusted employees have access.

If a reallocation process has been selected, but the user is not eligible to use this process, a message will be added in the work creation history log and the user can continue to process the work as usual. Every time that the warehouse user selects an exception, a message will be added in the history log. The user will not receive any further information on his mobile device.

Supported work order types

All work order types that currently support short picking have been enabled for automatic reallocation: sales issue, transfer issue, raw material picking, and replenishment.

Note, if a replenishment line gets partially reallocated, the demand sales work (if any) will be updated accordingly. Moreover, replenishment links will be created (records in the WHSReplenWorkLink table) to point to the reallocated work lines.

Replenishment has been disabled for the manual reallocation, but all the other work order types are available for this process. In the following matrix, you can see which reallocation process will be triggered (if any), based on the work exception and work user setup. For example, if manual reallocation is not set for the warehouse user, the order type of the work being processed is Replenishment (3^rd row of the matrix). The selected work exception has Item reallocation set to be automatic (5^th column of the matrix), then the automatic reallocation process will be triggered.

General

Automatic reallocation

If the user selects a work exception with automatic item reallocation enabled, when he short picks a work line, he will receive a short pick confirmation screen after he enters the quantity that he wants to pick. After he confirms the short picking, the system will run through the location directives that have been defined for the specific order type and warehouse, and try to find one or more locations to pick the remaining quantity from. If only part of the quantity remaining to be picked is available in another location, only that quantity will be reallocated. If the location directive line has been set up to allow a split, more than one location can be selected to reallocate the quantity from.

The work will be updated accordingly. The following is an example of the work lines before and after the reallocation has been executed. The work lines show before item A0001 was short picked from location BULK-001.

This is what it looks like when work lines after item A0001 are short picked and the system reallocates 8 pieces from location BULK-002.

As you can see, all the work lines that were open or skipped when a line was short picked (in this case lines 2 and 3) are canceled and recreated after the reallocated work lines. This is necessary in order to maintain the correct sequencing of the work lines.

Manual reallocation

If the user selects a work exception with the manual item reallocation, he will see a list with all the locations of the same warehouse that have available quantity to create work. The short pick confirmation will not be displayed. The short picking will be executed after the user either selects a location or clicks Proceed in the first manual reallocation list. The locations will be sorted by available quantity in ascending order.

If the user clicks Proceed, the short picking will be executed and no quantity will be reallocated. If the user selects a location ID, for example BULK-007, the short picking will be executed and a new work line will be created to pick 4 pieces from BULK-007. This will display the following list.

If the user clicks BULK-006, the work will be updated again and one more pick work line will be created with 4 pieces from BULK-006. If all the quantity has been reallocated or if there are no other locations with available on-hand quantity, the user will proceed with processing the work. All locations will be displayed, regardless of the location directives.

The maximum number of locations to be displayed in the list is 120. If you need to display more locations, you can update the SessionSchema.xsd file in the WMDP solution to have a higher number of the controls. The current number is set to 250 (“maxOccurs = 250”) and each location displayed in the list needs two controls.

Automatic and manual reallocation

For automatic and manual reallocation, after the user has entered the quantity that he is short picking, the system will check if all the remaining quantity can be automatically reallocated. If it can, the short picking will be confirmed and the automatic reallocation will be executed. If none or only part of the quantity can be automatically reallocated, this process will be skipped and manual reallocation will be triggered.

Work creation history log

In all the above scenarios, there might be a delay between the short picking and the automatic or manual reallocation, which can result in other orders reserving inventory that had been initially calculated to be available for the reallocation. If that occurs, the quantity that will be finally reallocated will be available. If it is less than what was shown to the user, a message will be added in the work creation history log. The quantity that was not reallocated will be short picked and will need to be waved again.

Conclusion

You can use item reallocation during short picking to pick the entire quantity for a work order. The on-hand quantity registered in the system can be out of sync or for some reason it might not be possible to pick some items that are registered in the initial location. The warehouse user now has additional capabilities to partially or fully fulfill the customer request. The customer request can be fulfilled faster and it will be no longer necessary to create a new wave and release new work to fulfill the demand.

Additional ideas for further enhancing this feature include:

• Providing the warehouse manager with the ability to define a list of location profiles that should be excluded from the manual reallocation list.
• Enabling manual reallocation for replenishment order types.

We would appreciate your feedback on the above suggestions.

Scenarios

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

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

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

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

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

Set up inbound pick-and-drop

Setup scenario

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

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

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

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

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

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

Setup procedures

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

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

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

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

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

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

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

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

Next, see the following query setup for Work templates.

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

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

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