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.

Cumulative update 12 for Microsoft Dynamics AX 2012 R3 is now available for download on Lifecycle Services, PartnerSource and Customersource. In this blog post, we will give you an overview of the feature improvements for warehouse and transportation management. If you want more details about the release of CU12, see the Dynamics AX In-Market Engineering blog. The build number for Cumulative Update 12 is 6.3.5000.138 and the knowledge base article is KB3199741.

In short, the following enhancements are now available:

• Work creation policies have been added to control whether work should be created for finished goods putaway and raw material picking.
• A warehouse worker can now cancel work using a mobile device.
• You can now reverse ship confirmations of loads, cancel packing slip updates for sales orders, and cancel product receipts for purchase orders.
• The Movement work creation menu item now has the option to show inventory status.
• It is now possible to merge license plates that are tied to work in staging area.
• Warehouse workers can now manually move inventory using a mobile device even if there’s work created for that inventory.
• It is now possible to change unit of measure during quantity confirmation when picking batch items.
• Improvements to the On-hand form with a new column showing available physical inventory on exact dimensions.
• There is now support to create invoice journals for transfer orders when freight is reconciled in transportation management.
• It is now possible to create a work exception with LP receiving for transfer orders.
• Performance improvements to location directive search.

The following table provides a list of feature enhancements made to WMS and TMS.

This blog provides an overview of the new inbound consignment inventory capabilities in Microsoft Dynamics 365 for Operations version 1611 (November 2016) release.

Overview

It is possible to have consignment inventory owned by a vendor but stored at your site. When you’re ready to consume or use the inventory, you take over ownership of the inventory.

This blog post includes information about:

• How to physically receive vendor-owned on‑hand inventory without creating general ledger transactions.
• How to start a production process where the vendor-owned inventory can be physically reserved.
• How to change the ownership of the raw material so that you can process the consumption as part of production order processing.
• There is also some information about how vendors can monitor consumption of their inventory by using the vendor collaboration interface.

By reading this this blog post, you will learn how to:

• Enable inbound consignment inventory by associating an inventory owner dimension value with a vendor account.
• Create a consignment replenishment order header and line to record and process inbound vendor-owned inventory.
• Physically receive vendor-owned on‑hand inventory.
• Monitor inventory cost values when you have on‑hand inventory that is owned by both your own company and the vendor.
• See which on‑hand inventory is owned by you, and which is owned by the vendor.
• Initialize a production order with lines that are physically reserved/picked against vendor-owned on‑hand inventory.
• Process an ownership change journal that is linked to a production, to record the change of ownership of the inventory from the vendor to the current legal entity.
• Monitor the consumed inventory that external vendors must invoice your company for.
• Adjust vendor-owned on‑hand inventory by using counting processes.
• Transfer vendor-owned inventory between storage dimensions.

The demo data company USMF is used for this blog post.

The materials manager (Karl) associates an existing vendor with an inventory owner dimension value.

To track the ownership of the on-hand inventory, it is possible to associate a vendor account with an inventory owner dimension value from the page:

Inventory management > Setup > Dimensions > Inventory owners

It is possible to add a vendor account to the list. The Owner value can be updated to a value that differs from the vendor account number in case you would like to track it differently within the inventory dimension values. The Owner value will be shown to the vendor in the vendor collaboration interface.

Note: The current legal entity owner is created automatically. In this case, the owner dimension value is USMF for all processes that are not related to consignment inventory.

The product designer (Emil) creates a new tracking dimension group and raw material product for consignment inventory.

Click Product information management > Setup > Dimension and variant groups > Tracking dimension groups.

Search for an existing Owner tracking dimension group, or create a new Tracking dimension group that has the Owner tracking dimension set to Active.

When the Tracking dimension group gets assigned to a released product, it will be possible to track the ownership of the on-hand inventory.

Only Items using Standard cost or Moving average costing methods are supported using the Owner dimension.

The purchasing agent (Alicia) manually creates a consignment replenishment order.

Procurement and sourcing > Consignment > Consignment replenishment orders

A new consignment replenishment order has been enabled to record and process inbound consignment inventory.

The order has a very simple UI with header and lines.

As for the purchase order, the consignment replenishment order lines will create expected inventory transactions and the owner dimension value will automatically be assigned based on the linked value related to the vendor account.

The receiving clerk (Sammy)/purchasing agent (Alicia) performs product receipt against the consignment replenishment order.

To get the vendor-owned inventory physically updated, a registration (either via arrival journal or inventory registration) can be processed.

To get the order and inventory transactions into the final state, run the Product receipt update from the consignment replenishment order.

Note: An External product receipt value isn’t required during the product receipt update process. An Internal product receipt number will be used for tracing.

The order status (header/lines) will be updated to Completed as soon as all quantities gets updated.

The inventory accountant (Cassie) monitors the inventory values and cost objects.

It is important to understand that during the consignment replenishment order product receipt process, no cost value will be recorded, and no general ledger transactions will be created.

This means that all inventory statements and KPIs will show values as 0 (zero).

No Inventory value will exist because the on-hand inventory is not owned by the current legal entity USMF.

The external vendor (Erin) monitors on-hand consignment inventory.

On the Vendor collaboration page, it is possible to monitor the on-hand inventory information related to consignment inventory.

Vendor collaboration > Consignment inventory > On‑hand consignment inventory.

An external user will be able to monitor on-hand inventory for several vendor accounts (inventory owners) depending on setup.

The shop supervisor (Lars) initializes the production.

The production line inventory transactions can become reserved and even updated to the status Picked and having the owner dimension value different from the current legal entity. When reserving, the on-hand inventory owned by the current legal entity will take precedence over the vendor-owned inventory.

The materials manager (Karl) processes an inventory ownership change based on production lines.

Inventory management > Journal entries > Items > Inventory ownership change

To record an inventory ownership change, a new journal has been enabled.

The journal lines can be manually entered or created based on a query linked to production lines.

It is only possible to change the owner dimension value that equals the current legal entity.

When posting the journal, the vendor-owned on-hand inventory will be issued out via an ownership change transaction reference and received on the current legal entity (USMF) dimension value via a Purchase order process. The inbound transactions will become product receipt updated (Received) and the price calculations can be based on the Item prices or Trade agreements.

The purchase order lines created based on the consignment process will have the Origin = Consignment.

From the Purchase order line, it will be possible to view the related ownership change transactions, and from the Inventory ownership change journal lines, it will be possible to see the related production line transactions.

As it can be seen from the above screenshot, the inventory ownership change process automatically updated the Issue field with Reserved physically and Picked and the Owner dimension value is updated to USMF.

Therefore, the production flow can continue for the raw material, so that the material can become consumed and put into WIP.

The external vendor (Erin) monitors the consumption of material.

The external vendor can monitor the consignment inventory ownership updates via the page Vendor collaboration > Consignment inventory > Products received from consignment inventory.

The vendor can also see detailed information about the expected invoicing process by viewing the purchase order information.

The warehouse manager (Ellen) creates an on-hand counting journal for vendor-owned on-hand inventory.

In addition to the Consignment replenishment order, the vendor-owned on-hand inventory can be recorded via a counting process. Note: The data connector can be used to create and update counting lines.

The warehouse worker (John) transfers vendor-owner inventory to production.

In case the vendor-owned inventory needs to be registered and transferred to another storage dimension, for example another location, the Transfer journal can be used.

More information.

For more information, see Demo script for Inbound consignment inventory (Requires access to PartnerSource).

Dynamics 365 for Operations 1611 – Improved packing functionality

Based on the input that we have received from many of our customers and partners, we have improved the packing station experience in Dynamics 365 for Operations version 1611 (November 2016) to make sure that it seamlessly integrates with the rest of the warehouse workflows.

On a high level, we have improved the following areas:

• Setup experience is better aligned with the rest of Warehouse management.
• The packing station is now seen as a location. When the warehouse workers are logging in at the packing station, they will only see and operate on shipments and containers that are planned at the specific packing location.
• Work can now be generated to bring goods from the packing station to the staging and bay door locations.
• The concept of container groups has been introduced to allow multiple containers to be moved out of the packing station in one operation.
• A new packing policy has been introduced to give warehouse managers greater flexibility in how containers should be handled in the packing process.
• The concept of manual manifesting has been introduced to allow a loosely coupled integration to external transportation provider systems.
• The user experience for packing and container processing has been improved.

Upgrade from Dynamics AX 2012

If you are not upgrading from a previous Dynamics AX version where packing processes were used, you can skip this section.

The In packing status has been removed from the shipments and loads as they were not working consistently and resulted in redundant data. Consequently, the list pages for In shipments and Loads in packing have been deprecated. Containers in packing are tracked at a location level.

In previous versions, the packing location was defined as a Location profile ID. In the current version, this is changed so setup of packing location will be defined using location types to align with the process for identifying staging and final shipping locations.

It is possible to continue the operation with the current setting, but we recommend that you update the setting because the legacy packing setting will be deprecated in future versions.

Please note that this process is irreversible. After clearing and saving the Profile ID for packing location field, the field will be disabled and cannot be used anymore. For installations where the legacy has not been used, the legacy setting will always be disabled.

IMPORTANT UPGRADE GUIDELINES

• All containers must be closed before upgrade. In previous versions, containers did not have a container packing policy assigned on creation. In the current version and going forward, container packing policy must be assigned to containers to process containers. This can be mitigated by using the Change container packing policy function on the Container form, but it is not a recommended approach.
• In the current version and going forward, it is required that the locations that operate as packing stations must be LP controlled. If the packing station is not LP controlled, it is not possible to process containers after upgrade.
• Before using the newly upgraded system, make sure that the right container packing policies have been defined and are associated with the correct packing profiles.

