DynamicsAxSCM: Migration of Microsoft Dynamics AX WMS to new R3 warehouse and transportation functionality

[Blog bot]

Источник: http://blogs.msdn.com/b/dynamicsaxsc...tionality.aspx
==============

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

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

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

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

Migration of the warehouse management database information

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

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

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

or

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

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

Warehouse layout

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

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

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



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

Zone Group and Zone

Conceptually the following warehouse layout is used for WMSII:

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

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

The conceptual WHS warehouse layout includes:

Warehouse -> ZoneGroup -> Zone -> Location

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



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



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

Location type

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

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

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







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



Location names

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



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



Physical dimensions (Location)

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

Location profiles

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



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

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

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

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

Location stocking limits

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

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

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





Inventory location

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



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

Storage dimension group

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



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

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

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

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

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

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

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

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

License plate

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

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

Inventory status

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

On-hand, Inventory transactions, and Inventory dimensions

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

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

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

And/or

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

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

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

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

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

Microsoft Dynamics Technical Conference 2015 presentation:

http://mediadl.microsoft.com/mediadl...ers/BSAX22.wmv

https://mbs.microsoft.com/Files/cust...nerup_v02.pptx

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

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

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

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

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

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

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

High-level migration process steps when keeping existing orders

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

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

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

b. Re-hashing might be needed if a unique index is not adjusted (please see the blog post about this: http://blogs.msdn.com/b/dynamicsaxsc...scenarios.aspx

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

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

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

Or

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

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

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

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

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

We recommended you read the blog post: http://blogs.msdn.com/b/dynamicsaxsc...scenarios.aspx

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

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

b. Assumptions:

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

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

Links to addition material:

Video recording from the Microsoft Dynamics Technical Conference 2015:

http://mediadl.microsoft.com/mediadl...ers/BSAX22.wmv

Power point presentation from the Microsoft Dynamics Technical Conference 2015:

https://mbs.microsoft.com/Files/cust...nerup_v02.pptx

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

http://blogs.msdn.com/b/dynamicsaxsc...scenarios.aspx

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

http://blogs.msdn.com/b/dynamicsaxsc...hs-part-1.aspx

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

http://blogs.msdn.com/b/dynamicsaxsc...x-2012-r3.aspx

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

http://blogs.msdn.com/b/dynamicsaxsc...anagement.aspx

Reservations in Warehouse management AX 2012 R3:

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

Data migration tools:

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

Technical Conference 2013 presentation:

http://mediadl.microsoft.com/mediadl...4_BRK458-R.wmv




Источник: http://blogs.msdn.com/b/dynamicsaxsc...tionality.aspx