[Tutorial] Look up data in the Warehouse management app using detours

Idea and Feature introduction

All of you are familiar with the Ideas portal, and in the Supply Chain Management team we do everything we can to include the features requested there into our plans.

One feature in particular has been sitting there in the Warehouse management top 5 for quite a while

Drop down to select purchase order (and order line) when receiving via Mobile device

The problem described in the idea is that purchase order receiving flows currently require that you scan in the purchase order number and often you do not have that available for scanning. So the only option then is to print out the arrivals expected today, as well as the product receipt lists for all of them, and scan from paper during receiving. But now that I'm on the Microsoft Cloud for Sustainability team, we cannot really have you using so much paper just for this, can we? :)

One of the reasons why we have not implemented this in the product yet is, as many of you are well aware, extending the mobile device flows in X++ is quite complicated and cumbersome.

Now, the last feature that I created before departing for the Sustainability team was the Detours feature. If you've been living under a rock, you can read about it here: [Tutorial] Warehouse management app detours

Working on the detours and having in mind the above item from the Ideas portal inspired me to create the feature that I would like to describe in this post.

Demo of purchase receiving flow enhancements

I have configured three different detours for the PONum step for the Purchase receive menu item. This step in the purchase receiving flow is the one, where the worker needs to scan in the purchase order number, but now, we can now look it up instead.

Detours to look up POs

We can look it up by vendor, or see all POs that are arriving today, or we can look up the POs based on the items in them, which can be useful if we can scan the item directly from the package that we  just received, for example. Let's explore them one by one.

Lookup POs by vendor

The way I have configured this flow is that I will be asked to enter the vendor name and not the vendor account as the first step, because I wanted to show that wildcards are enabled for the filters. Image that I am expecting a couple packages today from a vendor called Tailspin something, I don't remember the full name, but I can type Tail* to keep it short, and will see all purchase orders based on my filters where the vendor name starts with Tail.

Lookup POs by vendor name (with wildcard)

Each card has a number of fields that convey necessary information about the purchase orders. I can see the vendor name is Tailspin Parts. That's the one I couldn't remember fully. 

Results of Lookup by Vendor

When I select one of cards, it will immediately go back to the main flow and populate the purchase order number for me based on the selection.

Selected PO is populated back in main flow

Lookup POs from today

The way I configured the Lookup POs from Today menu item does not require me to enter anything when invoked; just showing some of the pre-configured filters, and I can just proceed.

No entry needed in Lookup POs from Today

I can see two purchase orders are arriving today, one from Fabricam Electronics, one from Tailspin Parts with additional information about each of the orders that are expected. The list of fields displayed is different from the previous detour. I can select one of the orders, and it will be populated back into my main flow. 

Resulting view of POs from today

Lookup POs by item

This one allows to look up POs by order line item. I kept the setup simple here, just asking the user to scan in the item number. You can play around to figure out a way to use GS1 barcodes here too, I guess.

Filter screen for Lookup POs by item

When that's done, it will show the purchase orders that have an order line with such an item on it, that are expected for arrival after Jan 1st 2020. 

Results of Lookup POs by Item

I can see that I have one unit of item A0001 arriving in order 105 and 30 units of that item arriving on order 125. I would then select the corresponding purchase order based on the quantity of the items I see in front of me on the pallet.

Lookup items

Now that I have selected a purchase order, I am shown the next step to scan the item number. 

And again, the item number might not be available for scanning, which means I have a look up function for all the items on this purchase order configured as a detour.

Lookup PO items detour

When I select this detour, you can see that the purchase order number is pre populated from my main flow on the filter screen.

Filter screen with pasted in PO number value

Upon confirmation, I can see the two lines that I have on this purchase order for the different items with some additional information about each line.

Lookup PO line items results

I can select one of them, which will bring back the item number into the main flow, and upon confirmation, I can proceed with further receiving steps.

By now, I guess, you're catching on to the pattern of these lookup flows - you have 2 steps: in the first step you enter filters, and in the second step you see the data retrieved based on those filters. 

And the wonderful thing is - this is not limited to purchase receiving flow at all - you can configure pretty much whatever flow you like this way, without writing a single line of code. 

I don't know about you, but I think this is pretty awesome! :)

Configuring the mobile device menu items

OK, let's now look at how these menu items are configured, one by one, in same order.

Lookup POs by vendor

Lookup POs by vendor configuration

You can see it is a new mobile device menu item type, of Mode Indirect, where the Activity code is Data inquiry.

The only property that I need to specify on such a menu item is the Table name. This will be the base table for the query used to retrieve the data. You can use the lookup for it and search by both the table name and human readable label.

Once a table name is selected, the two buttons on the top right light up, Edit query and Field list. This should be familiar for anyone who has at least once configured a Work list menu item.

Query configuration