Define location profiles and packing locations

Set up packing location profiles and packing locations in the same way as setting up staging and final shipping locations.

Create a location type that identifies the packing.

Under Set up parameters for Warehouse management, select Pack in the Packing location type.

Create one or more location profiles that use the packing location type.

Notice the setup for the packing location profile:

• Use license plate tracking must be set to Yes.
• Allow negative inventory should be set to No.
• Allow mixed items should be set to Yes.
• Allow mixed inventory statuses should be set to Yes.
• Allow mixed inventory batches should be set to Yes.

Set up the locations that operate as packing stations to use the new packing location profile ID.

Use location directives to bring goods to the packing station

Overall, the concept of using location directives to bring goods to the packing station is not changed.

The setup for using work to move goods out of the packing station will be described later in this document.

Log in the packing station

Before the packing station can be used, the Dynamics 365 for Operations user account must be associated with a user and the user must be created as a warehouse worker as shown below.

When navigating to the Pack form, the warehouse worker will be asked to log in the packing station by specifying the location of the packing station and the packing profile.

As it is very common that the same warehouse worker will work at the same packing station for a longer period, it is recommended to set up default values for the worker as shown below.

For the default packing station, it is possible to set up any combination. You can choose site only, site and warehouse, or even site, warehouse and location if the worker is always logging in the same packing station. All the values are the default values, but can be changed after login.

The default profile can be used for the warehouse manager to guide the warehouse worker at the packing station on what process to use when operating at the packing station, or it can be used for the warehouse worker to store favorite packing settings.

When selecting a Packing profile ID that has a Container packing policy associated with it, it is not possible to change the Container packing policy. If selecting a Packing profile ID without a Container packing policy, it will be possible to specify another default Container packing policy.

Set up container packing policies

The Close container profile field has been renamed to Container packing profile because it has a different impact on how containers are processed during packing.

In the previous versions, the Close container profile field was only used when a container was closed waiting for the decision as to which final shipping location the container should go to and what unit of measure should be used as the default value when weighing the container. As no work creation was supported, the container immediately appeared at the final shipping location after the container was closed.

In the current version, the Container packing policy defines how the container should be processed and consequently, it is applied immediately when a new container is created.

On the Overview tab, it is still possible to specify the actions when closing the container, but now it is possible to operate with or without work creation as well as defining when the container should be released from the packing station.

Container release policy

Using this parameter, it is possible to define what should happen when the container is released from the packing station by specifying one of the following options:

• Make available at final shipping location. This is the same as in the previous versions. As soon as the container is released, it is updated to the specified location for the final shipping location. When using this option, the field Default location for final shipment is enabled and used for specifying a preferred location for the container after closing it.
• Create work to move container from packing station. Using this option will create work for moving the container from the packing station to the staging area or directly to the bay door. When using this option, the field Work template is enabled and can be used for specifying a work template that should be applied when creating the work for the container.

Work template

A new work order type called Packed container picking is introduced. The work order type is used to describe the work created after a container or container group is released from the packing station.

In most cases, it is recommended to create work for moving the containers as it results in a better representation of the actual manual processes in the warehouse. There might be setups that are very simple or where packing station is located directly in the bay door area where it would be preferable to let the container be available at the final shipping location.

It is not possible to use work breaks, but it is possible to set up different work templates for different warehouses depending on the warehouse or the shipping carrier.

The examples below show templates for moving a container from staging or directly to the bay door.

Container closing policy

By using this parameter, it is possible to define what should happen when closing the container by specifying one of the following options:

• Automatic release. The container will be considered released from the packing station and the action specified under the Container release policy will be triggered.
• Delayed release. The container will not be released from the packing station immediately. It will be up to the warehouse worker to release it at a later point in time.
• Optional. During the process of closing the container, it will be possible to choose whether the container should be released at the closing time.

The setting of this parameter will depend on the nature of the individual customer and packing stations. If the packing station is mainly handling single container shipments directly to customers, it will be most natural to release the containers immediately. If the packing station is handling shipments with multiple containers or even pallets it will probably be optimal to delay the release until the entire shipment or pallet is packed and ready for pick up.

Weight unit

This parameter enables the user to choose a default unit of measure used for container closing and manifesting. Usually this will be the unit of measure of the scale used at the packing station.

The parameter will work for policies with or without work creation.

Manifesting

Manifesting is the process of specifying the weight of a container, container group or shipment as well as a tracking ID provided by the transportation provider.

There is no direct integration with external transportation provider systems. The warehouse worker must print the label from the external provider system and scan the tracking number when completing the manifest procedure.

As manifest requirements vary from customer to customer and even from shipment to shipment, the packing policies allow a lot of flexibility when it comes to the workflow. It is possible to set up manifests for containers, container groups and shipments in any combination.

If using a multiple level manifest procedure, it is a requirement that:

• All containers must be manifested before container group is manifested.
• All container groups must be manifested before shipment is manifested.

Manifesting will be described in more details when the workflow of the packing station is explained.

Container manifest

Container manifesting should be enabled if it is required to complete a manifest for every single container packed at the packing station.

Manifesting is activated by the parameter Manifest requirement for container. If this is set to Manual, the manifesting will be included as a requirement in the packing workflow. It will not be possible to close and release the container before the manifesting is completed. If the parameter is set to Transportation management, the manifesting will still be performed through the TMS rate engines. Please note that this requires partners to implement a specific engine for the transportation provider and will not work out of the box in the current version. 

If activating the Automatic manifest at container close, the warehouse worker must specify the manifest information as part of the Close container dialog to avoid a two-step process. This is usually the preferred setting if the same worker is packing and manifests the containers.

If activating the Print container content parameter, the container content report will automatically be printed as part of the container close. The report can of course also be printed and reprinted on demand.

Container group manifest

Container group manifesting should be enabled if it is required to complete a manifest for every single container group packed at the packing station. This will normally be used if containers are packed on a pallet and the entire pallet is manifested.

Manifesting is activated by the parameter Manifest requirement for container group. If this is set to Manual, the manifesting will be included as a requirement in the packing workflow. All containers included in the group must be closed before the group can be manifested.

There’s no transportation management engine support for container groups in the current version.

There’s no manifest report for container groups in the current version.

Shipment manifest

Shipment manifest should be enabled if it is required to complete a manifest for the entire shipment packed at the packing station. This will normally be used when one consolidated manifest is required even though the shipment consists of multiple containers or container groups.

Manifesting is activated by the parameter Manifest requirement for shipment. If this is set to Manual, the shipment manifest will be included as a requirement in the packing workflow. It will not be possible to release any containers on the shipment before the manifesting is completed. If the parameter is set to Transportation management, the manifesting will still be performed through the TMS rate engines. Please note that this requires partners to implement a specific engine for the transportation provider and will not work out of the box in the current version. 

If activating the Print packing slip parameter, the packing slip report will automatically be printed as part of the shipment manifest. The report can of course also be printed and reprinted on demand.

Packing station workflow

The first step for the warehouse worker is to log in the packing station. In the example below, we will log in the packing station at the location Pack.

Overall, the user interface for the packing station looks like the packing station in previous versions, but has several additions and workflow optimizations.

Prepare for packing

After the warehouse worker scans the shipment ID or the license plate identifying the shipment, the lines will be displayed and the packing of the shipment can be started.

Container packing policy

The new Container packing policy is now applied when containers are created. Normally the same packing policy will be used for a single shipment or even for the entire packing station.

Container group license plate ID

The Container group concept is introduced. This can be used if containers will be packed on a pallet and will be moved out of the packing station in one operation, instead of moving the individual containers.

Usually this field should be set up when starting to pack on a new pallet. The warehouse worker should scan the pallet license plate and it will work as a default container group for all new containers being packed and closed.

Please note that Container groups can only be used for containers that have a Container packing policy with delayed work creation.

It is possible to use an existing license plate, but if scanning a non-existing license plate, it will automatically be created.

License plates for containers that are already shipped should not be reused.

When closing the container, the default value will be used in the Close container dialog and it is possible to change it.

One way to add a container to a container group is through one of the containers forms, for example, Containers for shipment, Open containers at packing station, etc.

Both open and closed containers can be added to a container group. However, there are several restrictions when this can be done. For example: released containers can’t be added to a container group and containers from different shipments or different container packing policies can’t be added to the same container group.

Through the container forms, it is also possible to remove container from a container group by just clearing the Container group license plate ID field.

Pack the shipment

The shipment can now be packed in one or more containers. The first step is to create a new container with the selected Container packing profile.

The new container will be automatically selected in the Open containers view and packing can now be started. The view will also show the status of the container, for example, how much is packed, is the manifesting requirement met for the container, etc.

When an open container is selected, the warehouse worker will be able to start packing by scanning items using the Item packing section.

A new feature has been added so that it is now possible to pack everything on the selected open line by using the Pack button on the Action Pane. This will allow the warehouse worker to speed up packing shipments where it is not necessary to scan and pack individual items.

Manifest the container

If the container is using a policy with manual container manifest requirements, the Manifest container dialog can be opened and the container weight and tracking number can be specified.

Close the container

When the container is packed and any container manifest requirements are met, the warehouse worker can close the container. As the container is already manifested, it will no longer be possible to change the weight or the container tracking number.

If the container is using a policy with manual container manifest requirements and the policy parameter Automatic manifest at container close is enabled, the worker will be able be scan the container tracking number as part of the closing process.

If the container is not using a packing policy with container manifest requirements, the tracking number will not be displayed in the Close container dialog and the Manifest container button will not be enabled.

After the container is closed, follow the actions specified in the Container packing policy.

