Birger Larsen – AX / Dynamics 365 blog on WMS

WMS, Distribution, Logistics, Birger, Larsen, AX, 2012, WAX, TRAX, Dynamics 365

Vendor Managed Inventory with Powerapps and electronic reporting — May 5, 2020

Vendor Managed Inventory with Powerapps and electronic reporting

Dynamics 365 for Finance and Operations (D365FO) has basic support for Vendor Managed Inventory (VMI) in the form of Consignment replenishment orders.

From a warehouse perspective, there are however some serious limitations to consignment replenishment orders. In this post I discuss how you can overcome some of these limitations using Powerapps and Electronic Reporting.

VMI warehouse limitations

The main problem with consignment replenishment orders is that VMI items can only be received in non-warehouse management enabled warehouses. That’s a problem – because it forces you to have all your “normal” items in one (warehouse management enabled) warehouse and your VMI items in a separate non-warehouse management enabled warehouse.

This has serious implications for all processes where you would want to use your VMI items, including replenishment, raw material pick, sales order picking etc. All your normal scanner supported warehouse processes will simply not work with VMI items.

VMI replenishment pain points

In my company, a significant part of the raw materials on production sites are sourced as VMI items. So the primary warehouse process “suffering” from VMI items is the replenishment process to the production staging area.

The fact that VMI items must be kept in a non-warehouse-management enabled warehouse leads to the following two pain points:

  1. Zone replenishment can not be used to trigger and calculate the replenishment of production staging ares
  2. The actual picking of the VMI items can not be done using scanners, but must be done by entering inventory ownership change journal and subsequent transfer journal

On the site I’m currently working on, we have 3 production buildings that are regularly replenished from the same VMI area. Zone min/max replenishment would therefore have been the right thing for us, because each of the 3 production buildings are separate zones with individual min/max thresholds.

We ended up solving the first paint point with an Electronic Reporting based workaround that simulates zone replenishment. But in this post I will focus on the second pain point – not being able to pick VMI items with scanners.

VMI replenishment using Powerapps

The production site i’m currently working on, went live on D365FO early April 2020. The users quickly found the standard replenishment process for VMI items in D365FO to be very cumbersome.

This image has an empty alt attribute; its file name is standard-process.jpg

First they had to pick the items physically from the VMI area. Then they had to go back to a PC and register each combination of item/batch in the inventory change ownership journal. Then they also had to re-enter the exact same item/batch combinations in a transfer journal to get the items moved from the VMI warehouse to a trolley location in the main warehouse. So a typical replenishment trip could result in manual entering of 100-150 journal lines.

Apart from taking a lot of time – the manual entering of journal lines is also more likely to result in registration error.

We discussed a number of alternatives and ended up with a workaround based on a Powerapp and electronic reporting.

This image has an empty alt attribute; its file name is image-33.png

The Powerapp allows the worker to scan the items while picking them from the VMI locations. The Powerapp creates a Transfer order from the VMI warehouse to the main warehouse. The transfer order contains the items/batches scanned by the worker.

Electronic reporting is then used to generate the inventory ownership change journal.

Optimized VMI replenishment process

So the Powerapp will intially display a Transfer order header screen where From/To warehouse is displayed and the transfer order number is generated automatically. The user will basically just accept the proposed values by clicking the undefinedsign.

This will result in the creation of the Transfer order header in D365FO.

Next a pick screen is displayed with a white scan field at the top. In here the user scans location, item and batch barcodes.

The Powerapp will then automatically update the related fields with the scanned values. After scanning the user will click on the Quantity field and a numeric keyboard will be displayed on the scanner. The user enters the picked quantity.

When done the user will click on the undefined sign. This will result in the creation of a Transfer order line with the scanned item/batch/quantity.

The Powerapp will then present an empty pick screen again and the user will continue to scan next item/batch.

When all items have been scanned the user will click on the X sign and the Powerapp will display a complete list of the scanned items.

The user can then choose to edit/delete records before finalizing the picking using the standard canvas Powerapps user interface.

When done a transfer order has been created in D365FO with the scanned items.

Before the transfer order can be posted, an inventory ownership change journal must be generated and posted for each of the items in the transfer order. This part is handled by electronic reporting (more details on that in a follow-up post).

When the transfer order is posted – then the items are moved from the VMI warehouse to the main warehouse to a Trolley location where they will stay until they are putaway to the production staging locations in the production buildings.

How to create the Powerapp

I started by creating a canvas Powerapp based on the TransferOrderLines data entity:

This image has an empty alt attribute; its file name is image-3.png
This image has an empty alt attribute; its file name is image-4.png
This image has an empty alt attribute; its file name is image-6.png
This image has an empty alt attribute; its file name is image-8.png
This image has an empty alt attribute; its file name is image-12.png

This will give you a very “raw” app – like you can see below. But it will contain all the basic navigation to be able to create and edit transfer order lines.

I decided to change the theme to a black and green theme to give a somewhat similar experience as the “normal” warehouse app.

Next I adjusted which fields should be displayed and the field order on each screen.

Adding Transfer order header screen

Before adding transfer order lines you must be able to create a Transfer order header. To be able to do this, a Transfer order header screen was created like this:

The sign in the Transfer order header form was modified to open the Transfer order line creation form upon successful creation of the Transfer order header.

Calculating the Transfer number

One of the biggest challenges turned out to be the calculation of the Transfer order number. I did not manage to subtract a new number in the Transfer order number series. Instead I adjusted the number series in D365FO to allow manual override, to be able to calculate the new number series number manually:

A minimum transfer order number was defined as a global variable. This minimum number was set well above the normal Transfer order number series to avoid conflicts with transfer orders created from within D365.

The Transfer number was then calculated as the currently highest Transfer number + 1:

Receiving location main warehouse

Another challenge is to control which locations the items are received in your main warehouse. In our production site we do not receive items using WHS scanners. Items are received using Arrival overview journal. I was therefore able to specify my trolley location as the main receiving location in my main warehouse.

But if you are receiving your items using whs scanners – then you can not solve it like this. Then you can control the receiving location by setting the standard receive location on each VMI item like this:

Wrap up

So half of the VMI replenishment problem has now been “worked-around”. The workers are now able to scan items during replenishment picking using the Powerapp. The Powerapp creates a Transfer order that will move items from the VMI warehouse to a Trolley location in the main warehouse.

What’s still missing is the creation of the inventory ownership change journal. Because there is no data entity for that in D365FO, the powerapp can not create these journal lines. This can however be “worked-around” using Electronic reporting. I will get into more details on that in part II of this little blog series on Vendor managed inventory replenishment.

Until then – feel free to have a look at my example Powerapp here.

Eliminating gaps with Configurable business documents — February 12, 2020

Eliminating gaps with Configurable business documents

In this post I look into how configurable business documents can be used to fulfill many document requirements, that has previously been considered gaps in D365FO. These gaps can now be eliminated by configuring… the configurable business documents.

The obvious use of configurable business documents is to adjust the layout of all the predefined business documents like order confirmation, invoice, picking list, etc. Read more about that here and here.

Create new document types

But configurable business documents can also be tweaked to create entirely new document types and trigger them from relevant places in the business process.

As an example I will demonstrate how you can setup configurable business documents to generate a proforma invoice from a Transfer order – something that’s not possible without configurable business documents.

But why would you need a proforma invoice for a transfer order? Well – in my company, we regularly move items between warehouses, that are located in different continents of the world, but still owned by the same legal entity. Technically this is handled as a Transfer order in D365FO between two warehouses. The problem is that the movement across continents requires a commercial invoice type document for customs purposes.

D365FO actually have a commercial invoice and also a proforma invoice – which could both be used for this purpose. But unfortunately they are tied to a sales order transaction and not a transfer order transaction.

Fortunately we can use configurable business documents to create proforma invoice and trigger it from a Transfer order.

Generating a Transfer order proforma invoice

Before I go into details on how to configure a Transfer order proforma invoice – I would like to show you the finished result first.

So I have a normal Transfer order. The transfer order has been picked in the warehouse and also packed in several containers. To generate the Transfer order invoice I click on Load details to open the related load.

In the loads form I activate the Load list report. The load list report is normally a report that contains strictly load related information. But by changing configuration i have “injected” a Transfer order proforma invoice document instead.

So instead of printing a normal load list report – a proforma invoice is now printed – based on the information on the transfer order and a lot of other derived information – including sales prices from trade agreements and packing information from warehouse containers and more.

Trigger proforma invoice instead of load list report

So I have created a completely new data model, model mapping and excel report for the Transfer order proforma invoice in the electronic reporting configurations form (see below). Together they contain the configuration required to print a Transfer order proforma invoice. I will get into some details about them later in the post.

But for now I just want to focus on how you can get your own report triggered from the load list report menu item. The way to achieve that is to the add the same tag types as for the load list:

When you do that, your own electronic report configuration suddenly becomes available the print document setup

Transfer load information to the report

A challenge I had, was to get load id and other information transferred from the load (where I click the load list report menu item) to the report – and thereby allowing me to lookup related information in the transfer order table, prices etc.

I solved it by looking at Load list report data model. I “stole” the setup below – and then found that I had access to the load id and all other fields on the load.

Extracting price and container information

An important element on the proforma invoice are the sales prices. Unfortunately transfer orders do not contain any prices. To solve that I lookup the sales prices in trade agreements with the load line item as input.

This is possible in the data model mapping formula designer using SQL like formulas. The nice thing here is that you can lookup data directly in tables – no data entities are required.

Similarly container information like container id, weight and volume is looked up by searching for all containers with same shipment id as on the load.

There are quite a few other details I could talk about – but it would make a very long post. Instead you are welcome to download some example configuration files and perhaps get inspired ūüôā

Configurable warehouse business documents – part 2 — January 6, 2020

Configurable warehouse business documents – part 2

In my previous post Configurable warehouse business documents, I examined if the warehouse pick list layout in D365FO could be configured by superusers and consultants without the need for developer assistance. Using the new configurable business documents (CBD hereafter) framework I was able to remove irrelevant information like load/order barcodes and the print work step.

First try at configuring CBD pick list – load/order barcodes and print step removed

In this post I will examine how new information can be added to the pick list (and other CBD documents). To illustrate the process, I will be adding the sales pool field from the sales order to the pick list.

The sales pool field can be used to group sales orders into logical order pools, like normal orders, express orders etc. and can provide extra context to the warehouse worker performing pick/pack/ship operations.

This is the second of three posts on configurable business documents. Click here to open first post: Configurable warehouse business documents. Click here to open the third post: Eliminating gaps with Configurable business documents

Basic CBD / electronic reporting concepts

Before going into details with adding information to the pick list, I will just spend a few words on some basic CBD / electronic reporting (hereafter ER) concepts.