Edit query will allow you to define a query based on that base table selected, in our case it's the Purchase orders. 

Query configuration for Lookup POs by vendor

As you can see, I have configured that this particular menu item will be querying out open purchase orders that are expected to arrive anywhere after the 1st of January 2020. 

I have also explicitly added a filter based on Vendor name and left its value blank. 

I could also configure sorting for the query, for example ordering the data based on the delivery date in a descending order, similar to any other query editing window.

Field list configuration

Apart from the query, I also need to configure the fields that will be displayed on the cards in the inquiry list screen; 

Field list configuration for Lookup POs by vendor

This looks pretty much the same way it does for the Work list with the only difference being that no field is preconfigured like on the Work list, all of them are just free fields where I can select from the list of fields on that base table. Display field 1 is the one that will be used as the header for each card.

One additional thing that I have added and used a little bit different approach compared to the Work list is that I show the display methods in the same list together with the table fields, where you can tell that they are display methods based on the fact that they have the method syntax with the brackets at the end. 

Lookup for table fields and display methods

The label that is shown for display methods is the label of the Extended data type returned by these display methods.

Lookup POs from Today

Query configuration

If we look at purchase orders from today, I have configured in a similar way to return only open purchase orders that are expected to arrive today. I'm using the SysQueryRangeUtil syntax here. If you're not familiar with this, you can read more on the official docs site.

Query configuration for Lookup POs from Today

You can also notice that I do not have any other unpopulated filters, and if you remember back to the demo, I did not actually need to enter anything on step one on the filter screen, right? I could just proceed to the actual inquiry list step.

Field list configuration

Field list configuration for Lookup POs from Today

I have configured a number of PO fields to be displayed, and you can see that the first field is the purchase name, and the second field is the purchase ID. Purchase name will be used as the card header, but I can return any of these fields as information back from the detour. In this case I'm returning the purchase ID back to the main flow.

Lookup POs by item

By now you should be familiar with the process. The difference in Lookup POs by item obviously is that the table is Purchase lines. 

Query configuration

Query configuration for Lookup POs by Item

I'm looking at the lines from the purchase order, and I have configured an exists join to Purchase orders, because I wanted to still make sure that I'm only looking at open purchase orders that are expected after Jan 1st 2020, similar to the first flow.

I kept the filter on the Item number empty, so it shows up for the worker to enter on the device.

Field list configuration

The field list is pretty much the same as before, just a different set of fields.

This is where some customization might be required if you're lacking some of the information to display.

For example, if you want to show some special info about the purchase order or maybe even the vendor, you could add extensions with display methods to the corresponding table.

Lookup PO items

This flow also uses the Purchase order lines as its base table, as it's used to look up the purchase order lines for a particular purchase order. 

In terms of filters I went super simple and just added the PO number as a non-populated filter - the detour will populate this automatically when the detour is invoked.

I could of course make it more complicated and select certain lines only, for example only those that have WHS items on them. 

And the field list is pretty much same thing as before.

Lookup inventory

Lookup inventory flow

I've also configured an additional flow which is just a look up inventory flow. The base table is Items (InventTable) and the filter is just the Item number and then the field list is a couple of fields from the item. 

So it is that easy to configure just a random inquiry screen, if you want the workers to be able to look up some information from the mobile device. 

Note

In order for the worker to see the detour, they need to have access to it, which, similar to Work list, requires that he has the detour menu item somewhere in his assigned mobile device menu.

OK, so this is the mobile device menu items, and the only other thing that you need to configure after this is the mobile device menu items steps, to configure the actual detours. 

Configuring the detours in mobile app steps

Purchase receive - PONum

I have configured an override for the PONum step for the Purchase receive menu item, which is the step where we enter the purchase order number as part of receiving. I have added the 3 detours that you saw above.

Mobile device steps - PONum override for Purchase Receive menu item

And if I open the configuration for the fields to send to and from the detour (Select fields to send button), we can see the typical list of fields that are available in the purchase receiving flow, while for the detour it varies. 

Paste In fields for the data inquiry will display all filters from the corresponding query that are not populated. 

Copy From fields for the data inquiry will display all fields from the corresponding Field list configuration.

Note

In v1 this does not include display methods. This might be something that we extend in the future.

You can see in the screenshot that for all three flows I have not configured to send anything to the detour, but I have configured to send the purchase order number back.

Purchase receive - ItemId

Mobile device steps - ItemId override for Purchase receive menu item

If we look at the other detour that I have configured, which is the Purchase receive for the step Item ID, where I need to scan in the item, you can see that I have one detour, for looking up items, and I configured to send the purchase order number from the receiving flow into the detour, and then to send the Item number back from the detour.

One more thing - Detours that start from data inquiry list

One last thing that I wanted to show is that we now expose the generic data inquiry list step ID so you can configure this for creating detours from that inquiry screen.