• If the policy parameter Container closing policy is set to Automatic release, the container will immediately be released when the container is closed.
• If the policy parameter Container closing policy is set to Delayed release, the container will be closed, but will be pending until released by the warehouse worker.
• If the policy parameter Container closing policy is set to Optional, the container will be closed and the worker can decide to release it as part of closing the container.

Delaying the release of the container can be very helpful in scenarios with or without work creation. In most situations, it would not be optimal to create work every time a container is closed, but rather wait until the entire shipment is packed. It can also be utilized when running without work creation and the containers are kept at the packing station until the truck arrives and the containers can be loaded.

Remember that an even more optimized work creation process can be achieved when using container groups for work creation container policies.

Please note that the old Close container form has been deprecated. In the case where it is needed to support the workflow where packing and closing take place in separate operations, the container closing should be performed on the Containers form.

Release the container

If the container is not part of a container group and there’s no requirement for shipment manifesting, the container can be released as part of the container close.

Depending on the Container packing policy, one of the following actions will occur when releasing the container:

• If the policy parameter Container release policy is set to Make available at final shipping location, the container will immediately be available at the specified location when the container is closed.
• If the policy parameter Container release policy is set to Create work to move container from packing station, work will be created for moving the container out of the packing station.

Unmanifest container

If the container is still open and manifested, it can be unmanifested from the Pack form. Containers cannot be unmanifested when they are closed or released.

Container group manifesting

If a Container group license plate is selected, the container group with the selected group license plate can be manifested using the Manifest container group button.

To manifest the container group, all manifest requirements for the containers in the group must be met and the containers must be closed.

When manifesting a container group, the following dialog will be shown and it is possible to specify the total gross weight and tracking number for the container group.

Unmanifest container group

If a Container group license plate is selected, the container group with the selected group license plate can be manifested using the Manifest container group button.

A container group cannot be unmanifested if the containers in the group are already released.

When the unmanifesting process is completed, the tracking number is removed from the container group and a confirmation message is displayed.

Manifest shipment

If a shipment is selected, the shipment can be manifested using the Manifest shipment button.

To manifest the shipment, all manifest requirements for the containers and the container groups in the shipment must be met and the containers must be closed.

When manifesting a shipment, the following dialog will be shown and it is possible to specify the total gross weight and tracking number for the shipment.

Unmanifest shipment

If a shipment is selected, the shipment can be unmanifested using the Unmanifest shipment button.

When the unmanifesting process is completed, the tracking number is removed from the shipment and a confirmation message is displayed.

View containers

There are different ways to view containers based on the context. When packing a shipment, it is useful to see containers that are part of the shipment.

The following form shows open, closed and released containers.

From this form, the packer can also perform all operations on containers such as closing, manifesting, reopening and releasing.

It is also possible to see all containers that are physically at the packing station. The Packing station form has buttons that can be used to view all open and closed containers at the packing station. These views will not be restricted to a specific shipment.

The views can be very helpful in the situation where one worker is packing the containers and the other worker is manifesting and releasing the containers.

Furthermore, a consolidated view of all containers is also available. This will mostly be useful for users working outside the context of a single packing station.

Work creation

If the packing station is operating with a container packing policy with work creation, work will be created when the container is released as shown in the example below, where we are using a work template including staging.

Work cancellation

If a container was released by mistake, it is possible to reopen it if the work is not started yet. If the warehouse worker reopens the container, the corresponding work will be cancelled.

If the other worker is cancelling the Packed container picking work, the corresponding container will also be reopened.

In scenarios where the container is already moved out of the packing station it is no longer possible to reopen the container by cancelling work. The container must be manually moved back to the packing station for reprocessing.

Work execution

The Packed container picking work will be executed through the mobile device using menu items for packed container picking and packed container loading as showed in the example below.

Packed container picking

Packed container loading

Work creation and possibilities for container groups

The work that gets created for the container groups is very similar to the one for just one container.

You will notice a couple of differences: Target license plate ID is the same as the Container group license plate ID and not the Container ID. The work quantity is also created from all the containers in the group.

The work execution itself is also similar.

There are some additional possibilities with the container groups that are not available to individual containers. Namely, it is possible to remove a container from a container group if the container group is at a staging location.

To make this possible, there is a new warehouse mobile device menu item called Remove container from group.

By default, when a container is removed from the group, then the related Packed container picking work is updated to consider that the container group now has a different number of containers on it.

It is also possible to turn on the Cancel related work when removing container from group setting. If that is the case, then the related Packed container picking work gets canceled when the container is removed from the group.

This is how the removing container flow looks like.

For example, let’s take the container group from the above work. It has three containers.

If we click the Selected container, we can see which containers are going to be removed. Please notice that none of the containers are removed at this point and that it is possible to get out of the flow by clicking the Cancel button.

When the Remove containers button is selected, the flow ends.

This is how the work looks like now.

The removed containers are now at the staging location and can be moved freely.

Use multiple packing stations

In this section, we’ll describe how to set up multiple packing stations and use them for packing the same shipment. Of course, it is possible to use multiple packing stations for multiple shipments.

There are multiple ways to end up in a situation where there are items from the same shipment at different packing stations, for example, overriding the put location and selecting the Full button during sales order picking work, but we’ll describe one way to do it.

First, let’s set up the work template. To guide items to different packing stations, there should be multiple works. To accomplish this, we’ll break work by Item ID (and shipment, but that is not relevant for our case).

Setup of the work template query.

Setup of the work breaks.

Now, we need to set up the location directives.

We need to set up one location directive for the first item.

Location directive query.

Location directive action query.

The one for the other item is similar and it just filters for item A0002 and location Pack2.

If we now have a sales order with these two items and release it to warehouse, it will generate two work headers that will bring items to different packing stations.

The user can now proceed and pack the items at two different packing stations.

Currently, the interaction between the two packing stations is very limited. For example, it is not possible to move items between them even if the items belong to the same shipment. It is also not possible to add containers to container groups that are at different packing stations.

Also, after the container is closed and released, it is not possible to move the container back for repacking at a different packing station.

It’s important to notice that if the items are at the packing station, it is still possible to adjust items, leaving the container in an inconsistent state.

We’re very happy to announce that Dynamics 365 for Operations – Warehousing has been made available on Windows Store and Google Play store. This app empowers warehouse workers in your organization to complete tasks in a warehouse by using mobile devices. It enables material handling, receiving, picking, putting, cycle counting, and production processes with your Dynamics 365 for Operations subscription.

The Dynamics 365 for Operations – Warehousing app includes the following features to boost productivity:

• A tailored interface designed for fast warehouse scanning
• Supports over 40 different warehouse processes
• Custom built on-screen numeric keypad for you to hit numbers easily
• A simple calculator for you to enter and calculate quantities in a breeze
• Possibility to adjust font size and width of input fields on any device

This blog post will take you through the prerequisites, how to navigate the app, and the options to configure the app in Dynamics 365 for Operations.

Prerequisites

The app is available on Android and Windows operating systems. To use this app, you must have one of the following supported operating systems installed on your devices. You must also have one of the following supported versions of Dynamics 365 for Operations.

Use the information in the following table to evaluate if your hardware and software environment is ready to support the installation.

Install the app

The app is available for download here:

• Windows (UWP) – Dynamics 365 for Operations – Warehousing on the Windows Store
• Android – Dynamics 365 for Operations – Warehousing on the Google Play Store

For detailed steps on how to install and configure the app, refer to this tutorial: Install and configure Dynamics 365 for Operations – Warehousing. 

Navigating the app

The app comes with a new user experience. In this section I will go through and show different pieces and elements that we have changed in the UI.

Log-in screen and menu

Once the app is installed and configured to connect to a Dynamics 365 for Operations instance, you will be presented with a log-in screen. Sign in with the User ID and password of the warehouse worker. Learn how to manage warehouse workers with this tutorial: Manage warehouse workers.

In the below image you can see the log-in experience, as well as the menu structure and navigation.

Task and details page

For our most common flows that follow the same pattern of scanning input fields, we have changed the UI to split all information into two pages, the task or details page. In the task page, the information shown will be the main input field, three rows of additional information, and a previously scanned value. Sometimes there’s more information to any given screen than what can fit in three rows, and therefore we made the Details page, which will contain all overflowing information and input fields, as well as product picture in case that exists for the item. You can control in what order you want information to be prioritized to be shown on the Task page, this is done from the Warehouse app field priorities page in Dynamics 365 for Operations. This will be explained a bit further down in this blog post.

Numeric keypad

The app comes with a custom numeric keypad, specially designed with rugged environments in mind. It has large buttons that are easy to touch, and a nifty calculator for those occasions where quantities needs to be converted on the fly.

Alternatively, we have added a stepper for quantity input fields, where you can deduct or add to the quantity field without using the numeric keypad. This can be useful when it is not a high amount, and just a quick change is needed.

Multiple input fields

If there’s multiple input fields in any given screen with values not seen before, the app will recognize this and display a different UI. If there is 3 or less input fields, a carousel will be shown, which will allow the warehouse worker to quickly switch between input fields, without leaving the task page.

If there’s more than 3 input fields filled out and not seen before, a multi-input page with all input fields shown in a list will be displayed. The example below is during a movement of goods, where an existing license plate is scanned for movement, where the app receives information on what item, quantity, unit etc. that is on the license plate. It will then display that content with multiple input fields on the Task page, in order to enable the warehouse worker to quickly review, and move forward to the next step.

Action pane

As you might have noticed from the previous pictures, there’s not any buttons displayed on any of the screens except for the green OK button. We have deliberately moved all other buttons to an action pane, that is accessible from the hamburger menu in the top right corner.

Settings in Dynamics 365 for Operations