A Data model contains a model of the data to be exposed in a CBD document. The ER data model is mapped to D365FO tables and fields through a data model mapping.

A format is a representation of the data in a data model. The representation can come in many formats – like Excel, word, PDF, XML etc. All the new CBD documents are Excel formats. The ER format is mapped to the ER data model by a Format mapping. The format mapping for CBD documents is basically mapping of Excel cell name ranges to the ER data model. The format mapping can be done in Excel or optionally in the electronic reporting configuration form.

Relationship between F&O database, ER data model and ER format. From Microsoft CBD techtalk

Data model is key

Adding new fields to the pick list (and any other Configurable business document) is easy – if the field you want to add – is already included in the data model for the document. You can watch a short video on that here. But if your field is not included in the data model – which is the case with the sales pool field – then it requires a little more effort.

In this post I will focus on how you can extend your CBD document with new fields – that are not included in Microsofts standard ER data models.

Create a derived data model

If you want to add new fields to a CBD data model – then you do it by creating a derived data model. The derived data model in this example will be derived from the original pick list data model delivered by Microsoft. It will contain the same fields as the original data model – and can be extended with your own fields – like the sales pool field.

Creation of derived data models is done in the Electronic reporting framework. Open the Electronic reporting workspace and click on the Reporting configurations tile.

Find the data model used for pick lists – it’s called Packing list model – and create a new derived data model configuration as displayed below.

A new derived data model is now created. Mark it and click on the Designer menu item. Add the sales pool field to the model as displayed below.

Save the model and exit.

Change the status of your modified model to completed – otherwise you will not be able to reference it in the subsequent steps.

Create a derived data model mapping

The data model itself does not contain any information about which tables/fields that should be used in the pick list. This is stored in a data model mapping configuration. Similar to the data model, you also need to create a derived data model mapping – to bind the sales pool field in the data model to the sales pool field on the sales order table.

Now find the data model mapping used for the pick list in the Reporting configurations form – it’s called Shipping pick list model mapping. You can’t modify it directly – so again create a derived custom model mapping as displayed below.

Mark the new derived data model mapping and click on the Designer menu item. In the form below click Designer menu item again.

Now locate the Sales pool field in the data model section (right part of the screen) and find the Sales pool field in the data source section (left part). Click Bind to link them.

Finding the correct field in the left part requires some decent knowledge about the data structure in sales order /warehouse area. I did a number of trials before I got it right. But the relations underneath each table are powerful in the sense that they will allow you to bind to fields from joined tables.

Save and exit. Change status to completed.

Now the Sales pool field is added to the datamodel and mapped to the correct field on the sales order.

Creating a derived pick list format

Next step is to create a derived pick list format – based in the new custom data model and mapping. Find the standard pick list format – in this case the Shipping pick list for shipment (Excel) and create a derived custom pick list as displayed below.

Now complete the new configuration

Insert sales pool field in pick list

And now we are ready to insert the sales pool field into the excel pick list template. Open the Business document management form. Mark the correct shipping pick list. It’s a little confusing that all the pick list variants are listed with the same name – so I had to look into the details form – to determine which one was my derived pick list.

Now insert the new sales pool field

I had some trouble creating the range for the correct cell. Even though I placed the cursor in the correct cell before adding the range – it would propose a different cell. I found that if I edited the cell with F2 before adding the new cell – then it would point to the correct cell.

Finally bind the new sales pool cell range with the sales pool field in the data model.

Publish your new template and make sure that Print management is setup to point to your new layout. The final result looks like this.

You may also notice that I “enhanced” the notes section of the pick list. In Excel I just selected the notes cell in the excel template and increased font size and changed color to orange. I also applied the changes discussed in my first post (removing the load/order barcodes and print step).

Finally I changed the company logo. I never found out if it was supposed to take the report logo you can setup in legal entities. That did not work for me – so I simply inserted my company logo directly in the Excel template.


My work with these CBD blog posts has revealed a couple of limitations that you should be aware of.

Direct print of the pick list (or any other CBD documents) to a printer is not supported currently. You have to open the excel file and then print it from there. For most CBD documents that’s not a major issue – because you typically send them by mail. But for documents that are physically attached to items (like the pick list, packing slip etc.) that is a very real problem.

Low volume warehouses with few orders may be able to accept it, but for medium/high volume warehouses – it’s not a viable solution.

On my to-do list is to examine if the print issue can be worked-around by printing to the printers email address instead.

Another related issue is that the periodic job that prints pick list does not seem to be able to print the CBD version of the pick list – but only the SSRS version.

Configurable business documents – applicability 

Configurable business documents provides new and promising opportunities for superusers and consultants to adjust layout and content of business documents in D365FO.

The technology is however so new, that I need to spend (much) more time working with it to get a better understanding of which document scenarios that are well suited for CBD.

Here’s my to-do list for further exploring…

  • How easy is it to model customer directed business documents with complex layout requirements?
  • Performance of CBD documents versus SSRS documents?
  • Can lacking printer support be replaced by sending emails to printer?
  • Process for creating Word / PDF versions of Configurable business documents
Configurable warehouse business documents — December 19, 2019

Configurable warehouse business documents

With the introduction of configurable business documents for D365FO, it’s now possible to configure the layout and content of many of the business documents in D365FO. This also includes warehouse documents like pick list, container contents, load list, commercial invoice etc.