Mobile device steps - GenericDataInquiryList override for Lookup POs by vendor menu item

You can see above, how I have configured an override for the Lookup POs by vendor inquiry flow.

The detour will invoke the purchase receiving flow and will pass in the selected purchase order number to the detour flow.

Note

You need to remember to regenerate the default setup for the mobile device steps, as well as the mobile app fields, for all of this to show up and work properly.

Demo

Let's see how this looks in the warehouse app.

If I start the Lookup POs by vendors inquiry flow directly from the menu, enter Tailspin Parts vendor name, I'll navigate to the screen showing 3 purchase orders - you can see the same above.

In the list, if I select and long press to invoke available detours, I will get a detour to do purchase receiving for the selected purchase order.

Available detours for Data Inquiry list

This is an alternative way of running the receiving flow - instead of doing a look up, you could start from an inquiry flow, and invoke a detour to do the desired flow.

Note 

Because this is a detour flow I do not have the ability to invoke more detours from here. So when I get to the item number entry screen I will not have the look up for the items available, as we only support one level of detours today.

The data model does support multi level, but that's not on our priority list right now, as far as I know. 

If that is something that you feel is super necessary, create an idea on the ideas portal and team will prioritize that accordingly.

Same for auto-confirmation of the filter step - it would take a bit longer to show the next screen from a user's standpoint, but would look much more smooth. Again, do log it on Ideas portal, if this is important for your workers.

Which version is this available in?

That's a good question. :) I don't know yet. 

If all goes well, 10.0.27. 

I'll update here, as we make progress on productizing the changes. 

Important

You will need to enable feature WHSMobileAppDetourGenericDataInquiryFeature when you do get the right version.

YouTube video

[Tutorial] Warehouse management app detours

Feature overview

Warehouse management app detours is a feature we have shipped recently, available as part of 10.0.23, which enables a warehouse worker to park a task they are currently executing, perform another mobile device operation, and then come back to exactly where they left off, once the detour is complete. 

This is feedback we have heard way too often from workers in the warehouse, saying they are afraid to navigate away from their current step for risk of losing their progress, the lock on the work they were performing, etc. 

The detours help reduce that fear, and, what is great about the feature, is that pretty much any mobile device menu item can serve as a detour in another mobile app flow.

Enable feature

Feature management

In order to enable the detours feature, you first need to enable the "Warehouse app step instructions" feature, both shown in the image above. This is what really drives the configuration options for detours, so that you can be flexible in where the various detours show up in a mobile flow.

In addition to enabling the feature, you should also make sure to regenerate the default setup / update the Warehouse app field names configuration, as we've significantly expanded the metadata associated with the fields (aka steps in a flow).

Configuring mobile device steps

You configure detours through the Mobile device steps screen. 

Mobile device steps

First, you need to identify the step in the flow where you would like to show a new detour menu item, and then add configuration for this step for a selected mobile device menu item.

In my examples today, I have decided to show detours on the "Scan a license plate" step as part of the Sales picking flow, as well as in the Item Inquiry screen from each of the cards. 

Adding specific step configuration allows to configure an alternative set of instructions for the user, in case they should be different from the default for the selected menu item, as well as choose (if you enable the corresponding feature) the information that should be prominently shown to the user in the details section, so they don't need to click into the details to view it. And, which is what we are going to do now, it allows to add one or more detours to this step. 

Detour configuration for Scan a License Plate step of Sales picking flow

Detour configuration for Item inquiry list screen

Above is how I have configured detours for Sales picking and Item inquiry flows.

Note

It's not just about invoking another flow. You can actually also pass information back and forth between the main flow and the detour. In the examples above, I'm passing in the Location from the main flow into the detours, and in the Location inquiry detour, I'm also passing back the license plate. Which allows me to select the license plate from a list instead of entering it manually, if I for some reason is not able to scan the value in at the location.

The options with detours are almost limitless, especially when you take custom flows into consideration. Some of the examples could be allowing to do an ad hoc movement of inventory from the receiving flow, or even from a picking flow, so that the worker can clean up the aisle to get past some block. You could do ad hoc replenishments, or perform counting on the spot, if you notice something is off while picking goods. I'd love to hear what you come up with in your warehouse!

Sales picking with location inquiry detour demo

To demonstrate how detours behave on the mobile device, I've created a simple sales order picking work order with 1 line, picking 10 pcs of A0001 from FL-001 location, which is license plate controlled.

After scanning in the work ID created above, we arrive at the step, where the worker needs to specify the license plate to pick from in location FL-001. 

Detour menu items visible for Scan a license plate step

You can clearly see which menu items are detours because of the additional icon (return arrow) shown above the main icon. This signals to the worker that when they are done with the detour, they will be returned to their current step in the current flow.

