Advanced Warehouse Management in Ax is a great thing, but like any newer feature set, it has some issues that will take time to work out. Let’s put on our technofunctional Architect hats and walk through a challenging case that I recently encountered for a client. A lot of times what I find with newer Microsoft features is that the “bugs” aren’t so much from non-working code that somehow passed testing but from people using features in ways that weren’t anticipated. Such is the cause with waves and Advanced Warehousing for example. Let’s take a look at an example very pertinent to many implementations right now and save a reader or two some precious time on getting it resolved.

Problem Scenario: Production Orders Start times were highly variable. It could go from seconds to several minutes to start 2 or 3 production orders at the same time by checking a few of them on a list page and starting the production order. What was the culprit?

Initial Findings: I quickly noticed that variability in time was not based on the number of production orders so much as the number of BOM items that go into making the finished product that the production order delivers. 3 Production Orders with less BOM Items than 1 big Production Order would perform faster.

Look first at the pattern and see if you can spot what’s wrong with the default advanced warehousing code. Then, I’ll post a marked up picture in the screenshot right below it.

Getting our experienced Architect “EYE” on

Now, look Again with the markup. If you are new to the art of being able to diagnose implementation performance bottlenecks, don’t worry. Experience will teach you quickly.

So, for the first thing not shown here, I found issues with the default BOM costing calculation process. I can’t show you that though because not all of the methods are vanilla MS code and some are confidential to my client. So, for this part of the series, I found issues with the waves.

PUTTING ON OUR FUNCTIONAL HATS FOR A MOMENT: EXPLAINING WAVES à Why are they such a big deal????

Waves are the rage amongst supply side management people at the moment for good reason. Before this, people would have to customize that functionality in AX. Now, here is why they are important.

The best way I can explain it is from my days as a Walmart truck unloader. We had 3 guys who would do the unloading on any given shift for the storage area of a Walmart store back then. It was over 100 degrees during the summer and we wanted to finish fast because it was hot as hell. What we learned is that if you put all three guys in the truck to remove boxes, things would actually slow down. It was faster to have one guy in the crowded truck removing boxes. He would then hand off to another guy on the floor taking the box from him. And that guy would drop things off in a space close to the trucks, where a third guy would be responsible for picking up the boxes and walking them to their respective storage containers. In other words rather than have one person do everything(unloading and stocking), we learned it was faster to separate the duties to efficiently utilize space.

Such is the concept of the wave. You break down specific activities into designated areas of the warehouse to use space and personnel efficiently. A worker pulling 50 items off a 5 foot shelf in one operation is going to be faster than a worker walking all over a 50,000 square foot warehouse to pull 30 of the same items from who knows where. Waves give us the ability to aggregate our activities in the warehouse.

THE FUNCTIONAL Implementation of Theory:

Since Waves really are just a fancy term for performing Aggregated activity within designated areas of space, let’s see how they are implemented in AX.

In AX, we have Wave Types. This is the type of Aggregated Activity that you are engaging in, such as picking (somebody pulling stored items out of the warehouse). We say that we have a wave template which guides us on the top of the wave we’ll be creating plus the site where it can be created, plus any special rules that apply to that wave.

So, what happens is that someone who really understands the business starts to plan waves or the activities that will be available in certain areas. For example in Warehouse 51 at site 5,we will have an aggregate pick rubber wave. So, if someone submits 50 Production orders, we know that we can pick all of our rubber from there for example to make whatever they want. Or we might store more than one thing at the place. Companies do stuff differently.

WAIT, SITE AND WAREHOUSE aren’t specific enough!!!!!!!!!!!!!!!!!

No problem Says Microsoft.. We got this. Introducing the ability to add query criteria to your wave which gets as specific as you want when choosing how the wave will apply to a certain area.

Notice here, I went down to the item. I actually told the wave to only apply to some item that I was going to choose. So, you could have a thousand waves at a company when you think about all the big warehouses or complicated manufacturing scenarios at there.

RECAP BEFORE WE GET OUR TECHNICAL ON:

I’ve hinted that there is a classic technical challenge with waves from an architecture standpoint. It’s easy to code something if one is specific enough in knowing what they want, easy to also code for performance. But it’s these sorts of cases where you have to accommodate dynamic choices where it gets hard. Your Wave will be created based on the template that is too apply. We say that the data retrieval logic is “Dynamic” in that it is chosen at run-time. Technical people know that Dynamic Data Retrieval means to be especially cautious about performance. On part 2, we’ll see how this induces a nightmare looping scenario for large clients or highly complicated manufacturing plants on the technical end bringing their precious wave dream scenario to a startling nightmarish performance situation at present (note: this will probably get a hotfix after the next blogpost). Then, we’ll see how a good old fashioned techno-Functional agreement can fix it with less than 5 lines of code. J Till the next post – Part 2 on Waves..

Assignment to think about:

Review this post.. see if you can conceptualize why dynamically choosing amongst a possibly infinite number of aggregate activities at run-time is bad (aka querynew object if you look at the picture above) than you are starting to get a feel for the sort of thinking cap, you’ll need to tackle the occasional issue in AX. I have friends who are in SAP, JD Edwards and other ERP systems. The occasional performance issue is not unique to AX and is usually a result of an inherent assumption gone bad – this one, that we can dynamically choose our data retrieval logic at run time from a near infinite realm of possibilities – is a classic problem that introduces combinatorial issues behind the scenes. AX will go through each and every one of the waves setup for a particular type until it finds the right one for each bom item. Thus, number of operations to determine data retrieval logic to use at run-time is possibly the( number of BOM items times) * ( the number of Wave Templates available for a site and location). Large or complicated warehouses will feel that multiplier with severe performance..

Till the next post – the technical aspects of it plus the solution to make AX all better again and make our waves act nicely.