The configuration is done in excel and word and in some cases in the Electronic reporting framework.

In this post I examine if the warehouse pick list layout can be improved without the need for developer assistance.

This is the first of three posts on configurable business documents. Click here to open the second post: Configurable warehouse business documents – part 2. Click here to open the third post: Eliminating gaps with Configurable business documents

Original warehouse pick list

My experience is that warehouse workers typically find the warehouse pick list in D365FO confusing. First confusing thing is that the pick list contains 4! different barcodes. So which one should you scan?

Furthermore core information like item number, location and qty is squeezed together in the right part of the list to make room for the work barcode.

Original SSRS version of the picklist

Another annoying thing is that the Print work type lines are also listed, which is just additional unusable text to the picker. Optimally the pick list should only contain exactly the information that is required to complete the picking process.

Configurable pick list

As part of the configurable business documents feature a new pick list has been designed. The layout of the new pick list is nicer than the SSRS original – but there’s still room for improvement. It still has too many barcodes and the Print step is still displayed.

The good news is that you can now change the layout.

New configurable business documents version of the pick list

Change the pick list layout

Before you can change the layout, you must find the pick list in the Business document management workspace.

You can find all the configurable business documents in the Business documents workspace

Mark the business document you want to configure and click New Template

Give the new template a suitable name:

Normally Excel online should display the template. Sometimes I experienced that excel opened – but did not display the new template. I would then have to go back to D365FO and reopen the template.

Removing useless barcodes

First of all I wanted to get rid of the barcodes that I know I’m not going to use in my current D365FO project. In this case the load id barcode and the order number barcode.

I first tried simply to delete the cells containing the barcodes – only to find out that you get a validation error because you delete the Excel name related to the cell.

I then simply changed the font color of the bar code to white – which effectively made it invisible.

Remove print work step

The second goal I wanted to obtain was to remove the print steps. I tried conditional formatting and other approaches but found nothing in excel that would hide the print step row.

So instead I fixed the filtering of the print step in the Electronic Reporting format designer by adding the filter below on line values:

And finally a pick list without the annoying load/order barcodes and print steps:

Reduce warehouse costs using shipment consolidation — October 17, 2019

Reduce warehouse costs using shipment consolidation

The Dynamics 365 2019 release wave 2 contains so much new WMS functionality, that you really have to invest considerable time to digest and understand all the new features becoming available in the coming months.

In this post I will be looking into shipment consolidation – an area that has been significantly improved with the introduction of shipment consolidation policies in wave 2.

What is shipment consolidation?

Shipment consolidation is about consolidating several sales orders from the same customer into one shipment. Consolidation of several orders into one shipment is attractive because it can reduce warehouse labor and shipping costs.

Shipment consolidation example

Imagine a situation where a customer places an order at a company shipping orders in parcels to their customers. After receiving the order, it’s released to the warehouse. Now 10 minutes after the customer places a second order which is also released to warehouse.

Without any consolidation, the system will generate two shipments, two pick works, which will result in two pick tasks, two pack tasks and shipment of two individual parcels to the customer.

With shipment consolidation, the two orders are consolidated into one shipment, one pick task, one pack task and only one parcel to be shipped.

The result is saved time for both pickers, packers and lower shipment costs.

Improved shipment consolidation

Automatic shipment consolidation has been available in previous versions of D365FO, but had some severe limitations. With the new shipment consolidation policies most of these limitations are now eliminated.

One of the major improvements is that consolidation setup can now be setup per customer, customer requisition no or any other field on the sales order. Previously you had to decide at the warehouse level whether consolidation should be performed or not.

Another great improvement is that consolidation is now also supported for other release to warehouse methods, than the Automatic release of sales orders job. This means that consolidation is now also supported when using the release to warehouse menu item directly on the sales order and when releasing from load planning workbench.

Finally the timing has been more flexible. Previously only orders released during the same execution of the Automatic release of sales orders job was consolidated. Now orders released at different points in time can also be consolidated.

Shipment consolidation policy form

Shipment consolidation is now setup in a new Shipment consolidation policy form. When you open the form the first time it will be blank – until you activate the Create default Setup button, which will create a default consolidation policy.

You can now modify the default policy or create new policies. You can create as many policies as you like. The Policy sequence controls the order in which the policies will be evaluated. The lower the sequence number – the higher the priority.

Customer specific consolidation example

In the example below I have defined a specific consolidation policy for the US-027 Birch customer. The new policy is setup to consolidate new shipments with existing open shipments. I have given the new policy sequence no. 1 – meaning that it will be evaluated before the default policy which is setup to not consolidate orders

Select Edit query menu item to setup when the policy should be applied. You can filter on most fields from the sales order and load details.

Consolidation query is setup to only have effect for Birch customer

Testing the consolidation policy

To test the new consolidation policy I have created and released the sales order below.

The result is a new shipment

Now I create a second order for Birch customer and release it.

Due to the shipment consolidation policy, the second order has been consolidated with the first sales order on the same shipment.

Now I process the wave related to the shipment and a consolidated pick work is created, containing items for both sales orders.

And from here pick, pack and ship can be performed on the consolidated shipment. These processes do not differ from non-consolidated shipments – so I will not go into details with them.

Bonus info

A dedicated Shipment consolidation workbench will also be introduced – that will allow you to consolidate already created shipments using the shipment consolidation policies.