If we select Location inquiry, we are directed to the first step in the location inquiry flow, and you can see that Location is already pre-populated for us with the value coming from the sales picking flow. I can of course go and change the value to another location if needed.

First step in Location inquiry detour

After I confirm the location, I am presented with the list of license plates and products in the selected location. 

Location inquiry detour - list

Now, because I am in a detour, I can actually select one of the cards displayed, and when clicking back, the selected context is carried back to the main flow, including not only the card header (in this case, Item number), but all/most of the other related information. In this case, I'm interested in the license plate, which is how I have configured the detour above.

Note, also, that when selecting to go back, the first step (for scanning the location) is "skipped", and we go out all the way back to the main flow. 

License plate populated from detour

As you can see, the license plate was transferred back and I can simply go ahead and confirm the entry to proceed. Nice!

Item inquiry flow with spot counting detour demo

Now, I'd like to go into an item inquiry flow and view the on hand available for A0001. You can see I have four locations where this product is available. And let's say I actually want to re-count this location, as upon visual inspection something seems off (or maybe I noticed something fell and broke, for example). That is now possible with detours. 

All I need to do is long-press the card for the specific location I would like to count, and a list of available actions will pop up.

Detours available for BULK-001 card

Selecting one of the detours will pass the current card context into the detour, thus when the spot counting opens, for example, the location to count will already be pre-populated, as shown below:

Spot Counting detour with pre-populated value and step instructions

Note that the step instructions are also displayed, as this is the first time I open this particular flow. I can dismiss the instructions until next time, or for good by selecting the "Don't show again" check box.

In summary, not only do you have detours available in your typical page by page flows, but also on inquiry screens like location or item inquiry, providing even more flexibility.

And, I guess, it makes sense to explicitly call out that both ProcessGuide-based flows as well as WHSWorkExecuteDisplay-based flows are supported.

Want your feedback

Currently, when a detour is opened, we do not automatically confirm the value, even if it's populated based on the main flow. One of the reasons we discussed was that workers might get confused, expecting a particular and familiar step, but instead getting something else. Another is that it would be slower, as we'd still be going step by step on the backend, so the worker might perceive a longer wait time for the detour screen.

I'd like to ask for feedback on this!

• What detours do you find relevant for your business? 
• Do workers find it convenient?
• Is an auto-submit feature necessary?

Leave comments here, in the below Youtube video, or reach out directly!

YouTube video

[Announcement] Warehouse App task validation framework (RSAT for WMA) now available on Tier 2 environments

Refresher

In a recent post, I talked about testing, using the ATL framework to write easy-to-read test automation. 

This is a developer activity recommended for ISVs and partners, to ensure their customizations against regressions. 

At a customer site, if a developer team is unavailable, or for testing E2E scenarios in the system, Microsoft recommends using the RSAT tool. You can see a quick summary of those recommendations in the below picture:

Test classification pyramid

RSAT is well suited for recording and replaying tests that use the web client of Dynamics 365 SCM.

As such, it was not providing much support when it came to validating scenarios, that required the use of the Warehouse management mobile app.

To fill that gap we had shipped the RSAT for WMA a while back, officially called "Warehouse App Task Validation Framework". If you are not familiar with its capabilities and use cases, please watch the corresponding Tech Talk to familiarize yourselves.

Problem statement

This framework with the initial release was only supporting Tier 1 environments (like, DevBoxes). 

This was not ideal, as many customers wanted to run their RSAT validation on Sandbox ("perform") environments to replicate real production performance and behavior more closely. 

Also, with more and more customers being moved to Self-Service environments, they lose easy access to free Tier 1 environments.

Announcement

Starting with Dynamics 365 SCM version 10.0.19 the Warehouse App Task Validator is now supported on Tier 2 environments! 

Configuration

All you need to do to start capturing of the warehouse mobile device operations as part of RSAT is to enable this under Warehouse management parameters, as shown below:

Enable RSAT support for WMA on Tier 2 environments

You can now navigate to the Warehouse app task validation page (under Warehouse management \ Periodic Tasks) and start creating validation scripts.

Word of caution

As stated in the help text for the configuration flag, do NOT enable this on a PROD environment, as it carries a significant overhead for each operation. 

Request for ideas

The current user experience with RSAT for WMA is OK, but not great. A lot of people are timid when presented with the large XMLs.

If you have ideas on how to improve the user experience in RSAT for WMA, let us know!

[Tutorial] Find your Device ID and Warehouse management app version

Introduction

The two basic things support needs any time you log a support case is your application version, as well as your session id or similar, plus the timestamp of when the issue occurred. This helps troubleshoot the specific issue reported.

Well, with the Warehouse management app, it's pretty much the same. We'd like to know the app version you're running, as well as the Device ID of the device where the issue happened, plus the timestamp of the issue.