There are two new pages added in Dynamics 365 for Operations:

• Warehouse management > Setup > Mobile device > Warehouse app field names
• Warehouse management > Setup > Mobile device > Warehouse app field priorities

I will explain below the use of these pages, and how they relate to the app.

Configure warehouse app field names

In Operations you can configure how metadata should be shown on a warehouse mobile device on the Warehouse app field names page.

In a new environment or company, you can select Create default setup to generate all field names that exist in any of the warehouse mobile device workflows, and assign them a default preferred input mode and input type.

Once you’ve generated a list of field names, the following options are available:

• Preferred input mode – This option defines whether a scanning field or a manual entry input field should be shown for the selected field name. This is useful to distinguish fields depending on if barcodes are used for the field or not. Note: Field names with preferred input mode set to Scanning can still enter information manually in case the barcode is unreadable or damaged.
• Input type – This option defines what input type should be used for the selected field name. Four options are available:
  • Selection – The selection list is used for field names that contain a list of options to choose from. This option is not editable, and can only be change through extension.
  • Date – Field names specified as date will show a date format with the label, to help warehouse workers know which format to enter the date in. This option is not editable, and can only be changed through extension.
  • Alpha – If Alpha is selected, the device keyboard will be used when entering information manually in the app. The keyboard experience can change depending on the device used.
  • Numeric – For field names that you know will use numeric input only, you can select this option to display a custom numeric keypad with the input field instead of the device keyboard.

Configure warehouse app field priority

In the Warehouse app field priority page, it is possible to put field names into different priority groups. This makes it possible to decide what information should be promoted to the main task page when warehouse workers are performing work using the app.

If you click Create default setup, a default set of priority groups will be generated. It is possible to create as many priority groups as needed, but only three priority groups will be shown on the task page of the app at any given time.

When Operations is sending out metadata to the app, it will give each field a relative priority depending on its priority group, and the app will display the first three priority groups contained in the metadata on the task page of the app. The rest of the overflowing metadata will be presented on a secondary details page.

Summary

This blog post has provided a brief overview of Dynamics 365 for Operations – Warehousing. As always, we would appreciate any feedback you may have. We hope you enjoy using the app.

Concepts

Financial dimensions are available on each requisition line in the lines details. The purpose is to let you update the accounting distribution ledger account on the requisition line. The accounting distribution ledger account consists of a main account and financial dimension values. Accounting distributions are used to define how an amount will be accounted for, such as how the expense, tax, or charges will be accounted for and posted in the ledger.

Updates on the financial dimension values on the requisition line will update the accounting distributions ledger account, not the other way around.

Create a requisition line and set up initial financial dimensions values

When a purchase requisition line is created, the values of financial dimensions are assigned from various sources that are specific to the purchase requisition line.

This works such that the logic will apply values from what is considered the most important or specific source toward the least important source. The sources are ranked in the following order:

1. Project
2. Requester
3. Vendor
4. Item

If one of the sources is not on the requisition, e.g. not related to a project or does not include a reference to a specific item from the master data, then the source is ignored.

The financial dimensions are only assigned a value once. This is done by first taking all dimension values available from the project, and then taking the dimension values from Requestor that are used but not already assigned a value. Next, the values from the Vendor for dimensions that were not already assigned a value are used, and so on. In the following example, the default financial dimension values are set up for Vendor 1 and Requester.

Create a requisition line for an item that has the default Vendor1.

As you can see from the table above, the Requestor’s default value for financial dimension is Department (033). This value takes priority over the Vendor’s default value Department (025).

If the requisition is not for a project, then that source will not contribute to the financial dimension values.

The accounting distribution ledger account dimension values will be set according to the final result of the values on the requisition line.

Manually update the financial dimension on a requisition line

When you update a financial dimension value on the requisition line to a non-blank value, that will update the dimension values on the accounting distributions. If the accounting distribution lines are split, then all lines will be updated with the new value.

• For non-stocked items and lines not referring to a catalog item – Setting a financial dimension value to blank on the requisition line will not update the accounting distribution.
• For stocked items and fixed assets – Setting a financial dimension value to blank on the requisition line will update the accounting distribution by removing the dimension.

For stocked items and fixed assets, the financial dimensions need to be in sync between the financial dimension on the line and the accounting distributions. Note that the accounting distributions cannot be split or edited manually for such cases.

Update a vendor or project

Two of the original sources for setting financial dimension can be changed on the requisition line: project and vendor. Changing one of these on the requisition line will reinitialize the financial dimensions on the requisition line according to the ranking of the sources described above. The new initialization of the financial dimension values will only update the financial dimensions that do not have any value, i.e. are blank. The existing financial dimension values on the purchase requisition line will take priority, and thereby keep their value.

Changing the project or vendor will also mean that the accounting distributions ledger account is reset and updated based on the new project or vendor and the updated set of financial dimensions. If the accounting distributions are spilt, then the split will be removed during the reset.

Note that if you want to ensure that the financial dimensions are reset to how the requisition line was initially created when changing the project or vendor, clear all the financial dimensions on the requisition line that you want to re-default.

Example

Set up the following default values.

Create a requisition line for a non-catalog item.

Use a template to update the accounting distribution

You can only use a template for non-stocked items and lines not referring to a catalog item. The lines should also not be categorized as a fixed asset item.

When you apply a template on your requisition line it will update the accounting distribution directly with a split distribution on different dimensions. Applying a template will not change the financial dimension values on the requisition line.

However, if you manually change a financial dimension value to a non-blank value on the requisition line, then that dimension will be updated on all split accounting distribution lines. Clearing a financial dimension value on the requisition line will not change the accounting distributions.

If you change a vendor or project the financial distributions from the vendor or project will update the financial dimension on the requisition line as described above; however, using a template will prevent the accounting distribution split from being cleared. Any updated dimension value will update all the split lines in accounting distributions.

If you remove the template from the requisition line, then the accounting distributions will be reset based on the financial dimension values on the requisition line. Any split lines in the accounting distributions will be removed.

Introduction

We last looked at the Warehouse Mobile Devices Portal (WMDP) in detail in a series of blog posts here, here, and here.  The last one covered how to build custom solutions and walked through building a new sample workflow for the WMDP.  This post will be updating that sample to cover some of the changes that have occurred with the Advanced Warehousing solution and the Dynamics 365 for Finance and Operations – Enterprise Edition warehousing application.

WMDP vs Dynamics 365 for Warehousing Mobile App

The Warehouse Mobile Devices Portal (WMDP) interface, which is an IIS-based HTML solution (described in detail here), is being deprecated in the July 2017 release of Dynamics 365 for Finance and Operations (see deprecated features list here). Replacing this is a native mobile application shipping on Android and Windows 10 devices.  The mobile app is a complete replacement for the WMDP and contains a superset of capabilities – all existing workflows available in the WMDP will operate in the new mobile app.  You can find more detail on the mobile app here and here.

Customizing the new Dynamics 365 for Warehousing Mobile App

The process for customizing the new mobile app is largely unchanged – you can still utilize the X++ class hierarchy discussed in the previous blog post.  However – I want to walk through some of the differences that enable customizations to exist as purely extensions.  The previous solution required a small set of overlayered code.  Moving forward this practice is being discouraged and we recommend all partners and customers create extensions for any customizations.

As before, we will be focusing on building a new workflow around scanning and weighing a container.  The inherent design concept behind the Advanced Warehousing solution is unchanged – you will still need to think and design these screens in terms of a state machine – with clear transitions between the states.  The definition of what we will build looks like this:

WHSWorkExecuteMode and WHSWorkActivity Enumerations

Just as in the previous blog post – to add a new “indirect work mode” workflow we will need to add values to the two enumerations WHSWorkExecuteMode and WHSWorkActvity.  The new enum names need to match exactly as one will be used to instantiate the other deep inside the framework.  Note that both should be added as enumeration extensions built in a custom model.  Once this has been done it will be possible to create the menu item in the UI – since the WHSWorkActvity enumeration controls the list of available workflows in the UI:

You can see the extension enumeration values in the following screenshots:

WHSWorkExecuteDisplay class

The core logic will exist within a new class you will create, which will be derived from the WhsWorkExecuteDisplay base class.  This class is largely defined the same way as the WMDP-based example, however there is now a much easier way to introduce the mapping between the Execute Mode defined in the Menu Item and the actual class which performs the workflow logic – we can use attributes to map the two together.  This also alleviates the need to overlay the base WHSWorkExecuteDisplay class to add support for new derived classes (as the previous WHSWorkExecuteDisplay “factory method” construct forced us to do).

The new class will be defined like this:

[WHSWorkExecuteMode(WHSWorkExecuteMode::WeighContainer)]
class conWhsWorkExecuteDisplayContainerWeight extends WhsWorkExecuteDisplay
{
}

Note that all the new classes I am adding in this example will be prefixed with the “con” prefix (for Contoso).  Since there is still no namespace support it is expected partner code will still leverage this naming scheme to minimize naming conflicts moving forward.

The displayForm method is required – and acts as the primary entry point to the state machine based workflow.  This is completely unchanged from the previous example:

[WHSWorkExecuteMode(WHSWorkExecuteMode::WeighContainer)]
class conWhsWorkExecuteDisplayContainerWeight extends WhsWorkExecuteDisplay
{
    container displayForm(container _con, str _buttonClicked = '')
    {
        container    ret = connull();
        container    con = _con;

        pass = WHSRFPassthrough::create(conPeek(_con, #PassthroughInfo));

        if (this.hasError(_con))
        {
            con = conDel(con, #ControlsStart, 1);
        }

        switch (step)
        {
            case conWeighContainerStep::ScanContainerId:
                ret = this.getContainerStep(ret);
                break;

            case conWeighContainerStep::EnterWeight:
                ret = this.getWeightStep(ret, con);
                break;

            case conWeighContainerStep::ProcessWeight:
                ret = this.processWeightStep(ret, con);
                break;

            default:
                break;
        }

        ret = this.updateModeStepPass(ret, WHSWorkExecuteMode::WeighContainer, step, pass);

        return ret;
    }
}

A detailed analysis of this code can be found in the previous blog post – we will skip forward to the definition of the getContainerStep method, which is where the first screen is defined.  The two methods used to define the first screen are below:

private container getContainerStep(container _ret)
{
    _ret = this.buildGetContainerId(_ret);
    step = conWeighContainerStep::EnterWeight;

    return _ret;
}

container buildGetContainerId(container _con)
{
    container   ret = _con;

    ret += [this.buildControl(#RFLabel, #Scan, 'Scan a container', 1, '', #WHSRFUndefinedDataType, '', 0)];
    ret += [this.buildControl(#RFText, conWHSControls::ContainerId, "@WAX1422", 1, pass.lookupStr(conWHSControls::ContainerId), extendedTypeNum(WHSContainerId), '', 0)];
    ret += [this.buildControl(#RFButton, #RFOK, "@SYS5473", 1, '', #WHSRFUndefinedDataType, '', 1)];
    ret += [this.buildControl(#RFButton, #RFCancel, "@SYS50163", 1, '', #WHSRFUndefinedDataType, '', 0)];

    return ret;
}

Note that I am using a class to define any custom constants required for the Warehousing logic.  This was typically done with macros in the previous version – but these can cause some issues in extension scenarios.  So instead we are encouraging partners to define a simple class that can group all their constants together – which can then be referenced as you see in the code above.  The only area where this does not work is in attribute definitions – this will still need a Macro or String definition.  Here is mine so far for this project:

class conWHSControls
{
    public static const str ContainerId = "ContainerId";
    public static const str Weight = "Weight";
}

The other important thing to notice in the above code is that I have explicitly defined the data type of the input field (in this case extendedTypeNum(WHSContainerId)).  This is important as it tells the framework exactly what type of input field to construct – which brings us to the new classes you need to add to support the new app functionality.

New Fields

In the previous version of this blog we discussed the fact that since we are adding new fields to the warehousing flows that are not previously handled in the framework we must modify (i.e. overlayer) some code in the WHSRFControlData::processControl method.  This allows the framework to understand how to handle the ContainerId and Weight fields when they are processed by the WMDP framework.

In the new model these features are controlled through two new base classes to customize and manage the properties of fields.  The WHSField class defines the display properties of the field in the mobile app – and it is where the default input mode and display priorities are extracted when the user configures the system using the process described here.  The WhsControl class defines the logic necessary for processing the data into the field values collection.  For my sample, we need to add support for the ContainerId field – so I have added the following two new classes:

[WhsControlFactory('ContainerId')]
class conWhsControlContainerId extends WhsControl
{
    public boolean process()
    {
        if (!super())
        {
            return false;
        }

        fieldValues.insert(conWHSControls::ContainerId, this.data);

        return true;
    }
}

[WHSFieldEDT(extendedTypeStr(WHSContainerId))]
class conWHSFieldContainerId extends WHSField
{
    private const WHSFieldClassName        Name        = "@WAX1422";
    private const WHSFieldDisplayPriority  Priority    = 65;
    private const WHSFieldDisplayPriority  SubPriority = 10;
    private const WHSFieldInputMode        InputMode   = WHSFieldInputMode::Scanning;
    private const WHSFieldInputType        InputType   = WHSFieldInputType::Alpha;

    protected void initValues()
    {
        this.defaultName        = Name;
        this.defaultPriority    = Priority;
        this.defaultSubPriority = SubPriority;
        this.defaultInputMode   = InputMode;
        this.defaultInputType   = InputType;
    }
}

Obviously my conWhsControlContainerId class is not doing much – it is just taking the data from the control and placing it into the fieldValues map with the ContainerId name – which is how I will look for the data and utilize it later in the system.  If there was more complex validation or mapping logic I could place that here.  For example, the following is a snapshot of the process logic in the WhsControlQty class – this manages the logic for entering in quantity values from the mobile app:

public boolean process()
    {
        Qty qty = WHSWorkExecuteDisplay::str2numDisplay(data);
        if (qty <= 0)
        {
            return this.fail("@WAX1172");
        }

        if (mode == WHSWorkExecuteMode::Movement && WHSRFMenuItemTable::find(pass.lookup(#MenuItem)).RFDisplayStatus)
        {
            controlData.parmFromInventStatusId(controlData.parmInventoryStatusSelectedOnControl());
        }
        else
        {
            controlData.parmFromInventStatusId(controlData.getInventStatusId());
        }

        if (!super())
        {
            return false;
        }

        if (mode == WHSWorkExecuteMode::Movement && fieldValues.exists(#Qty))
        {
            pass.parmQty(qty ? data : '');
        }
        else
        {
            fieldValues.parmQty(qty ? data : '');
        }

        //When 'Display inventory status' flag is unchecked, need the logic for #FromInventoryStatus and #InventoryStatusId
        this.populateDataForMovementByTemplate();

        return true;
    }

The buildGetWeight method is very similar to the previous UI method – the only real difference is the Weight input data field.  Note that we don’t need to define a custom WHSField class for this field because it already exists in the July Release.

Error Display

There was another minor change that was necessary before I could get the expected behavior, and it points to a slight change in the framework itself.  In the previous version of the code when I reported that the weight was successfully saved I did so with an “addErrorLabel” call and passed in the WHSRFColorText::Error parameter to display the message at the top of the screen.  This same code in the new warehousing app will now cause the previous step to be repeated, meaning I will not get the state machine transition I expect.  Instead I need to use the WHSRFColorText::Success parameter to indicate that I want to display a status message but it should not be construed as an error condition.

container processWeightStep(container _ret, container _con)
…
ttsBegin;
containerTable = WHSContainerTable::findByContainerId(pass.lookupStr(conWHSControls::ContainerId),true);
if(containerTable)
{
    containerTable.Weight = pass.lookupNum(conWHSControls::Weight);
    containerTable.update();
    _ret = conNull();
<strong>    _ret = this.addErrorLabel(_ret, 'Weight saved', WHSRFColorText::Success);
</strong>    pass.remove(conWHSControls::ContainerId);
    _ret = this.getContainerStep(_ret);
}
else
{
    _ret = conNull();
    _ret = this.addErrorLabel(_ret, 'Invalid ContainerId', WHSRFColorText::Error);
    pass.remove(conWHSControls::ContainerId);
    _ret = this.getContainerStep(_ret);
}
ttsCommit;

Caching

The mobile app as well as the AOS perform a significant amount of caching, which can sometimes make it difficult to add new classes into the framework.  This is because the WHS code is heavily leveraging the SysExtension framework.  I find that having a runnable class included in the project which simply calls the  SysExtensionCache::clearAllScopes() method can help resolve some of these issues.

Conclusion

At this point I have a fully functional custom workflow that will display the new fields correctly in the mobile app.  You can see the container input field and weight input below.  Note that if you want to have the weight field display the “scanning” interface you can change the “preferred input mode” for the Weight EDT on the “Warehouse app field names” screen within the Dynamics 365 environment itself.

The Dynamics 365 for Operations project for this can be downloaded here.  This code is provided “as-is” and is meant only as a teaching sample and not meant to be used in production environments.  Note that the extension capabilities described in this blog are only available in the July 2017 release of Dynamics 365 for Finance and Operations or later.

In the latest version of Dynamics 365 for Finance and Operations, Enterprise Edition we put a lot of effort to make it easier to create initial configuration of the Cost Accounting module.

Take a look how simple it is!

Cumulative update 13 for Microsoft Dynamics AX 2012 R3 is now available for download on Lifecycle Services, PartnerSource and Customersource. In this blog post, we will give you an overview of the feature improvements for warehouse and transportation management. If you want more details about the release of CU13, see the Dynamics AX In-Market Engineering blog. The knowledge base article for Cumulative Update 13 is KB4032175.

• Packed goods can now be brought from the packing station to the staging area or loaded directly on a truck.
• Ability to move one item or the entire license plate (LP) although there is replenishment work behind.
• Transfer order receiving and returns are now enabled as part of Mixed pallet receiving.
• Guided partial cycle counting at a location has been enabled.
• Short picking - Inventory reallocation. Ability to pick items from another location in short picking scenarios.
• Use the demand replenishment method in the raw material picking process.
• Correct reservation status after re-marking of WHS items with the Storage dimension enabled.
• Timing of planned production orders when overlap jobs are enabled and the route operations use different calendars.
• Product confirmation requested by the system before a put is completed.
• Ability to report consumption of staged and order picked material.
• Plan purchase orders through TMS in an inbound process when using Change management.
• Pick (other) work order lines even if one of the order lines is blocked by demand replenishment.
• RAF\Transfer Order integration. Finished goods can be cross docked to bay door locations providing an alternative to the put-away process where finished goods from the production output would normally be put in the Finished goods put location.
• With a maximum weight or volume on the work template, the work split is now based on the directive unit and not on the lowest unit of measure.

Key concepts

Inventory dimension

An inventory dimension can have a Physical value and a Financial value. The setting of the Physical value controls whether a dimension is active for Inventory management and Warehouse management. The setting of the Financial value controls whether a dimension is active for Inventory accounting in Cost management.

Note: An inventory dimension can have an active Physical value but no Financial value. However, it can’t have an active Financial value but no Physical value.

Cost object

The term cost object was introduced in Microsoft Dynamics 365 for Finance and Operations, Enterprise edition. It represents a key concept that is used in the management of business costs. A cost object is an entity that costs and quantities accumulated for. For example, a cost object entity can be either a product or product variants, such as variants for style and color.

A cost object is derived from the item ID and the inventory dimensions that have an active Financial value.

There are three groups of inventory dimensions: product, storage, and tracking. Each inventory dimension can have a set of dimensions associated with it. For each dimension, you can set up the following inventory dimension values.

Example: Define a cost object

When an item is created, a set of inventory dimension groups can be assigned to it. The following table shows how you can define a cost object.

In the following example, the cost objects are defined by Item + Color + Site.

Examples:

• Speaker + Black + Site 1
• Speaker + White + Site 1
• Speaker + Black + Site 2

The inventory objects can be used to report the physical quantity at any level in the warehouse that is defined by Item + Color + Site + Warehouse.

Examples:

• Speaker + Black + Site 1 + WH 11
• Speaker + Black + Site 1 + WH 12
• Speaker + White + Site 1 + WH12

It’s crucial that you understand the concepts. The configuration and implementation of these concepts have a significant impact on the whole system, especially in Inventory management and Cost management.

After the configuration is implemented, it’s almost irreversible. Any change will require significant resources and will affect system usage itself.

In the rest of the document, we will use the Speaker item as an example. The inventory valuation method is set to Moving average.

Cost object:

• Speaker + Black + Site 1

Inventory objects:

• Speaker + Black + Site 1 + WH 11
• Speaker + Black + Site 1 + WH 12

After a few transactions have been posted, the following inventory transaction entries are generated in the Inventory subledger.

The inventory close job was run as of January 31, 2017. Because the inventory valuation method was Moving average, no adjustments were posted.

As part of the fiscal period–end process, an Inventory value report that shows the ending inventory balance in quantity and value is required. To meet this requirement, the inventory value report framework was introduced. The framework lets you create custom reports by including more data points that depend on the type of business. It also lets you define the level of aggregation for cost objects.

Note: The inventory value report is designed to print only the values per cost object or aggregations of cost objects.

You create an Inventory by cost object report, based on the configuration in the following table.

The report will look like this.

Note: The Warehouse column will remain blank, because the Speaker item doesn’t have any cost object that includes the Warehouse dimension. Inventory dimension Warehouse is only set to Physical.

View the inventory value by physical location Warehouse

Configure the storage dimension group

To meet the customer’s request, you could configure the storage dimension group differently. In this case, the Warehouse dimension is configured so that it has a Financial value.

This configuration affects how the Speaker item is handled by the system. The cost object and inventory object now have the same level of granularity.

Cost objects:

• Speaker + Black + Site 1 + WH 11
• Speaker + Black + Site 1 + WH 12

Inventory objects:

• Speaker + Black + Site 1 + WH 11
• Speaker + Black + Site 1 + WH 12

The configuration also directly affects the inventory valuation. In this example, the FIFO, Weighted average, or Moving average inventory valuation method will be applied per cost object, and the overall result will differ.

The result will also differ when the Inventory value report is run by using the same configuration that is described in the previous section.

The Warehouse column now has a value, and the inventory value is 26.00 instead of 24.00.

Note: When you activate the Financial value for the Warehouse inventory dimension, you might affect performance. All transfers between warehouses are now considered financial movements, and financial movements can cause cycles in the Inventory close job. If the Warehouse inventory dimension is used only to physically track inventory, these will be closed as non-financial transfers before the cost calculation begins and the changes of cycles reduced.

Create a custom report that looks at inventory transactions and settlements.

You can create a custom report that sums inventory transactions and settlements by InventDim ID.

The old Physical inventory by inventory dimension report was designed for that purpose. In the report dialog box, users could select any inventory dimensions, regardless of whether they were part of the defined cost objects.

This approach works, provided that the inventory dimensions that you select are part of the defined cost object. However, if you select an inventory dimension that isn’t part of the cost object, the report starts to print incorrect results.

The following table shows the result of printing balances per item and inventory dimensions.

Note: The inventory cost is calculated at a level above the inventory dimension and warehouse. Therefore, the cost on issue transaction from warehouse WH11 explains why the inventory value per warehouse can become negative.

Report the value of physical locations

If the value of a physical location must be reported, a sum of transactions per location, as described in the previous section, isn’t the solution.

The correct approach is to calculate the value per location by using the following simple formula:

Value = Cost object, cost × physical object, quantity

Cost object:

• Speaker + Black + Site 1

Inventory objects:

• Speaker + Black + Site 1 + WH 11
• Speaker + Black + Site 1 + WH 12

In Microsoft Dynamics AX 2012 R3, a new report that is named Inventory aging was introduced. As the name of the report implies, this report does more than just report the value by physical location. It can also show the age of the current inventory in the user-defined buckets.

In the report dialog box, enter the following information.

The following table shows only the first section of the Inventory aging report, but the user-defined buckets have been omitted.

Conclusion

If your organization must provide inventory value by any physical location, you don’t have to update the current configuration of inventory dimension groups. This change can be very intrusive, and also affects the cost calculation and performance. We also don’t recommend that you build a custom report for this purpose.

The Inventory aging report is designed to calculate the cost per cost object and then can apply it to any physical level that is selected on the report. This report is designed to automatically detect the level that the cost object is defined at per item. It then applies the formula to calculate the value by physical location.

Allowing physical negative inventory may have undesirable consequences in inventory accounting, especially if the inventory costing principle is Actual and the valuation method is either FIFO or Weighted average.

Most of the issues that are related to physical negative inventory can be mitigated by using the correct configuration and maintenance of data.

Example: Why is the cost out of sync?

The following table lists the required setup for the Item model groups.

The purchase from the supplier always takes place at a unit cost of 7,500.00.

The following table lists the events as they occur, in chronological order.

The system starts issuing from inventory at cost per unit of 18,750.00 even though the cost of purchase has not exceeded 7,500.00.

Why does this happen?

In order to explain this in better detail, let’s add a few more columns on the rightmost side, in green. These new columns represent the inventory balance after posting the specific transaction. The inventory balance is also known as InventSum.

Notes:

1. The Cost per unit is 0.00. When the balance is negative, the system looks for a fallback cost to apply.
   1. First, the system looks for an active cost. This fails.
   2. Second, the system looks for cost set up in the Cost price field in the item master record. The cost is equal to 00.
2. The Cost per unit is 7,500.00. The balance is still negative. The system looks for a fallback cost to apply.
   1. The system looks for an active cost. This succeeds.
   2. The latest cost price was set to Yes on the item record. The prior Purchase order unit cost of 7,500.00 has now become the active cost.
3. The same condition applies as in number 2.
4. The Cost per unit is 18,750.00. If the balance is positive at the time of posting the issue transaction, the system applies the average cost of the balance.
   500.  Average cost is calculated as: 37,500.00 / 2.00 = 18,750.00

The issue is that the inventory balance of 1 piece at 18,750.00 is overvalued because the item has never been purchased at a cost higher than 7,500.00. The reason for this overvaluation is that the first issue transaction leaves inventory at a cost per unit of 0.00. The wrong cost estimation will continue to ripple through the following transactions.

The only way to get the inventory balance back in sync is to run either the Recalculation or Inventory close jobs.

The Inventory close will apply the selected Inventory model, in which case is FIFO, and then adjust the cost on the issue transactions accordingly.

Note: If the inventory balance is negative when executing the inventory close, the balance will not be adjusted. A full adjustment can only occur when the balance is positive, and enough receipts exist that can adjust the issues.

Conclusion

By default, all items should have an active cost. If you plan to allow temporary physical negative inventory, which is a valid scenario in certain business, it’s essential to apply an active cost before creating any transactions on the item.

Introduction

This blog describes the new capabilities that allow you to migrate existing items with open inventory transactions so they can use the new storage dimensions. This can be needed when you upgrade from older versions of Microsoft Dynamics 365 for Finance and Operations that supported the pallet dimension or if you want to use the Warehouse management functionality for existing items that were previously using WMS1 processes.

Typical migration scenarios:

• You have existing items with the location dimensions enabled.
• You have existing items with the location dimensions enabled and the pallet dimensions active.
• You have existing items with the location enabled which are catch-weight items.

The goal when migrating items to use warehouse management enabled processes

The following setup is required to use an item in warehouse management processes:

1. The item must use a storage dimension group that is set up to use warehouse management processes which means that the Inventory status dimension, the location and the license plate must be active.
2. A reservation hierarchy must be assigned.
3. A unit sequence group must be assigned.

The goal of the migration is to enable the items to meet the above  criteria and ensure that all related data is consistent with the items’ new settings allowing business processes to proceed after the migration.

High-level overview of the process

The upgrade process – blocking items

If you upgrade from a version that supported pallets the upgrade will identify the items that had the pallet dimension active and create a record in a new table called InventUpdateBlockedItem. This is done to block the items from all inventory processes because the item is configured using unsupported settings.

Items that are blocked must be migrated. The blocked items can be viewed in the Items blocked for inventory updates form.

The migration cockpit Change storage dimension group for items

The migration cockpit is simple. It allows you to enter the item ID of the items you want to be migrated and the new storage dimension group. If the item is to be downgraded from a group with the pallet dimension active, this is all you need.

If the item should be converted to use warehouse management enabled processes, you need to assign a reservation hierarchy and a unit sequence group.

The illustration below is a screenshot of the form.

Using entities to populate the data

You can use both OData which allows you to use Excel directly and data management to import and export the data.

OData

You can use the OData approach by clicking the Open in Microsoft Office icon and export the data to Excel. Once the information has been entered, the changes can be synchronized back.

Data management

For larger datasets, data management is the most effective. The entity is called Item storage dimension group change request and follows normal data management patterns.

Validation

Before the migration is started, the validation should be performed to ensure that the data is ready for migration. Several conditions are validated:

• A default inventory status value must be defined
• Inventory on-hand on pallets must not exist on non-license-plate-tracked locations
• Inventory on-hand without pallets must not exists on license-plate-tracked locations
• That the combination of the selected storage dimension group and reservation hierarchy is valid
• If migrating to use warehouse management processes, the item cannot be enabled with catch weight

The list is not exhaustive, but it covers the most important validation points.

Starting the migration

The migration is started by clicking the Process changes button.

The migration supports parallel processing for parts of the process. The batch framework is used and the different steps will be handled by different batch tasks.

The recommendation is to set the Recommended number of parallel tasks field to two times the number of cores that are available. It is recommended to have a dedicated batch server for the migration since the migration is a heavy process due to the updates to the inventory dimensions.

Un-supported scenarios

Catch weight enabled items:  Catch weight enabled items are not supported in the new WHS. If such items exist, and they have the pallet dimension active, they will need to be downgraded to a dimensions group where only the location is active., Otherwise an ISV solution should be used.

Reserve Ordered transactions: Because of the way reservations work for warehouse management enabled items there are certain constraints on the state of the inventory transactions. If there are Reserved ordered transactions with a “hole” in the dimensions, the item cannot be converted.

A “hole” could exist for an item that has the batch dimension active and has the batch placed below the location in the reservation hierarchy. If a reservation exists on site, warehouse, batch, then the location is missing, which is what we refer to as a “hole”. This is not supported.

The mitigation is to either assign the missing dimensions or clear the dimensions so the “hole” is removed.

Customization that involves inventory dimensions

If you have customizations related to inventory dimensions that fall in one of these two categories:

• New inventory dimensions field on existing table
• New table with and inventory dimensions

You need to do something before you can use the migration process. Otherwise you will get an error like the one below:

Since a new inventory dimensions field exists, the system needs to know what actions should be taken for the dimensions in the table. This is done by implementing an event handler.

Three situations where an inventory dimension field is added:

1. You do not want the data updated
2. You want the data updated and the table has the itemId on it
3. You want the data updated but the table does not have the itemId on it

In the below examples we will assume that we have added a table looking like this:

Handling situation 1 and 2

The below eventhandler illustrates how an eventhandler for situation 1 and 2 can be implemented. Here we want to update the dimensions related to the InventDimIdAllDimensions but not the dimensions in InventDimIdOnlyProductDimensions

[SubscribesTo(classStr(InventItemInventoryDimensionConversionTaskInitiator), delegateStr(InventItemInventoryDimensionConversionTaskInitiator, tableWithInventDimIdDiscoveredDelegate))]
    public static void tableWithInventDimIdDiscoveredStorageConversionDelegateHandler(
        TableId _updateTableTableId,
        FieldId _inventDimIdFieldId,
        InventItemInventoryDimensionConversionType _conversionType,
        EventHandlerResult _result)
    {
        if (_updateTableTableId == tableNum(MyOwnTableWithInventDimId))        {
            
            if (_inventDimIdFieldId == fieldNum(MyOwnTableWithInventDimId, InventDimIdAllDimensions))
            {
                InventItemInventoryDimensionConversionTaskCreator creator = InventItemInventoryDimensionConversionTaskCreator::newStorageConversion();
                creator.createTasksForTableWithItemId(
                    _updateTableTableId, //tableId of the table that should be updated
                    _inventDimIdFieldId, //fieldId of the inventDimId field that should be updated
                    fieldNum(MyOwnTableWithInventDimId, ItemId),  //fieldId of ItemId field
                    fieldNum(MyOwnTableWithInventDimId, DataAreaId)); //field id of DataAreaId
                _result.booleanResult(true); //we need to update
            }
            else if (_inventDimIdFieldId == fieldNum(MyOwnTableWithInventDimId, InventDimIdOnlyProductDimensions))
            {
                _result.booleanResult(false); //no update needed
            }
        }

Handling situation 3

Situation 3 is different since the itemId is on a different table. Here we need to write code specifically to the datamodel for the involved tables. The best approach is to follow the existing examples in the code. The InventBatchJournalResult table is a good example. This table is more complex because it has an InventDimId, but the itemId is on the inventBatchJournal table. The code below shows how this scenario is handled.

public class InventItemInventDimConversionInventBatchJournalLinePopulationTaskProcessor implements InventItemInventoryDimensionConversionITaskProcessor
{
    public boolean process(InventItemInventoryDimensionConversionTask _conversionTask)
    {
        var queryBuilder = InventItemInventoryDimensionChangePopulatorItemIdTableJoinedQueryBuilder::newFromParameters(
            _conversionTask.UpdateTableName,
            _conversionTask.InventDimIdFieldId,
            _conversionTask.DataAreaIdFieldId,
            tableStr(InventBatchJournal),
            fieldNum(InventBatchJournal, ItemId));

        InventItemInventoryDimensionChangePopulator::newFromQueryBuilder(queryBuilder).populateDimensionChanges();

        return true;
    }

}

Additional information

You can find more information as part of the product documentation:

https://docs.microsoft.com/en-us/dynamics365/unified-operations/supply-chain/warehousing/upgrade-migration-warehouse-management-processes

Introduction

This is another blog post in the series about warehouse mobile devices in Dynamics 365 for Finance and Operations. In the last blog post, the difference between customizing for WMDP and the warehouse mobile app was discussed. This blog post will be walking you through a new control scheme that was recently released, explaining how it unlocks new potential for partial offline processing in the warehouse mobile app.  This new functionality is called “multi-scan” and it enables a user to perform a series of offline scanning operations and then return them all to the server in one round trip operation. The goal for this control scheme is to allow for very quick scanning operations (many scans per second as an example) in high transactional warehouses where the standard model of a server round trip after each scan will not scale. Especially in sequential operations where the user does not need to look and verify on the device after each scan, but rather just need to register all scans in one go.

Multi-scan Functionality

If you download the latest version of the warehouse mobile app, you will have some new capabilities in the demo-mode which shows how this new control pattern works.  Once you have enabled the demo mode you should see the following menu:

Cycle counting is the flow we have enabled in the demo with multi-scanning to demonstrate the new capabilities.  It is designed to simulate a user performing a spot cycle count at a location in a warehouse or retail store where there are many items to scan. Currently this in only available in demo mode of the app, there is no support for this functionality when connected to a Dynamics 365 for Finance and Operations environment.

The first screen that is displayed is a location scanning screen – you can enter (or scan) anything in the demo mode here to move to the next screen.

Once you have scanned the location, the app enters the multi-scanning mode.  This is the new control that is being introduced in this release, so let’s go through the different UI elements that have been introduced to support this new flow.

This is the initial screen – you can tell it is the multi-scanning interface because of the new list icon in the bottom left corner; clicking the list icon will show you the list of items you have scanned so far. The checkbox icon in the bottom right is used to report to the app that you are done scanning and it is the only time the processing returns to Dynamics 365 – everything else will take place within the app locally on the device.

Once a worker starts to scan barcodes (or enter data manually into the app) the UI will change slightly.  Every item scanned will be added to an internal buffer and the number of items scanned will be displayed in the main UI.  For example – after a few scans the UI will now display the scanned count of three:

At any time, the user can click the list icon in the lower left, which will then display the list of items that have been scanned (in this example perhaps product barcodes in the location).  The UI for this looks like the following:

This lists the barcodes that have been scanned as well as a count of the times they have been scanned by the user.  This is very useful in the counting scenario, as a user can simply scan each product’s barcode to generate a count of items at that location.

You might note that there are two disabled buttons at the bottom of the screen.  These become active when a row is selected by the user in the list – as you can see below:

The edit icon on the left allows you to manually change the number of scans for the selected row. The icon on the right with the “X” deletes the selected row in case something was scanned accidentally.  

The edit icon will open a new screen with the numeric stepper UI allowing the user to quickly increment or decrement the number of scans or click on the value to open the numeric keyboard:

When clicking on the value, the numeric keyboard will open. As the number of barcodes cannot be negative, or integers, buttons that aren’t relevant for this use case has been disabled:

Returning to the main screen (by clicking the back button in the upper left corner) we are ready to submit the scanned list of items and their counts to the server. We do this by clicking the checkbox button in the bottom right – this is when we finally make the round-trip to the server and communicate with Dynamics 365. Later in the blog post the API will be explained and how to consume the scanned items and their quantities in X++ code.

In the demo flow, the next screen that is displayed is the following list of items which are not present in the location:

This is the second control pattern that we have introduced as part of this release – it allows a workflow to display a list of items (for example barcodes or product UPCs) and then allow the user to “scan to remove” from the list.  In this demo example we are displaying the items that were found in the cycle count but are not currently registered as on-hand for this location; the intention is that the warehouse worker would double check this list and scan any items that were indeed found as an extra validation check.  Scanning “T0001” in the above screen would then remove this from the list – and remember that this is all done client-side at this point. It is also possible to click on any value in the list and remove it.  Then when the user clicks that checkbox/submit button the new list of items would be submitted to the server for processing through a X++ workflow.

Custom Workflow

Hopefully that walkthrough gives you some idea of the capabilities we have added with these two new client-side control screens.  It is important to know that we have not currently added any multi-scan capabilities to the core product yet – the above cycle counting workflow is just a demo inside the app.  The goal of introducing these new control screens is to enable partners and customers to build new workflow-based solutions in the mobile app that support client-side driven scanning operations.  As such let’s walk through a simple customization example to show how the new control screens can be utilized in a real workflow.

Page Patterns

The way to enable the multi-scan screen is through a Page Pattern.  This might not be something you are aware of in the mobile app, as most of the time this is handled for you by the standard framework.  The Page Pattern is what tells the mobile app what type of UI to display on the device itself.  If you look at the WHSMobileAppPagePattern Enum you can see the different options available:

• Default
  • This is the page pattern used for 90% of the screens in the app. It displays a primary scanning UI and a set of controls in the secondary tab – of which a few can be promoted to the first screen.  An enter and cancel button and an optional set of additional buttons in the menu are supported.
• Custom
  • This Page Pattern is not used in many places in the core mobile flows – it is designed to allow partners to convert their old WMDP pages into the new model. Using this pattern will render the controls as it was done in WMDP  – each control simply vertically stacked in a single screen.
• Login
  • This is used for the initial login page.
• Menu
  • The Menu screens are rendered with this Page Pattern.
• Inquiry
  • This Page Pattern support the workflows that allow the user to search for something and then see the results – such as LP or Item lookup screens.
• InquiryWithNavigation
  • This is the Page Pattern that supports the Worklist view in the app. It is similar to the Inquiry pattern, except that includes some sorting options as well as the tiles are navigable.
• MultiScan
  • This is the new pattern that has been added which will display the multi-scan UI shown in the demo above.
• < MultiScanResult>
  • Note that as of the 8.1.1 release there is one missing and will be added in an upcoming release. If you want to enable a workflow to use the second screen described above – the “result list” of items, you would need to add a new Enum and return the value MultiScanResult. 

The actual job of returning the Page Pattern to the app is done through a class which derives from WHSMobileAppServiceXMLDecorator. This abstract class has a “requestedPattern” method that can be overridden to return the specific Page Pattern that is necessary.  This is typically done through a workflow-specific factory class that understands the correct workflow steps and thus can return the correct XMLDecorator class depending on the stage in the state machine.

For example – here is the standard factory class for the Work List functionality.  You can see that it typically will return the WHSMobileAppServiceXMLDecoratorWorkList object – which will render the work list Page Pattern as you would expect, however if the user has switched to the edit filter view then we need to display a different Page Pattern – thus the factory has the context to make this switch.

Multi-Scan API

Now that we know how to enable the Multi-Scan UI through a Page Pattern, we need to understand the basic API for passing the scanned items back and forth.  Once the MultiScan Page Pattern is requested, the first input control registered on the page will be used for the multi-scan input.  Remember that most of the UI interaction is all done client-side – so the only thing the server X++ code needs to do is define this control and the data that it contains.

When the user clicks that “submit” check box and sends the multi-scan data back to the X++ code, this is formatted in a very specific way.  The actual parsing of the data is done using the same interaction patterns as before – it will be stored in the result pass object for the specific control defined as the primary input of this page.  But the data will be passed in this format:

                         <scanned value>, <number of scans>|<scanned value>, <number of scans>|…

Thus, in my demo example above the data that the server would receive would be the following:

                         BC-001,2|BC-002,1|BC-003,1

In the X++ code you would then be responsible for parsing this string and storing the data in the necessary constructs.  We will see a simple example in a moment of how to parse this data.

Asset Scanning

The workflow I will demonstrate is very similar to some of the WHS workflow demos we have described in previous blog posts.  In this flow we will be scanning a container and then capturing all the “assets” that are stored in that container.  Imagine that these assets are very numerous and thus are stored outside of the standard batch tracking mechanisms in AX – they are implemented in the sample as a simple asset table associated with a container.  The assumption here is that scanning assets needs to be extremely quick and thus the offline “multi-scan” mode is the perfect solution.

The state machine for this workflow is similar to our previous examples – we will have an initial scan container screen, which will transition into the multi-scan enabled “Scan Assets” state – and finally when the list is returned we process the assets and return to the initial state. 

You can see this reflected in the core displayForm method below.  We will not be covering some of the lower-level details of the code – please review the earlier blog posts for details on the enums and control classes necessary to facilitate the new workflow.  All the code necessary for the solution can be downloaded at the end of the post if you want to dig into the details.

The getContainerStep is identical to our previous examples – it simply shows a simple UI and grabs the container ID from the user.  The getAssetStep method validates this container ID and calls the buildGetAssets method – which is where the UI for the multi-scan screen is built.  This is copied below:

As you can see this does not look much different that standard WHS code we have done previously.  The first input control (in this case the Asset ID field) will be used as the multi-scan field, but this code does not need to be modified in any way to support the multi-scan Page Pattern.  Instead what we need to do in ensure the correct Page Pattern is returned to the app during the correct workflow step.  To make this happen I have added a new DecoratorFactory class which will return a WHSMobileAppServiceXMLDecoratorMultiScan object at the appropriate step for my workflow – which in turn is what renders the Page Pattern to the app.

Please note the attribute at the top of this class – it is the same WHSWorkExecuteMode mapping attribute used for the WHSWorkExecuteDisplayAssetScan class in the code sample above.  This is how the framework knows that this specific decorator factory class is used for this work execute mode – the enum-based attribute ties these classes together through the sysExtension framework.  The key point here is that if you need a custom decorator factory to define when exactly to switch to multi-scan mode, the above example is how you will enable this.

In the final workflow step we need to process the incoming multi-scan results. As mentioned before these are returned to the server in the same way as normal data – it will simply look like a specially formatted string in the value of the input control.  Recall the discussion above with the format of the string being <scanned value>, <number of scans>|… In my simple example below, I am parsing this string using X++ and saving the assets to a new table associated with the Container.  In this case I am not making use of the second piece of information in the collection – the number of scans was not necessary in this case.

Hopefully it is clear how we loop through all the scanned assets and save each one to the new table.  After this is complete, we reset the workflow and move back to the first stage in the state machine.

Example Workflow

Now that you have seen the code to enable this in a custom workflow, let’s walk through this demo.  You can download the complete code for this project in the link at the bottom of this post – you just need to get it up and running on a dev environment and configure the necessary menu items to enable the workflow for your system.

The initial screen shows the Container ID scanning field.  Not that in the sample project I have included the necessary class to default this to the scanning mode – however you will need to set these up in Dynamics as defined here.

Scanning a container id (CONT-000000001 works if you are in USMF in the Contoso demo data) will navigate you to the next screen and enable the multi-scan Page Pattern.

Here you can enter any number of assets and the app will store them into the local buffer.  As we described above you can view the scanned assets by clicking the icon in the lower left.  After a few scans we would see the UI updated:

Clicking the list icon would show us the scans we have performed offline:

Finally clicking the “submit” button on the main screen will push the items to the server, which will then be saved to the custom table we have and the UI will display the success message.

Conclusion

Hopefully this help you understand the new control scheme that was added and how it can enable fast scanning operations.  The code used for this demo is available to download here – please note that this code is demonstration code only and should not be used in a production system without extensive testing.

The post Upcoming program for Business Applications ISVs appeared first on Microsoft Dynamics 365.

Organizations can automate repeatable sales activities and respond to external events by standardizing best practices using the Playbooks feature in Dynamics 365 for Sales. Playbooks can include guided actions and contextual sales materials that sales representatives need for closing deals and can be triggered manually or automatically based on entity record events.

Lets look at the basic expectations of sales managers and sales representatives.

Playbooks help your organization to meet the expectations of sales managers and sales reps and in driving sales efficiency, productivity, and consistent outcomes.Here are some scenarios where your organization could use playbooks:

• A sales representative working on an opportunity suddenly comes to know that the key decision maker and top champion of the product has left the organization in the middle of a deal. This event could possibly jeopardize the entire commercial transaction. With playbooks, automation can trigger a play that creates a set of tasks and activities needed to mitigate the situation. A task to reach out to current contacts at the customer account and identify the new stakeholder could be immediately followed by an introductory phone call to better understand the new stakeholders priorities. This carefully crafted orchestration of activities ensures that the new decision maker is successfully identified and turned into a new champion for the product so that the deal can be salvaged.
• A seller receives multiple leads from the marketing team, which they must follow up on. From experience, many of the leads turn out to not show any true interest and are a waste of the sellers time. With playbooks, organizations can automate the sequence of emails and activities to effectively communicate with the potential customer and only involve the seller when a connection is initiated.
• After closing an opportunity, there may be certain products, industries, or regions where the seller must provide some post-sale deployment support. Playbooks can help automate a set of defined tasks or activities that would help the customer get up and running, and potentially adopt the product or solution faster.
• Contract renewal is a key process that helps sales teams to boost their recurring revenue. Playbooks can provide a guided set of best practices when contracts are nearing renewal. These can be based on contract types, such as license, support, and maintenance agreements. You can configure tasks like checking any open customer issues and the latest NPS score as part of the information the playbook gathers to assist sellers in achieving their planned revenues.

Learn more about how to create and use playbooks, including links to step-by-step instructions, by going to Enforce best practices with playbooks.

How are playbooks different from business process flows?

While a playbook may seem like a business process flow conceptually, there are some fundamental differences between the two. Lets have a look.

Primary usage

Configuration / authoring

Runtime experience

Conclusion

Playbooks are a great way to automate repeatable processes and respond to events, thereby improving sales reps’ efficiency and productivity, and helping to ensure more consistent outcomes for your organization.

Dynamics 365 for Sales is making strong investments toward helping sellers automate their work and guiding them on their next best action. The Playbooks feature is the initial step in that direction. Stay tuned for future innovations from our product in this area!

The post Use playbooks for guided selling in Dynamics 356 for Sales appeared first on Microsoft Dynamics 365.