Update 11-11-2019: J√ľrgen Weber hinted me that the following limitations (and workaround) apply to the shipment consolidation feature:

  • It’s only possible to consolidate shipments with status Open. Once the wave related to a shipment is processed, then the shipment will change status to Waved and it will no longer be possible to consolidate
  • It’s not possible to group shipments according to ship date. This is an issue if you have several orders planned for the same customer – but with different ship dates. This issue can be solved by scheduling different Automatic release to warehouse batch jobs that run in sequence after each other. One job for shipments with shipment today (day(0)), one for shipments with ship date tomorrow (day(1)), etc.. This will ensure that shipments with different ship dates will not be consolidated..

Zone replenishment — August 7, 2019

Zone replenishment

Dynamics 365 for finance and operations (hereafter D365FO) already supports a number of replenishment variations in the warehouse, including wave, load and min/max replenishment.

With version 10.0.2 a new replenishment variation, called Zone replenishment is available for preview and generally available October 2019.

Why zone replenishment?

Zone replenishment solves a rather common gap related to the existing min/max replenishment process.

In Min/max replenishment you typically setup a fixed location for an item and whenever on-hand on that specific location decreases below a minimum threshold, replenishment work is generated.

The replenishment work directs the warehouse worker to replenish the fixed location up to to the maximum value specified for the fixed location.

Zone replenishment example 1 – total qty in pick zone (40+30=70) is below minimum (100)

But some warehouses do not want to specify the min/max thresholds for a particular location – but rather for a zone. They don’t care if a specific location is below minimum – as long as the zone – as a whole – is above the minimum. Zone replenishment solves exactly that requirement.

So instead of specifying min/max thresholds for a specific location, you specify min/max for a whole zone when working with zone replenishment.

Zone replenishment example 2 – total qty in pick zone (30+80=110) is above minimum (100)

Whenever on-hand in the zone decreases below the minimum threshold, replenishment work will be generated.

Zone replenishment work will direct the worker to replenish up to the max value specified for the zone. The put location can be any location in the zone.

Zone replenishment advantages

One important advantage with zone replenishment, compared to normal min/max replenishment, is that you do not need to maintain fixed locations for each item – which can be a time consuming task. Typically re-slotting of fixed locations tend to be neglected – which over time will result in poor pick performance.

Another advantage with zone replenishment is that you can setup more dynamic rules to control the optimal put location. It could be that high runner items are directed to the best locations in the zone, whereas slow moving items are directed to less attractive locations in the zone.

Zone replenishment templates

Zone replenishment is setup with replenishment templates – as you may know from normal min/max and demand replenishment.

The replenishment template setup is pretty similar to normal Min/max replenishment – with the following exceptions:

  • The min/max values apply to a zone instead of a fixed location
  • A directive code dedicated to zone replenishment must be specified. This is used to link a put location directive to the replenishment template. The location directive will determine where in the zone the items will be put.
  • You select a zone instead of referring to a fixed location

Location directive setup

Like normal min/max replenishment, a pick location directive must be setup to specify possible pick locations for zone replenishing.

Unlike normal min/max replenishment, a put location directive must also be setup to specify where to put the items in the zone.

In the Location directive Actions query specify the same zone as specified in the replenishment template, to make sure the items are directed to the correct zone:

In my example I have chosen the “Empty location no incoming work” strategy, which will find the first empty location in the zone, but I could also have selected the consolidate strategy or used stocking limits to control the put location. I have not tested these variations though – so you must experiment with these sub variations yourself ūüôā

Besides the location directive you must also setup a valid replenishment work template. The work template does not differ from other replenishment variations, so I will not go into detail with that here.

How to generate zone replenishment work

To illustrate the zone replenishment work generation, I have setup on-hand for item A0001 as follows:

The total qty of the item in the zone is 70, which is below the minimum threshold for the zone which was setup as 100 on the replenishment template. So replenishment work should be generated when executing the replenishment job.

Zone replenishment work is generated by activating the replenishment job also used for normal min/max replenishment.

Select the zone replenishment template that contains the zone replenishment thresholds.

Work, work, work

When the replenishment job has completed, then the resulting replenishment work can be viewed in the work details form.

The resulting work in my example looks like this:

The replenishment work can now be executed like all other replenishment work on the warehouse app. The actual execution does not differ from other replenishment variations – so I will not go into detail on this.

Bonus information

One thing you should be aware of, is that zone replenishment works best with system directed replenishment – meaning that the system decides the put location.

You can though, set it up to be user directed – meaning the put location is blank and the worker must decide the actual put location in the zone – but you will run into a couple of issues:

  • The worker can not see on the work which zone the work is intended for. If you only replenish one zone – then this is not a problem – but if you replenish several zones then you have a challenge.
  • If you run the replenishment job again – it will not take any open previously generated work against the zone into account. Probably because the work has no put location.

In the preview version, you are able to specify more than one zone on the replenishment line. It doesn’t really make sense to me because you are not able to setup the put location for more than one zone.

Not much documentation is available yet – I have only been able to find this

Confirm and Transfer — May 9, 2019

Confirm and Transfer

As part of the 10.0.1 release of Dynamics 365 for operations (hereafter D365FO) Microsoft released a small – but very useful feature called Confirm and Transfer.

The Confirm and transfer feature is solving a very annoying issue in the current warehouse loading process.

This feature is part of a “wave” of new warehouse features originating from the acquisition of Blue Horseshoe’s AWAX product.

Loading surprises