In this post I'll describe how to retrieve these two pieces of information, as this is not as obvious as we would hope.

Modern app

Step by step guide to find app version and Device Id

New version released

I would also like everyone to know, that we have this past week shipped the new version of the app, version 2.0.5.0. Here is the change log for this version:

## 2.0.5.0

## Fixed issues:

- Submit button incorrectly enables depending on window size.

- Slider can't proceed on smaller screens when button size is larger.

- Four button overly being cut.

- Keyboard does not support delete button.

- Brightness issue when keyboard pressed.

- Various demo data issues.

- Details page issue for numeric fields.

- Disappearing on screen keyboard on some devices.

- Various UI bugs including background color, positioning, etc.

- Improved UI with Russian language.

- Fixed various crashes.

- Calculator re-opening problem.

- [Android] Android 4.4 crash on start-up.

- Client secret not hidden in connection settings setup.

##New Features:

- Long press any text to see it fully.

- [Android] Reduced minimum scaling to 50%.

- Improved error message when missing storage permission.

- New control sequences on certain flows.

Black and Green app

Step by step guide to find app version and Device Id

YouTube

[Development tutorial] Thoughts on test automation + more sample tests using ATL

I recently had an interesting discussion around testing and specifically Microsoft testing efforts and frameworks, namely, ATL. If you are not familiar with this framework - you've been living under a rock. Get out from under there and go read some articles about it, like the one below

https://kashperuk.blogspot.com/2019/05/development-tutorial-sample-test-tips.html

The discussion revolved around the complexity and costs of adding and maintaining tests. The partner also questioned how often we add tests, and if we can share more samples of such. You can also see his comment with a more concrete ask in the blog post above. 

Here's a partial quote:

Partners need more example for this functionality usage. Is it possible that you provide real tests for some real issues (I just took several bugs from the latest PU Warehouse and Transportation Management)

533573 Creating a sales order’s work without a pick location is not updating the on-hand figures correctly.

535311 Cannot do material consumption from mobile device for shelf life items

536899 The container contents report does not show an error if shipment does not have a dropoff address specified

537772 Cluster profile could not be found please check your configuration Error is blocking Purchase Order Receiving

If you share them in a new blog post as examples that will be a great discussion point

So in this post, I'd like to share 2 things:

1. Generally speaking, we at Microsoft, or rather, more specifically, we in the Warehouse management team, add one or more tests for every single customer reported issue. 

This obviously adds a cost to each bug fix we do, but with this we get a much more reliable release schedule and on-going confidence in our product offering, and have very few regressions despite heavy code churn.

The point I want to make here is - if you are an ISV, and you have not covered your solution with test automation, you should do it now, and reap the benefits. 

If you are a partner getting paid by the hour doing a specific customer implementation, it gets more tricky. However, I believe (I know) it is in your and your customer's interest to justify the cost of adding test automation.

Very frequently today, even with some of our larger customers, we hear test cycles of 1-2 months before taking a newer standard release. That puts a significant on-going cost on the customer, as well as stress, as we at Microsoft keep pushing everyone to be current. This could have been mostly alleviated with test automation

ATL is a framework which allows to write robust (and reasonably fast) test automation with a low cost investment, all things considered. 

2. We do not ship our test automation library. The code is not written with shipping in mind, so it's not necessarily "Microsoft production quality". The value for customers is also marginal. 

But, to answer the ask from the quote above directly, here are the tests added for the 4 issues listed. I did not include the class/test setup logic, nor did I verify these tests are able to run on your specific dataset (internally we have tests that are both dataset dependent and independent). So take them for what they are - mere samples that prove the point - all of these are rather easy to understand when reading, and are rather easy to write, if you know the scenario you want to automate. For all or most of the standard functionality there are already ATL "wrappers" ready to be used.

