Practical experiences on implementing the (WHS) warehouse module – Consolidating shipments

We recently went live with a customer on AX (it was a 2012 R3 CU10, below I have illustrated the learnings on AX “7”). The customer who is a producer, distributor and retailer of jewelry and luxury goods decided to implement their warehouse operation in the WHS warehouse module. The daily operations were hundreds to thousands in peak season of individual parcels shipped with different third party vendors from their different transport hubs. The transportation decisions were setup for automatic decision so in other words Loads and load planning were not relevant

A key requirement for this customer was the ability to consolidate sales orders. The item catalogue consisted of both standard shelf products and on-order products because of this partial release of sales orders were a fact of life and a typical B2B shipment would normally contain sales order lines from quite a few sales orders.

The “Consolidate shipment at release to warehouse” (on the Warehouse management>Setup>Warehouse>Warehouses) were because of the above set to Yes.

Now it is important to understand what this parameter does. The code that controls consolidation of sales orders is located in the WHSWarehouseRelease.createShipments() method. In short the code first creates the load lines (think of these as a copy a sales order line plus some additional warehouse specific fields) and then iterates through all the load lines that are released.

The initial way that AX splits a set of sales orders identified through the query in: Warehouse management>Release to warehouse > Automatic release of sales orders is located in line 148 to 166 in the above method and the only strict criteria of when two shipments will be created instead of one is if two lines have different warehouses. If a given set of sales orders requires to be split further on some sale line or item attribute individual “release to warehouse” (batch) jobs have to be made.

Note that all lines that are being evaluated for consolidation are lines that currently have no shipment id plus the code looks only in a temporary list of shipments that gets populated in this single instance of release. In other words, this mechanism does not work over different “releases” of lines, a sales order that was released yesterday will not combine with one that is released today. There are hints that a broader consolidation was in mind but this must have been forgotten (why else would there be the line 191 below).

In line 186 to 194 we have the use of the consolidate parameter, line 192 and 193

In essence we either split for each individual sales order or not if the consolidate parameter is set PLUS that a sales order line has to have the exact same delivery name, address, warehouse the mode code is an attribute on the carrier (related though the mode of delivery of the sales order line) so it is not possible to combine two orders if one is for example a ground delivery and the other is a TL/LTL. I do wonder at the reason that I will forced to combine two different services (UPS standard and expedited) from one carrier but have the option of combining two different carriers as long as they are within the same segment.

The end result can be validated by creating two sales orders and release them simultaneously using the “Automatic release of sales orders”. Note that the order number field is blank on the shipment itself and in the below example I have personalized my load lines and added the Order number to see that each line comes from a separate sales order:

The missing order number on the header of the shipment makes sense but it seems to be a forgotten (poorly tested) scenario and from the top of my head the container content report and the sales order line to shipment button does not work when the shipment looks like this.

In the next post I will dig into merging and splitting works based on different attributes in combination with using the Pack functionality

About us

Pingala is an ERP consulting and development company with in-depth expertise in Microsoft Dynamics AX. All our consultants have more than 10 years' of experience in Dynamics AX.

At Pingala, we have a broad understanding from idea through implementation to identifying areas of improvement and bottlenecks in live system as well as deep knowledge of all practical and theoretical aspects related to IT projects.

We are specialists in process improvement and we work at several levels from consultancy, architectural assistance to practical optimization. We have a wide experience in all standard AX modules ranging from deep to world class.

About the author

David has 15 years of AX experience, 12 of which was in the Microsoft AX Development team in a role as Program manager across multiple teams/features areas. David has designed a large range of features, functions and modules that are a part of standard AX today. Leaving Microsoft in 2013 to become an AX consultant David has participated in a range of customer implementations with primary responsibility for areas such as Warehouse management (WHS), Project/Service management, Sales&Marketing, Procurement, Time&Attendance/ME/T&A Payroll, Product information management and more