Imagine warehouse workers have picked 43 pallets to be loaded onto a double deck truck. The pallets have been staged nicely on the dock – ready to be loaded. The truck arrives – but for some reason the carrier sent a standard truck – and not a double deck.

Now only 33 pallets can be loaded to the truck and the remaining 10 will have to be sent on a later truck. Before the Confirm and transfer feature you would have to unpick the 10 pallets, re-release to warehouse and repick them again (systemwise). This can be a very time consuming and annoying process – especially if you work with batch or serialized items.

Confirm and Transfer to another load / truck

The confirm and transfer feature solves this by allowing the warehouse workers to confirm the first load (with the 33 pallets) and transferring all remaining pallets to a new load – where they remain picked and ready to be loaded.

Activate the flighted feature

Before you can use the feature make sure it’s activated. If you can see the the field “Allow load split during ship confirm” in the load templates form – then you are good to go.

If not, then you must activate the flighted feature in MS SQL management studio using the following query:

I had to restart the environment before the feature was visible in the application. Note that in production environments, you will need Microsoft to do the flighting part.

Setup load templates

Next you must activate the new feature for each load template:

And now you are ready to use confirm and transfer.

Confirm and transfer example

I have created a Truck DD load where I have picked 5 pallets, but the truck only had room for 3 pallets. So two pallets must remain on the staging location.

Now I confirm the load and the system allows me to split the 2 pallets on the dock to a new load:

My original load is now confirmed and only contains the 3 loaded pallets:

A new load has been created with the remaining 2 pallets:

When the second truck arrives, they remaining 2 pallets can be loaded onto that truck.

Other nice things to know

The confirm and transfer feature can also transfer work in process to a new load. This means that pallets that are being picked can also be transferred.

You can also control on a specific load whether split is allowed:

Though this feature is nice it will not replace the Transport Load feature. It’s intended for transferring items from a load to another. Not to split a large “virtual” load into many loads representing the actual trucks.

If you are using the TMS module, then be aware that the new split load must be re-rate/routed.

Container quality inspection with PowerApps and Dynamics 365FO — December 14, 2018

Container quality inspection with PowerApps and Dynamics 365FO

I’m currently working with a company that ship goods around the world in containers. Occasionally the container and/or the goods are damaged during transport. To be able to document that possible damage happened during transport, the company has implemented a quality process, where every outbound container is photographed before and after packing.

The current process is slightly casual in the sense that the photos remain on the camera (until the memory stick is full) and they are not archived properly to the container.

In this post I will talk about how this – and other – quality processes can be optimized by combining PowerApps with Dynamics 365 for operations (hereafter D365FO).

Improvement potential

There’s several issues with the current process:

  • Permanent storage of pictures on cameras is not optimal. The camera can be lost or the memory chip can be damaged. You would want them in a secure file area with proper backup.
  • When the camera is full, the photos are copied to the workers personal onedrive – which is a better storage option – but still not perfect, because onedrive is tied to a particular worker – you’d want them in file area where more than one worker has access
  • The pictures are difficult to find again, because they are not stored in a container file – or stamped with the container number. The worker must compare picture creation date with shipment date of the container and search all pictures on that date to identify the photos.
  • You need to have a dedicated camera in the warehouse – why not let the workers use their own mobile phone to take the pictures

One way to eliminate all these issues is to combine PowerApps with D365FO. As you will see below this will allow the worker to: 1) use his own phone to take the pictures, 2) have the photos immediately stored on sharepoint or some other company file area and 3) immediately be visible in D365FO from the container/Load they are related to.

Container inspection PowerApp

The Container inspection PowerApp is a PowerApp that combines container information from D365FO with a mobile phones camera capabilities. 

The Container inspection app will present the warehouse worker with a list of the containers currently on the Container inspectionoutbound docks. As soon as a Container arrives at the Dock it will appear on the PowerApp and when it’s been shipped it will disappear from the list.

Because the dock is also displayed it’s easy identify/find the container you’re about to document.

Behind the scenes the PowerApp is finding all container loads where a driver checkin has been performed.

When the worker clicks on any of the containers a new inspection process is started, where the worker can take one or more photos of container with the phone:

New inspection              Container photos

When photos have been taken, they are stored in a container inspection archive on sharepoint. 

The archived photos can be viewed both on the app and from the load (container) form in D365FO:

Embedded powerapp

Another embedded PowerApp will handle the display of photos in D365FO. The embedded PowerApp will take the container id from the load in D365FO and use that to retrieve the photos stored on sharepoint.Embedded powerapp2

The embedded powerapp will then display all photos related to that container.

The result is that the worker will only have to worry about taking the photos. All archiving and relating photos to the correct container is performed by the App behind the scenes.

How to build the App

I built the Container inspection PowerApp by modifying/extending the template Site Inspector PowerApp, that you can download from within PowerApp. I modified/extended it in the following ways:

  1. I created a read-only Load and Appointment data entity in D365FO using the data entity wizard.
  2. I created a new screen/gallery in PowerApp with the Load data entity as the datasource
  3. I created 2 sharepoint lists ContainerInspection and ContainerPhotos to store the results of the inspection.
  4. I modified the site inspection app to store images on my new sharepoint lists instead of storing them in excel/image files on onedrive.
  5. I did a lot of renaming of forms
  6. I created an embedded PowerApp in D365FO that can be inserted on the loads form. The embedded powerapp is used to display container photos in D365FO on the load/container.
  7. plus various other small adjustments