• 533573 Creating a sales order’s work without a pick location is not updating the on-hand figures correctly.

	[SysTestCheckInTest]
    public void soRelease_StopWorkOnLocDirFailureFalse_onHandCorrectWorkCompleted()
    {
		// Given
        const InventQty QtyOnReceiptLocation = 100;
        const InventQty SalesQuantity = 1;

        ttsbegin;

        var locDirFailure = whs.locationDirectiveFailures().sales();
        locDirFailure.LocDirFailWork = NoYes::No;
        locDirFailure.update();

        var locProfile = whs.locationProfiles().receipt();
        locProfile.setLPControlled(false).save();

        var receiptLocation = whs.locations(warehouse).create(locProfile);

        // Delete existing sales pick location directive to ensure no impact to the one created.
        var locDir = AtlEntityWHSLocationDirective::find('24 SO Pick', WHSWorkType::Pick, WHSWorkTransType::Sales, warehouse);
        locDir.delete();

        whs.locationDirectives().salesPick().setLocationRange(pickLocation).moveToTop();

        onhand.adjust().forItem(item).forInventDims([receiptLocation]).addOnHandQty(QtyOnReceiptLocation);

        salesOrder.addLine().setItem(item).setInventDims([warehouse]).setQuantity(SalesQuantity).setAutoReservation().save();
        ttscommit;

		// When
        salesOrder.releaseToWarehouse();

		// Then
        var work = salesOrder.work().singleEntity();

        work.lines().withTypePick().withLocationId('').assertSingle();
		
        invent.trans().query().forItem(item).forReferenceCategory(InventTransType::WHSWork)
			.forReferenceId(work.parmWorkId()).assertCount(0);

		onHand.assertExpectedOnHand(
            onHand.spec().forItem(item).withInventDims([warehouse]).withAvailTotal(QtyOnReceiptLocation - SalesQuantity));

        var soPicking = rf.login().salesOrderPicking()
			.setWork(work)
            .setLocation(receiptLocation);

        invent.trans().query().forItem(item).forReferenceCategory(InventTransType::WHSWork)
            .forReferenceId(work.parmWorkId()).withStatusIssue(StatusIssue::ReservPhysical).assertSingle();
        invent.trans().query().forItem(item).forReferenceCategory(InventTransType::WHSWork)
            .forReferenceId(work.parmWorkId()).withStatusReceipt(StatusReceipt::Ordered).assertSingle();

        soPicking
			.confirmPick()
			.confirmPut()
			.assertWorkCompleted();
    }  
  

• 535311 Cannot do material consumption from mobile device for shelf life items

      [SysTestCheckInTest,
        SysTestCaseAutomaticNumberSequences,
        SysTestFeatureDependency(classStr(WHSProdMaterialConsumptionJournalBOMBatchExpiryDateFeature), true)]
    public void materialConsumption_BatchIsExpiredBySchedDate_JournalLinesCreated()
    {
        const Qty BomLineQty = 1;
        const Qty ProductionOrderQty = 1;

        ttsbegin;

        // Given

        InventModelGroup fefoGroup = invent.modelGroups().fefoWithExpiryCriteriaBuilder().save().record();
        fefoGroup.PickingListBatchExpirationDateValidationRule = WHSPickingListBatchExpirationDateValidation::ReservationDate;
        fefoGroup.update();

        InventTable rawMaterial = items.whsBatchAboveBuilder()
            .setItemModelGroup(fefoGroup)
            .setPdsShelfLife(PdsShelfLife)
            .create();

        InventBatch validBatch = invent.batches().create(rawMaterial);
        validBatch.setExpiryDate(DateTimeUtil::getToday(DateTimeUtil::getUserPreferredTimeZone()) + PdsShelfLife).save();

        onhand.adjust().forItem(rawMaterial).forInventDims([floor, lp1, validBatch]).addOnHandQty(RMItemQty);

        InventTable finishedGood = items.whsBatchBelowBuilder()
            .setItemModelGroup(fefoGroup)
            .setPdsShelfLife(PdsShelfLife)
            .create();

        AtlEntityBillOfMaterials billOfMaterials = this.createBOMAndBOMVersion(rawMaterial, BomLineQty, finishedGood);
        AtlEntityProductionOrder productionOrder = this.createProductionOrder(finishedGood, billOfMaterials, ProdReservation::None, ProductionOrderQty);
        productionOrder.estimate().execute();
        
        productionOrder.scheduleOperation().setSchedDirection(ProdSchedDirection::ForwardFromSchedDate).setFiniteCapacity(false)
            .setFiniteMaterial(false).setSchedDate(DateTimeUtil::getToday(DateTimeUtil::getUserPreferredTimeZone()) + PdsShelfLife + PdsShelfLife).execute();

        productionOrder.start().setAutoBOMConsumption(BOMAutoConsump::Never)
            .setPostPickingList(false).execute();

        ttscommit;

        AtlWhsWorkExecuteProdMaterialConsumption materialConsumption = this.createMaterialConsumptionWithBatch(productionOrder, floor, rawMaterial, validBatch);
        
        materialConsumption.setQuantityToConsume(ProductionOrderQty);

        // When and Then
        materialConsumption.assertMessageOnClickOk("@WAX:MaterialConsumptionJournalLineCreated");

        materialConsumption.assertMessageOnDone(
            strFmt(
                "@WAX:MaterialConsumptionJournalPosted",
                productionOrder.pickingLists().withJournalType(ProdJournalType::Picklist).singleEntity().parmJournalId()));
    }
  

