Friday, September 30, 2016

Tutorial: Location directive failures - Common mistake #1 - Multi SKU


A lot of people that are getting to know the new Warehouse solution are struggling to set up the location directives correctly. They very often end up scheduling some work and not getting the location automatically selected by the system.

A good example is this post on the AX community where I attempt remote location directive setup data troubleshooting:

In this next series of posts I want to cover some of the more common errors people do when setting up the location directives and explain ways you can try to figure out why a location was not pre-selected automatically, if that happens.

You can read the basic information about creating location directives on MSDN, in these posts I will assume good knowledge of the concept.

Common mistake #1 - Multi SKU

This is one of the most common problems reported as "location directives are not working and I can't figure out why, everything seems right".

As most of you have probably seen on your installations, you needed to setup 2 location directives for Put for each configuration, one with Multi SKU, the other without. Often, because people don't really understand when this setting comes into play, they don't create both, but only the single sku, or only the multi sku, thus resulting in location not being assigned (allocation failing).

So here is a brief explanation:

As you know, when work is being created for an order, whether it is a sales, a purchase or any other supported order, the location directives are used to determine WHERE to pick/put the item(s). So for each individual work line location directives will be evaluated, and a location will be selected based on the work line details. The location directives will be evaluated sequentially from all the ones that meet the requirements for the particular work line (e.g., they are for the right warehouse, have the right details based on the query, etc.)

Note. There are special cases where the location to Pick/Put is pre-selected. For example, during PO registration the first pick is always from the RECV location. Another example is the Inventory movement by template, where the location to Pick from is selected by the worker himself, and only the puts are done through location directives.

One of the criteria evaluated on the location directive is the Multi SKU flag. The location directive which has Multi SKU flag selected will only be considered, if the corresponding work line being processed right now has Item number = 'Multiple' (it shows up as blank in the work details, but as "Multiple" on the mobile device). This is typically the case for when you need to put items down to a Staging / Pack / QMS areas, after having picked up multiple items from the different picking locations in the warehouse.

Therefore, if Multi SKU flag is selected for a location directive, you cannot edit the query for it. That makes certain sense, since this location directive would only apply to multiple items, thus you cannot really check if they fall withing the conditions of the query, because there are more items than one.