The whole thing probably took me 2-3 days to work out, which is partly due to my limited experience with PowerApps. It’s very likely that an experienced PowerApp consultant would be able to do it (much?) faster – but the point I want to make here that it’s very much possible for everybody to build these apps – if you are willing to invest a little time to understanding the Power platform.

Other applications

This type of PowerApp could also be used for other processes where you would want to combine data from D365FO with photo’s.

It could be used to support visual quality inspection in manufacturing. In that scenario you would want to link the photos of the product to a quality order.

It could also be used in vendor returns processes to document damaged goods before returning to vendor.


Using PowerApps to support warehouse processes — October 30, 2018

Using PowerApps to support warehouse processes

Written by Steffen Daugaard Pedersen and Birger Larsen

The warehouse app for Dynamics 365 for Operations and Finance (hereafter D365FOE) offers out-of-the-box support for both basic and more advanced warehouse processes. There are however some areas, where the process support can be improved.

In this post we investigate if PowerApps can be used to compliment the warehouse app to improve warehouse processes in D365FOE.

Lack of overview

For most warehouse processes, the warehouse worker can see an overview of pending warehouse work in worklists on the warehouse app. Worklists presents each work as a tile. The more tiles – the more work remains to be done.


Besides providing overview on remaining work, the worklist also provides, a quick way to initiate execution of the work. The worker simply touches one of the tiles to start the picking process.

There are however some processes, that are not supported by worklist. Examples of this include item receive process, production report-as-finished and system grouped picking. For these processes no overview is provided and the warehouse worker must initiate the process by manually entering (or scanning) a purchase order id, load id, production id etc.

PowerApps supported item receiving

As mentioned previously, the item receive process does not provide any worklist overview. Consequently, the warehouse worker must initiate the item receive process by manually entering a purchase order ID.

As a workaround you can find various purchase order overview forms in D365FOE, but they have several inherent problems:

  • They are not specifically designed to display relevant information for warehouse workers performing the item receive process. They will typically display a lot of irrelevant information, and on the other hand omit important information relevant for item receive process
  • They can’t be used to initiate the item receive process on the warehouse app

We have therefore tried to solve these two problems by creating a PowerApp (see below), that provides a specialized item receive overview and also allows the worker to initiate the item receive process in a simple way.

Purchase order today powerapp

The PowerApp only displays information relevant for the item receive process. Furthermore exceptions / special handling is highlighted with color to increase awareness for the worker.

The warehouse worker can initiate the item receive process, by scanning a Purchase id barcode displayed on the PowerApp and optionally also the item barcode from the PowerApp:

ScanPOnum       ScanItemId

Building an item receive PowerApp

The PowerApp is built using a standard tablet layout based on the list template.


First step is to identify the data entities containing relevant information for the item receive process. D365FOE comes with many predefined data entities. We identified the three data entities below, that contained the required item receive information.


Next step is to filter and sort the list of purchase orders. This is done in the item property of the gallery list:


Now start by inserting fields from the PurchaseOrderLinesV2 entity, as these can be inserted directly:


Fields from related data entities to PurchaseOrderLineV2 can be inserted using the lookup function:


Refresh of data

To make sure the PowerApp will display updated information, a timer is inserted. The timer counts to 60 seconds and then restarts.


Upon restart, the purchase line data source is refreshed:


Creating barcodes in PowerApps

To allow the worker to use the PowerApp to initiate the receiving process on the warehouse app, we need to add barcodes to the PowerApp screen.

This can be done by using a barcode API. The API that we are using is the This API enables you to generate a barcode from a ZPL file.


To create the ZLP file, download the Zebra Designer from the Zebra website. This free editor will create printed bar code labels, and the next steps will walk through the generation of a simple QR barcode.

Open the Zebra Designer -> create a new blank document and select the QR code.


In the next screen insert the requested data. In this case the number sequence does not contain letters, but the QR Barcode is able to have letter and special characters like -.


Press finish and resize the QR code.


Print the barcode as a file:

Select the print button and print as a file.


Save the file in a folder and edit the file in notepad.

NotepadCopy the content and insert the content after this path:×2/0/%10%10CT~~

In this case, the new web path looks like this:×2/0/%10%10CT~~%10CT~~CD,~CC%5E~CT~%5EXA~TA000~JSN%5ELT0%5EMNW%5EMTT%5EPON%5EPMN%5ELH0,0%5EJMA%5EPR4,4~SD15%5EJUS%5ELRN%5ECI0%5EXZ%5EXA%5EMMT%5EPW609%5ELL0406%5ELS0%5EFT79,343%5EBQN,2,10%5EFDLA,00000451%5EFS%5EPQ1,0,1,Y%5EXZ

This web site is then used in the power app:

Open the power app in edit mode and insert a picture:


Edit the picture and insert the web address from the previous setup.

The web address must be put in quotes. (‚Äú‚ÄĚ)


In the web address, replace the ID with the function for purchase order ID.

This is done by writing &PurchaseOrderNumber&

Before editing (remember to put quotes around the text below):×2/0/%10%10CT~~%10CT~~CD,~CC%5E~CT~%5EXA~TA000~JSN%5ELT0%5EMNW%5EMTT%5EPON%5EPMN%5ELH0,0%5EJMA%5EPR4,4~SD15%5EJUS%5ELRN%5ECI0%5EXZ%5EXA%5EMMT%5EPW609%5ELL0406%5ELS0%5EFT79,343%5EBQN,2,10%5EFDLA,00000451%5EFS%5EPQ1,0,1,Y%5EXZ