• 536899 The container contents report does not show an error if shipment does not have a dropoff address specified (Not using ATL, as this was an old existing test. More than 1 test was added / modified here)

      [SysTestCheckInTest]
    public void preRunValidate()
    {
        // arrange
        InventSiteLogisticsLocation inventSiteLogisticsLocation;
        delete_from inventSiteLogisticsLocation;

        Args args = new Args(formStr(WHSContainerTable));
        FormRun formRun = classfactory.formRunClass(args);
        formRun.init();

        FormDataSource containerTableDS = formRun.dataSource(tableStr(WHSContainerTable));
        containerTableDS.executeQuery();
        containerTableDS.markRecord(containerTable, true);

        args = new Args();
        args.caller(formRun);
        args.record(containerTable);

        WHSContainerContentsControllerTestable controller = new WHSContainerContentsControllerTestable();
        controller.parmArgs(args);

        Query query = new Query(queryStr(WHSContainerContents));
        controller.setRanges(query);

        Map queryContract = new Map(Types::String,Types::Class);
        queryContract.insert('Query',query);

        SrsReportDataContract srsReportDataContract = new SrsReportDataContract();
        srsReportDataContract.parmQueryContracts(queryContract);
        controller.parmReportContract(srsReportDataContract);

        // act
        container validateResults = controller.preRunValidate();

        // assert
        this.assertEquals(validateResults, [SrsReportPreRunState::Error, "@WAX:WHSContainerContentsReportMissingPrimaryAddress"], 'Unexpected value in validateResults.');
    }
  

• 537772 Cluster profile could not be found please check your configuration Error is blocking Purchase Order Receiving

      [SysTestCheckInTest]
    public void poReceive_QualityOrderAndAssignClusterEnabled_WorkAssignedToCluster()
    {
        const Qty PurchOrderQuantity = 2;
        ttsbegin;
        // Given
        whs.warehouses().ensureQualityManagementEnabled(warehouse);
        invent.qualityOrders().ensureCanCreate();
        whs.locationDirectives().qualityItemSampling(whs.locations(warehouse).stage().wMSLocationId, warehouse);
        whs.workTemplates().qualityItemSampling();
        invent.qualityAssociations().defaultBuilder()
            .setOrderType(InventTestReferenceType::Purch)
            .setApplicableWarehouseType(WHSApplicableWarehouseType::QualityManagementOnlyEnabled)
            .setItemRelation(whsItem.ItemId)
            .setSiteId(warehouse.InventSiteId)
            .setDocumentType(InventTestDocumentStatus::Registration)
            .setShowInfo(NoYes::Yes)
            .setAcceptableQualityLevel(100)
            .setQualityProcessingPolicy(WHSQualityProcessingPolicy::CreateQualityOrder)
            .setItemSampling(invent.itemSamplings().onePiece())
            .getResult();
        clusterProfile = whs.clusterProfiles()
            .putawayClusterManualAssignAtReceipt(WHSWorkTransType::Purch, whs.workTemplates().purchaseReceipt().parmWorkTemplateCode());
        ttscommit;
            
        this.addPurchaseOrderLine(whsItem, PurchOrderQuantity);

        // When
        var poItemRecv = rf.login().purchaseOrderItemReceiving()
            .setPurchaseOrder(purchOrder)
            .setItem(whsItem)
            .setQuantity(PurchOrderQuantity);

        AtlQueryWHSWork workQuery = purchOrder.work().withClusterProfileId(clusterProfile.parmProfileId());
                
        // Then
        poItemRecv.assertErrorOnConfirmUnitSelectionWithWorkQuery(workQuery, clusterProfile.parmProfileId(), 'Wrong message');
        invent.qualityOrders().query().forPurchaseOrder(purchOrder.record()).assertCount(1, 'Should have 1 quality order');
    }
  

Hope this helps. Do reach out to us with feedback / suggestions.

Do make use of CDE (Community Driven Engineering) to submit additions / bug fixes. We do expect ATL tests with those fixes.

[Development tutorial] Extending the work list and work pick line overview flow fields

 Introduction

Whenever we talk about the work list, and recently also the work pick line overview feature, customers think this could be a great optimization for their warehouse, but frequently, they want to display some business-specific information on the cards, that would help drive the decisions, but that information is not available out of the box on the work list.

In this post I'd like to cover the simple steps needed for extending the out of the box functionality, adding fields displayed on the work list / work pick line overview. This in turn automatically means you get sorting capabilities on these fields on the mobile device, enabling faster navigation.

If you are not familiar with these features, I'd like to refer you to the following links:

• Work list feature
• Work pick line overview feature

Customization walkthrough

For this demo, I've made the following extensions (in a new model/package):