The Multi SKU flag mostly makes sense for Put location directives, because for most of the picks we are in a situation where it is:

  • an initial pick (thus, pick of 1 particular item)
  • a special pick of one or more items from a pre-defined location (like RECV I mentioned above)
  • a special pick where we continue work execution after having previously put the item(s) down to a certain location (STAGE is the typical example, since we'll need to continue to BAYDOOR after that)

Location directives do not prevent you from setting the Multi SKU flag for Picks, however, so if there's a certain scenario where you do need this, it'll be available.

Short summary

In short, if your work orders are always small, 1 item per order, then you do not need a Multi SKU location directive.
If, however, you have work orders with single items, and then some with multiple items being picked as part of one work order, you will need to have 2 separate location directives, one with and one without the Multi SKU flag, and then you can decide if you want the goods travelling to a different location in such cases.

Example walkthrough

To show the difference between the behavior of the location directives with and without Multi SKU, I have created the following location directives, which are identical apart from the flag, as well as the location to Put, so we can see the result difference. Again, only the two Put location directives are really of interest. I have chosen to show a Sales scenario, but the same applies for all other flows.

Location directive for sales Pick work lines on WH 24
Location directive for single-item sales Put work lines on WH 24

Location directive for multi-item sales Put work lines on WH 24
To summarize, the intention is that work order with single items will be put to BAYDOOR location, while multi-item orders will be put down at BAY_MULTI location.

Note. Both Put location directives have the Directive code set to Baydoor. Discussing the behavior of this field is outside the scope of this blog post, but will be covered in one of the following posts.

Now, I have created the following 4 sales orders and released each one individually to create work. I have created sufficient on-hand for picking these items. Sales orders have the following configuration:

  1. 1 line for a single item
    1. 10 pcs of A0001
  2. 2 lines for different items
    1. 10 pcs of A0001
    2. 10 pcs of A0002
  3. 2 lines for the same item
    1. 10 pcs of A0001
    2. 10 pcs of A0001
  4. 2 lines for different product variants (meaning, same item number, but different product dimensions)
    1. 10 pcs of P0004, Size = L
    2. 10 pcs of P0004, Size = S 
You can see the screenshots for work orders created, in the above order, below:

Work for sales order with a single item
Here, location BAYDOOR was used. That is correct, since the Put work line is for a single item, A0001.

Work for sales order with multiple different items
Here, location BAY_MULTI was used. That is correct, since the Put work line is for two items. You can see the Item number is blanked out on the work order line in this case.

Work for sales order with multiple lines for same item
Here, location BAYDOOR was used. That is correct, since the Put work line is for a single item, even though the quantity for this line is a combination of more than 1 work line.

Work for sales order with multiple product variants
Here, location BAY_MULTI was used. That is correct, since the Put work line is for multiple product variants. So even though the Item number stamped on the Put line is just 1 item, the product dimensions are blanked out since there is more than one.

This is one of the "confusing" parts, as the rule is not just a simple "item number is not filled in".
We treat product variants as different products in this regard, so it is important to note this particular difference.

Next step

Stay tuned for the next common mistake in one of the next posts.

Tuesday, September 27, 2016

Development tools: Editor scripts in Microsoft Dynamics AX 7 or Visual Studio X++ code snippet library

As you know from some of my previous post, I'm a bit fan of developer productivity. Over the years I've delved into creating new Editor Scripts in Axapta, some of the more complex ones shown below:

That's why I was very happy to read a blog post by Martin Drab aka goshoom the other day. Martin describes the use and the simple steps to create new code snippets for Visual Studio that apply to X++ language. Here it is:

Now, as you can see from the blog post, it's not exactly the same in terms of capabilities as the Editor Scripts in AX 2012 and prior. The code snippets in VS are specifically targeted at inserting some new code into the editor or refactoring existing code in the editor, but not interacting with AOT and AX metadata.

They are however still quite handy, especially if you get used to the hotkey combination Ctrl+K, Ctrl+X (or S for surrounding your code with whatever the snipped inserts).

That's why I decided to create a public code snippet library through which we could potentially share some useful code snippets with each other.

To start it off I have ported some of the more commonly used template editor scripts from AX 2012.

Here is the link to the Visual Studio X++ code snippet library.

Share your cool code snippets here in the comments, and I will upload them to the share (just to have some moderation process in there)

If you have some comments or suggestions as to a better place to store these, let me know through the comments below.


Monday, September 26, 2016

Development tutorial: Extensible base enumerations in Microsoft Dynamics AX 7


Microsoft Dynamics AX 7 is a game changer when it comes to applying customizations required for running your specific business. Specifically, the development approach changed to focus a lot more on extending the application instead of over-layering elements to customize application flows.

Over the following months I will try to describe some of the examples of where Microsoft has ensured that the application can be extended without modifying existing AOT elements.

If there is a specific topic you would like me to cover, let me know in the comments.

Topic of today

Today I would like to start by talking about Base Enums. Enums in X++ are defined in AOT to represent a list of literals, or named constants, if you will, which then can be used in the code in a convenient way. They are stored as integers in the database.
As all of you I'm sure are already familiar with this concept, I will no go further into this.
If necessary, here's a refresher:

Base enums have caused a lot of grief when writing customizations or when doing code upgrade, as you always needed to be aware of new values Microsoft might add to the list in future updates, some of the ISVs could add to the list, etc. So normally you'd have to remember to add a gap in values when adding your new enum value.
You also needed to be very careful about changing existing values as to not break the existing data in the database.

In AX 7 it is not that easy. Since there is a much more strict separation into models, with Platform and Foundation pieces being clearly isolated from Application components, customizing by overlayering base enums is not as easy, and not possible in some cases.


Let's look at NumberSeqModule base enum as an example. You all are most probably familiar with this enum, since that's where you would need to add your new application module for new solutions, if you want it to be handled through the common Number sequence framework.
In AX 7 this enum is defined in the Application Platform model, meaning that it cannot have any values that are application-specific, as well as that it cannot be over-layered.

That means that the only way to go is to extend the enum.
If you are not familiar with the concept of extensions in Dynamics AX 7, you can read a good description on our wiki page:

In order to be able to extend a base enum, it needs to be marked as allowing extensions, which is done through the property IsExtensible.

Note that in Application Platform there are a few enums that are extensible, while the majority does not allow it. That is done on purpose, for performance reasons, based on the belief that partners would not need to extend these enums.

If that is not the case, you should let Microsoft know, so they mark the corresponding enum as extensible and release it as a hotfix.

As a result of extending an enum, a new base enum element will be created in the current model, and you will be able to add one or more element values to it.

At runtime AX will collect the values from the base definition and all extensions across all models and present the combined list of values to the user.

Note that you cannot change the properties of the base enum through extension, only add new enum values.


The major difference of an enum that has extensions vs the legacy enum is in the way how they are represented under the hood.

The extensible enums are represented in CLR as both an Enum and a Class, where each enum value is represented as a static readonly field. So accessing a specific value from the above enum, say, NumberSeqModule::Invent would under the hood look something like NumberSeqModule_Values.Invent, where Invent is of type NumberSeqModule which is an Enum. It would in turn call into AX to convert the specific named constant "Invent" to its integer enumeration value through a built-in function like the symbol2Value on DictEnum.

This class containing all the values would be built based on all the extensions of the corresponding enum, thus providing a generic way of handling them.

Nothing changes on the database layer, the values are still stored as integers, as today.

X++ impact

  • What this means for your every-day X++ development is that things like comparison of different enum values are out of the question. So you cannot, for example, write
if (workTable.WorkStatus <= WHSWorkStatus::InProgress)
You would now need to be more explicit, listing all the specific values that are applicable through an equality operator. (Like, Open and InProgress)
  •  This also means that you cannot rely on a certain enum value having a specific integer value, since they will be assigned per-deployment depending on all the different extensions for this enum you have deployed. So doing enum comparisons to their integer values is a Big No from now on.
if (workTable.WorkStatus == 0)
Note that both of the above have been a Best Practice for enums for a while now, so your modifications should hopefully not be impacted, if a certain enum is made extensible.
  • For extensible enums there is still an implicit conversion to and from integer type, but a warning will now be shown, to warn the developer that the enum value might be incorrect as a result of the assignment.

Development environment impact

In Visual Studio the impact is visible for any kind of metadata properties where enum values need to be specified. That includes Fixed field and Related Field Fixed when defining relations on tables and data entities, filter values on Query data source ranges, etc.

For example, when defining a Fixed field relation, you would now be able to select the enum value from a dropdown:

Setting value of an extensible enum on a Fixed field relation

Note how the full notation is used instead of what you'd do before with specifying the integer value of the corresponding value.

On query data source ranges you would instead use the short notation by just specifying one or more enum values, comma separated:

Setting value of an enum on a Query range


As you have seen, extensible enums is a way the platform now supports adding additional values to existing base enums without customizing these enums, which really simplifies upgrade going forward.
It however introduces certain limitations on how you use these enums in X++ code and metadata that you need to familiarize yourself with.

Let me know if you have any questions on this

Saturday, September 24, 2016

Tool: Dynamics AX 7 browser power & Table browser add-in for Google Chrome

Microsoft Dynamics AX "7" is, as you all know, a Cloud release, which means that the one and only client available for AX "7" is the web browser.

Nowadays browsers are pretty advanced, meaning that you get pretty much the same look and feel, as in a "rich" Win32 client. It has its drawback as well, of course, but we are not here to talk about those.

On the positive side, it now allows for a number of entry points that will take you directly into the flow or form you want to execute, because most of the information about where you want to go is provided through the URL itself.

I have already previously posted about the Warehouse Mobile Devices Portal emulator form and how you can access it. Here it is again:

You basically specify your Dynamics AX URL, followed by which company you want to connect to, and which menu item to open - in this case, an Action menu item WHSWorkExecute. Easy, right?

Well, you can do the same trick to open other menu items, and that is what this blog post is about - Table Browser.

As some of my old readers know, I'm a big fan. If you are not one of those, and are running previous versions of AX, check out the blog post below, it's awesome!

Well, Dynamics AX "7" also has a little something to help you browse tables now.
Here is a cool little add-in for Google Chrome, which allows you to open the table browser for a selected table in a selected company (settings are persisted, so you don't need to enter the company name each time):

I've just tried it out and it's pretty neat, so take it for a spin and let me know what you think!

To finish off, let's just take a quick look at what the add-in actually does, which is - opens a pre-defined URL similar to WMDP link above:

We specified that we want to open the Display (which is the default) menu item SysTableBrowser, passed in an argument TableName WHSWorkTable. We also specified the company, as before, as as well the display language. We've also added in the limitednav=true flag, which removes some of the navigation panels and buttons, so you cannot navigate away from this page to another form or menu.

Technical Note. Check out UrlUtility.getQueryParamValue('TableName'); This could potentially be used in some of your customizations

Monday, September 19, 2016

Tutorial: Dealing with rush orders or the skill of "Ship now" in Dynamics AX


Quite often, situations happen in supply chain which require the warehouse to handle rush orders, meaning that they need to ship the same day, if not immediately.
At the same time, the normal levels of data accuracy are still expected, meaning workers cannot just ship the goods without simultaneously registering everything in AX, as to not allow the data to get out of sync with the real world.

But, even though this situation is quite common, Microsoft Dynamics AX does not handle it quite that well. Specifically, once the work is created, you can't ship the load until after all work has been executed, including any intermediary stages (quality inspection, packing, etc.)

An alternative scenario is when delivers to a customer are done on a regular basis, using a third party logistics provider like UPS for deliveries, and per agreement their transportation vehicles depart from our docks at a particular point in the day. In such cases the workers may get instructions (or make the decision on their own if experienced) to skip certain picks and just ship what has already been picked, just to make the cutoff time. The remaining goods would be then shipped with the next planned delivery.

Today I would like to show one of the possible ways of achieving better results in the above scenarios with the out-of-the-box functionality in Microsoft Dynamics AX by showing two features:

  • Skipping non-mandatory work lines
  • Short picking without impact to the inventory but with load line qty reduced


I have created the following sales order in AX, which turned out to be a rush order, so I need to avoid the staging step I usually go through when picking such items, and instead, take the items directly to the bay door, where the truck is already waiting.

Note. For the purpose of the demo, I only have 2 items and no prior picks completed.

Rush sales order
The sales order has already been released and the work looks as below:

Open Work order
Now, since I want to rush this order, I am going to skip the staging step. How do I do that?
Well, for this to work, the corresponding lines in the work template used to create this work must have been set up as optional (Mandatory flag was not set)
Luckily, that was the case for this order, so I can move on to step #2, actually skipping these lines.

That is done from the Load by selecting the "Skip non-mandatory work" button, as shown below:

Load in Waved status with "Skip non-mandatory work" button
Note. You can only skip non-mandatory work on an order in Open status right now

Now the work looks like below. Note how the work class has been updated to enable the initial picker to load the goods as well

Open work order, where staging lines are skipped

OK, so let's execute this work now. We'll use a standard mobile device menu item with user directed work execution method.

The worker picks the first item from the picking area very close to the outbound dock, as shown below.

Initial pick instruction from a Picking area

However, the next pick he's instructed to make is in the bulk area, as nothing was left in the Pick area and the item has not been replenished yet.
Walking over to that area takes a whole 30 minutes, and John knows that he needs this order to ship in 10, so he makes the decision (or is called by the warehouse manager with instructions) to not ship this item now, but do it the next day or whatever the agreement is with the customer.

For this, he's going to short pick this item. Since we are not going to pick any items, he'll enter the quantity of 0, and select the reason for short picking - Ship Now, which we'll talk about in a minute.

Short pick with reason = Ship Now

After confirming the short pick, he'll immediately be asked to put the items he did pick (in our example just 1) to the BAYDOOR location, since we skipped the other lines

Put directly to Baydoor

As a result, the work looks like below:

Work in status "Closed"
All work lines have been Closed, and as you can see the remaining quantity is 0 for both picks, and for one of them the work quantity is also 0, since that was the line we short picked.

Now, hold on, you might say. I do not want to short pick these items - does that not tell the system that the items are actually not there, and in many cases adjust them out or create cycle counting work? 

Not in this case. See the setup I have done for the Ship Now work exception below:

Short pick work exception "Ship Now"

As you can see, I have not selected to create cycle counting work or adjust these items out. All I selected was to Automatically decrement shipment or load

What that means is that on-hand will not be impacted in any way, however the quantity on the respective load line will be decreased, essentially taking this item off the load. Note that the source document line (in this case, sales order) is not impacted, since the customer still expects those goods. We do not currently support also reducing the quantity on the sales order. You will have to use the "Deliver remainder" function from the sales order line explicitly to achieve that.

So, let's take a quick look at the load now.

Load in status "Loaded", where 1 line has 0 qty
As you can see, the status of the load has been updated to Loaded, meaning all the goods planned for this load are on board. 

You can read more about the various statuses of the Load/Shipment in my previous blog post:

 That means we can now ship this load, as shown below:

Load in status "Shipped"

Hope this will help some of you avoid unnecessary customizations

Let me know if you have any questions.

Sunday, September 18, 2016

The Cloud, what it all means and how it applies to Microsoft Dynamics AX

The ERP world is changing rapidly due to to cloud implementations as there are big differences in implementing and running the business in the cloud versus on-premise.

There is a lot of talk about what IaaS, PaaS and SaaS can offer a company, but these are never well described, and I have seen a lot of people being confused about what each of these actually means / does for a company.

Today I read a nice short description of the benefits you get with applying IaaS, PaaS, SaaS that I wanted to share:

  • IaaS - Infrastructure as a service. This allows for the sharing of raw computing power and storage, including such pieces as databases, rules engines, processing power and other infrastructure capabilities. With cloud these can be accessed and leveraged on an “as needed” basis. Similar to the power grid, you pay for what you use. IaaS is what the corporate IT department needs to enable your day-to-day tools to operate with reliable and fast response
  • PaaS - Platform as a service. This allows developers to access tools to create their own applications. The building blocks are made available by the software vendors to provide a jump start on development. PaaS is what your supply chain IT support or third party consultants use to create customized workflows or tools specific to your needs
  • SaaS - Software as a service. The business process application (“solution” in vendor-speak) layer in the cloud. Users can rent applications on a per use basis to tackle specific business issues. SaaS is what you log on to use without any customization.

The current version of AX, released under the codename "AX 7", provides infrastructure and platform as a service, and you could say software as a service for many of the small and medium businesses. Partners have been active filling the gap with their custom solutions available through the Microsoft AppStore.

Note Historically AX has been a favored development platform so many would buy it with the purpose of customizing the logic to match the exact needs of the business, instead of attempting to configure it "the right way" and adjust their business processes. In my opinion that hinders the adoption of AX 7 a bit, as it made it a bit more difficult to re-tailor it as they see fit.

With future releases of AX, I'd expect to see Microsoft converge more and more into providing a rich business SaaS offering. I am excited to see how much closer the release of Dynamics 365 will bring us to this goal.

What's your opinion? Do you agree with the definitions above and how they apply to AX?