After editing (remember to put quotes around the text below):×2/0/%10%10CT~~%10CT~~CD,~CC%5E~CT~%5EXA~TA000~JSN%5ELT0%5EMNW%5EMTT%5EPON%5EPMN%5ELH0,0%5EJMA%5EPR4,4~SD15%5EJUS%5ELRN%5ECI0%5EXZ%5EXA%5EMMT%5EPW609%5ELL0406%5ELS0%5EFT79,343%5EBQN,2,10%5EFDLA,”&PurchaseORderNumber&”%5EFS%5EPQ1,0,1,Y%5EXZ

Now the app will show the barcode per line:



Improve Report-as-finished process using embedded PowerApps

In the report-as-finished flow in the warehouse app, the production number must be used when reporting as finished.


Instead of entering the production id manually or scanning from a piece of paper, we can use an embedded PowerApp, to display the barcode directly in the D365FOE production form. This will allow the worker to scan the production id from the D365FOE form to initiate the report-as-finshed process:


Creating the embedded PowerApp

The same method as the previous example can be used to generate a barcode for the production order. Using embedded powerapps do however require a few more steps, and we will go through them in the next steps.

In the PowerApp editor, create a blank app and insert a picture like the previous app.

We have selected a landscape app, as the embedded app will look nicer when adding it to the form in Dynamics365FOE.


Instead of the purchase order tag, insert the function for data from embedded powerapps in dynamics 365.

This fuction is called FinOpsInput and to use this in a web address, the EncodeUrl must be used.

The web address should look like this:×2/0/%10%10CT~~CD,~CC%5E~CT~%5EXA~TA000~JSN%5ELT0%5EMNW%5EMTT%5EPON%5EPMN%5ELH0,0%5EJMA%5EPR4,4~SD15%5EJUS%5ELRN%5ECI0%5EXZ%5EXA%5EMMT%5EPW609%5ELL0406%5ELS0%5EFT89,337%5EBQN,2,10%5EFDLA,”&EncodeUrl(FinOpsInput)&”%5EFS%5EPQ1,0,1,Y%5EXZ”

Select the OnStart function in the app. Do not select the picture before doing this. This line will enable Dynamics365FOE to use the app with live data as an embedded app.


Insert this function in the fx area:

If(!IsBlank(Param(“EntityId”)), Set(FinOpsInput, Param(“EntityId”)), Set(FinOpsInput, “”))

Copy the app id by selecting the file menu:


Select See all versions:


Click the details tab and copy the App ID number for later use:


Open Dynamics 365FOE and in the production orders details form, right click and personalize.



Insert powerapp in D365FOE

To insert the power app, select insert power app and point in the form where you would like the power app to be available.


Use the APP ID that you copied earlier and select the input field that you would like the power app to use. In this case the barcode should be generated for the production order ID.


Click insert.

Now, an embedded powerapp is available for all production orders, and the report as finished flow is simpler when using the warehouse app.


Advanced PowerApps using customized data entities

It’s also possible to create more advanced Powerapps using customized data entities. The Powerapp below supports the Load receive process in D365FOE. In this item receive variation, the worker starts by scanning a load id instead of a purchase ID. Instead of entering the load id manually, the worker scans the barcode containing the load id.

This PowerApp does however require a customized data entity consisting of information from loads, load lines, appointments and products.InboundLoads.png

The creation of customized data entities do require developer assistance, but there’s several advantages:

  • The PowerApp becomes simpler/easier to build, because you do not need to join several datasources
  • You can avoid delegation issues in the PowerApp, because you can filter data before sending it to PowerApps.
  • App performance can be optimized using filtering at row and column level before sending data to the App

What’s next?

Powerapps provides interesting possibilities to extend warehouse and manufacturing processes in Dynamics 365 for operations. We are currently trying out PowerApps on D365FOE projects to get feedback from customers to understand where / how we can apply PowerApps to leverage the customers processes. Other processes that might benefit from the Powerapps described in these posts are:

  • System grouped picking, where the worker must enter some grouping id ‚Äď typically a sales order id or a load id to initiate picking of all work to a sales order/load etc.
  • Work lists system grouped, where the worker must enter some grouping id ‚Äď typically a sales order id or a load id to initiate picking of all work to a sales order/load etc .
  • Material consumption, where the worker must enter a production id to register material consumption.
  • Raw material picking, where you can use worklists ‚Äď but they are not able to display production start date/time and context about the production – like production id, finished goods item etc.



“Cancel replenishment if demand has been cancelled” — September 10, 2018

“Cancel replenishment if demand has been cancelled”

Ever wondered what the parameter “cancel replenishment if demand has been cancelled” is used for?

Cancel replenishment

Well recently I did and had serious trouble finding any documentation. The parameter is mentioned briefly in this blog, but I was not sure I understood the description there Рso I decided to test it.

Conclusion: If the parameter is ticked – then replenishment work will be deleted automatically if you decide to cancel the original work (that caused the replenishment) from the work form.


I have created a sales order work that’s been blocked because dependent replenishment work has been created.

Pick work

The replenishment work looks like this:

Replenishment work - open2

Now I cancel the original work because the customer called in and cancelled the order:

I cancel replenishment work

And behind the scenes the Parameter¬†“cancel replenishment if demand has been cancelled” make sure that my replenishment work is cancelled automatically:

Replenishment work - cancelled