• Added a new string field, MyOwnField, to WHSWorkTable.
• I also extended the form to display this field, so a user can modify it for an existing work order
• Added a new display method, requiresForklift, to WHSWorkTable. 
• This is a common requirement we hear from customers - being able to quickly identify if special equipment is required for performing a work order.
• Note. I use a string as a return type instead of an enum, as the base logic does not handle enums "the right way" for display methods, thus presenting their integer representation on the mobile device, instead of the corresponding label.
• I also needed to extend the populateWorkDisplayMethods method on table WHSTmpFieldName, so my newly added display method shows up in the list, when configuring the mobile device menu item.
• Added a new integer field, MyOwnField, to WHSWorkLine.
• Added a new display method, crushabilityWeightPerUnit, to WHSWorkLine
• This allows to stack the items on the pallet (Target LP) so that the top layers do not crush the bottom ones.
• No need to modify the lookup logic here for configuration, as it's already generic.

All of my implementations are super simple, just to demonstrate the concepts and the process. You can download the full code on GitHub.

Alternatively, watch the below YouTube video, where I walk through each customization in detail.

Result screenshots

After making, building and synchronizing those changes, I can open the mobile device and would have the following view. (I won't go over the demo data setup here)

Work list, sorted to show work that needs a forklift first. My field is also populated for some orders:

Work list with custom fields

Work pick line overview, ordered to show the items that should be placed on the bottom of the pallet first:

Work pick line overview

Question to you

What type of information are you using on the work list / work pick line overview?

Should it be available out of the box?

Let us know!

Thanks

[Tutorial] Work pick line overview

Introduction

Work pick line overview is a feature that is currently in Public preview, and will become generally available in one of the upcoming Dynamics 365 SCM releases.

It provides the flexibility to experienced warehouse workers to change the work picking route on the spot, based on the current situation the system is unaware of. 

For example:

• some of the goods on the order might need to be rushed out the door, to make the delivery truck departure time
• system is not configured to suggest an optimal picking route that takes into account item dimensions, weight, etc.
• worker is inhibited in some way, for example, cannot carry larger items right now, so would like to pick the smaller ones first, and then come back for the larger ones with a forklift, etc.

Using the work pick line overview feature, the worker can get all of the work lines to show up in a list on the mobile device, allowing the worker to order them based on the data displayed. This way, he can quickly choose the work line that he will pick next. 

This is a lot more convenient compared to the existing Skip button functionality, where the worker could skip one line after another until he reaches the one he would like to pick next.

Configuration

As I mentioned, the feature is in Public Preview as of writing this post, so you need to first enable it through the Feature management dashboard, as shown below:

Work pick line overview feature

Enabling the feature adds a new option to the Mobile device menu items of type "Work - use existing work", like shown below. 

Mobile device menu item configuration

The 4 options available for selection in the Show work list list option are described nicely in our article about the feature on docs.microsoft.com:

• Show only upon request – Workers can choose to view the pick line list by selecting the Skip to button in the warehouse app.
• Show at the start of every pick – Workers see the list every time that they start or finish a pick line. They can also view the list again by selecting the Skip to button in the warehouse app.
• Show at the start of the first pick only – Workers see the list every time that they start new picking work, but not after each line. They can also view the list again by selecting the Skip to button in the warehouse app.
• Never show – The standard Skip button appears in the warehouse app, and display of the work line list is turned off. The Skip button lets workers cycle through the lines one at a time, in a fixed order. They can also cycle through the list as many times as they require, until all lines have been processed.

Selecting one of these options also make the Field list configuration button available. In the form that opens the superuser can configure the work list fields that should be visible on the mobile device. 

Note You can configure to display not only table fields, but also display methods, allowing for a much more flexible setup

Work pick line overview field list configuration

Demo

To demonstrate, how the work pick line overview can be used, I've create a small sales order with 4 lines, as shown below:

Sales order lines

Upon releasing this order to the warehouse, the following work order was created:

Work order lines

Using the new Warehouse management app (you can read more about it in my previous post), we can now navigate to this work order, using the newly created mobile device menu item, as shown below:

Work picking flow, step 1

In my example, I have configured not to trigger the pick line overview to appear automatically, meaning that the worker would need to manually select the Skip to button from the ribbon

Select Skip to button in the ribbon

This will bring up the work pick line overview screen, where the worker can see all the work lines in one or more columns, depending on the device form factor. 
All the selected fields and their respective values are shown on the cards, and tapping either of them will take the worker to start performing the pick actions for that work line.

Work pick line overview

To speed up the selection process, especially in cases where many work lines are displayed at the same time, the worker can use the ordering options available above the cards, for example, to show the heaviest items first, as shown below.

The ordering selections will also be preserved for whenever the pick line overview is opened next time, simplifying the picking process further.

Work pick line overview showing heavy item first

Demo recording

If you prefer watching demos with voice-over over reading, please check out the YouTube video I made for this feature:

View on YouTube

Conclusion

As you can hopefully see by now, the Work pick line overview is a powerful feature than can help your business find further cost reductions in the warehouse by allowing more flexibility on the floor.

We love feedback, so don't be shy and let us know if you have issues with the feature, or have further ideas on how this can be improved!