Item order defaults in Dynamics 365 for Operations

I’ve mentioned the Dynamics 365 for Operations roadmap site (roadmap.dynamics.com ) before, but there’s another place where you can find out what’s available in the latest release, and that is the New or changed features page of the Dynamics 365 for Operations Help Wiki. On the ‘What’s new or changed in Dynamics 365 for Operations version 1611 (November 2016)’ page under the Product master data heading you’ll find reference to a couple of neat little enhancements to the processing of product variants.

The first one I’d like to call out is the ability to setup your own Product number format for Product variants. It’s not immediately obvious in Dynamics AX 2012, but when you’re using product variants (Configuration, Style, Size, or Colour), the system creates a unique product number for each valid combination:

Now we’re typically going to use Style, Size and Colour variants when dealing with Retail companies, and mostly those companies have their own convention for referencing a Style, Size and Colour within a part number, so they may have something like ITEM1234L01. Well now you can do that in standard Dynamics 365 for Operations. Product information management > Setup > Product nomenclature:

You can construct your Product variant number from any combination of: Product master number; a Number sequence; Configuration; Style; Size; Colour; and/or a Text constant.

Next, on the Product dimension group you specify the Product nomenclature (product variant number configuration) which you’d like to use.

Product information management > Setup > Dimension and variant groups > Product dimension groups:

Now, let’s create a product master, Product information management > Products > Product masters > New:

And create some product dimensions:

And:

And then:

That’s neat, and a nice tidy up of a clunky AX 2012 convention – but there is more.

We can now specify Default order setting for each of the Product variants. I’ve released my three product variants into the USMF company and setup the item. Now, (if you’ve used Dynamics AX before) you’ll notice that we don’t have ‘Default order settings’ and ‘Site specific order settings’, we just have: ‘Default order settings’

The Default order settings form shows a couple of significant changes from earlier versions:

So the most significant change here is that the Default order settings setups now have a ‘Rank’. The higher the rank, the more important the rule is, meaning that it will have a higher priority and will be used before the rules with lower ranks. There’s one general default order settings rule with a rank of zero (and there can only be one rule with rank zero). Rules can have the same rank, provided that the dimensions they apply to are different. This is useful for modelling site specific order settings. When a new default order settings rule is created, the values for order values, stop flag, etc. are inherited from the rule with rank zero, but can be overwritten.

And the second major change is that the Default order settings can now be specified for individual product variants (or product dimensions), including the all-important ‘Stopped’ flag.

Brilliant!

The Help page for this form also mentions that you can switch the form between Details view (shown above), and Grid view (shown below) – useful for checking setup. The switch is on the on ‘Options’ tab:

‘Grid view’ gives:

So finally, I’ll just mention in passing that the Master planning setup of an item is done partly on this form, and partly on the Item coverage settings. Item coverage setup is always performed at the product variant level.

Vendor managed inventory in Dynamics 365 for Operations

I’ve just been reminded of a handy little website: roadmap.dynamics.com. It’s a great place to keep up to date with the what’s new, and roadmap for Dynamics AX / Dynamics 365 for Operations. Tucked away under the What’s new > Vendor collaboration, is an announcement of the availability of Vendor managed inventory – or Consignment stock.

This is a really nice enhancement of supply chain functionality.

Consignment stock is often used in Lean manufacturing implementations – but I’ve also come across it being used in more traditional environments, and it seems to be very commonly used for labels and packaging, because the printing vendor wants to use large batch sizes to minimise their setup and run costs, and they’re prepared to hold the inventory.

So let’s walk through this new functionality, and note that this is only available for Dynamics 365 for Operations – it’s not available for Dynamics AX 2012.

Detailed instructions are found on the Dynamics 365 for Operations Help Wiki. The summary is that the process uses the ‘Owner’ inventory dimension (which used to be enabled only as a localisation for Russia); a new Consignment replenishment order; and an Inventory ownership change journal.

First some setup.

Inventory owners. Inventory management > Setup > Inventory owners:

Here, we are setting up a link between our vendor and the Owner inventory dimension, and defining the default dimension which represents our own inventory.

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

We’ve created a new Dimension group with the ‘Owner’ dimension active – in the current version you can’t enable batch or serial tracking (well you can on this form, but you get an error when you try to create an item with with this Tracking dimension group).

Inventory ownership change journal. Inventory management > Setup > Journal names > Inventory:

No surprises here, apart from the new Journal type, and of course we can define a default Ownership change journal name:

Next I’m creating a new Consignment stock warehouse. This isn’t strictly part of the process, but it’s the way I’ve seen this process being managed in practice. Inventory management > Setup > Inventory breakdown > Warehouses:

Note. Don’t be tempted to use the warehouse Vendor account on your Consignment warehouse. That field is related to the sub-contract production process (where you want to deliver to your sub-contract vendor), so it defaults the warehouse delivery address. In this context you’d have products going round in circles.

Now we can setup a new item, and assign that Tracking dimension group. Note that only standard cost, and moving average inventory cost models are supported:

I’ve chosen Standard cost, so I’ll activate the standard cost for my released product.

Now we’re ready to create a Consignment replenishment order. Procurement and sourcing > Consignment > Consignment replenishment orders:

Well the concept is pretty self-explanatory. There’s not much to this document and it only supports the Product receipt update. Let’s create one:

Vendor; Contact; Deliver to warehouse – couldn’t be simpler. Add a line:

Again all self-explanatory, and we have a linked inventory transaction:

Without any fuss the system’s assigned the correct Owner inventory dimension.

Consigned inventory is often managed via an over-arching Purchase agreement or Contract. You’ll see in a moment that when you change the owner of the Vendor managed inventory to yourself, the system creates a purchase order. That purchase order will take the price from a purchase price trade agreement, but unfortunately not from a Purchase agreement. So managing the Purchase Contract is currently a manual process. Note also that there isn’t any option to print the Consignment replenishment order, so at this point your communication with your vendor is again a manual process.

As an aside, Master planning recognises the Consignment replenishment order as a supply (but there’s no Planned consignment replenishment orders, you have to create Consignment replenishment orders manually):

OK – now let’s receive our consignment inventory. Procurement and sourcing > Consignment > Consignment replenishment orders > Receive > Product receipt:

Again this form shows all of the features that you’d expect to see. There’s an option to perform Registration prior to receipt, but I don’t really see the point in doing that here. OK updates the on-hand and inventory transactions:

And:

Note that there are no ledger postings related to the Consignment replenishment order product receipt:

Before we consume this inventory we need to create an Inventory ownership change journal. Inventory management > Journal entries > Items > Inventory ownership change or Procurement and sourcing > Consignment > Inventory ownership change:

New gives:

OK gives:

Create a line, and note that the ‘From’ Site, Warehouse, Location and Owner are all enterable – whereas the ‘To’ dimensions are set by the system.

Post the journal, and the system creates a Purchase order:

Note that the Purchase order header shows an Origin of ‘Consignment’ (and the purchase order line quantity can’t be changed on the Purchase order):

Now let’s review the inventory transactions again:

The Inventory ownership change journal has consumed some of our consignment inventory and we have a purchase order product receipt (with the normal ledger postings).

So now we can transfer this inventory and consume it on a production order, and we can post a purchase order invoice on the purchase order.

There are some [sensible] restrictions on the consignment inventory. You can’t issue the consignment inventory to a transfer order, and you can’t issue the consignment inventory to a production order – you have to have posted the ownership change first. But you can count the inventory (up and down), and transfer the consignment inventory using a transfer journal. There’s also a rather neat function to automatically populate the Inventory ownership change journal from production order components.

If you’re planning to implement this process you might want to check out the options for setting up Vendor collaboration as per this help wiki, but it’s perfectly possible to operate this process without giving your vendors access to Dynamics 365 for Operations.

Updated 16/12/2016: Scott Hamilton has just published a definitive article on this topic. See Manage Consigned Inventory using Microsoft Dynamics 365 for Operations.

The SSRS warmup class in Dynamics AX

Thanks to my colleague Frankie Zhao for giving me this one.

We’ve all noticed that the first time you do something in Dynamics AX it takes a bit longer than normal – and in the case of an SSRS report that bit longer can be quite a bit longer, so I was pleased to come across the SSRS warmup class a while ago.

See the TechNet details here.

Unfortunately, I didn’t carefully read the whole article, because the first two sections talk about how to setup a batch group and a batch job – and I didn’t think that that was particularly complex:

In Dynamics 365 for Operations: System administration > Setup > Batch group	In AX 2012: Systems administration > Setup > Batch group
In Dynamics 365 for Operations: System administration > Inquires > Batch jobs	In AX 2012: Systems administration > Inquires > Batch jobs > Batch jobs
New:	File > New:
Batch job > View tasks:	View tasks:
New:	Ctrl-N / File > New:
And add the row: Note the name of the class is SrsReportServerWarmup.	And add the row:

Then define a recurrence, (for instance run on each working day at 7:45am).

Batch job > Recurrence:

Recurrence:

And finally change the batch job’s status to ‘Waiting

Batch job > Change status:

Functions > Change status: (Just click on the required status).

So, imagine my disappointment that after setting this up in a brand shiny new Dynamics AX implementation, I logged in first thing in the morning and noticed that the main report that the users were going to use didn’t actually open any faster than normal.

And the reason is staring us in the face in the TechNet article:

“When the SRSReportServerWarmup class runs, it prepares the report server for use by running a sample report that is named SRSReportServerWarmup. You can customize the SRSReportServerWarmup class so that it runs additional, specific reports.

For example, assume that Phyllis, the Accounts Payable manager in your organization, runs the Vendor Aging report every morning. To ensure that this report renders quickly for Phyllis, you can customize the SRSReportServerWarmup class so that it runs the Vendor Aging report every morning. To do this, you’ll need to create a new method that runs the Vendor Aging report and then configure the SRSReportServerWarmup class to call this new method.”

What this job does is to save a copy of the report ‘SRSReportServerWarmup.AutoDesign’ to a PDF file in the system’s temporary directory, but your user’s won’t really derive any benefit from this job unless you customise the class to run those reports that the users actually run. However, beware that you aren’t exposing any sensitive data by creating a file in a folder that everyone has access to, so give some thought to the parameters that you use to run your warm-up reports.