Towards the deconsolidation in Dynamics Warehouse Management

Towards the deconsolidation in Dynamics Warehouse Management

The deconsolidation (opening of a complex packaging, quality control, taking small packages out of the larger packages announced by the supplier of the goods via ASN) seems to be a well-established process in SAP EWM, yet the implementation in Dynamics for SCM, its WHS module may turn cumbersome. Below is the workflow one may configure in Dynamics WHS out of the box:

Deconsolidation workflow

It all begins with an Advance Shipping Notice transmission and import. The invaluable – and only available – source on this topic is located here: Processing of inbound ASNs in Warehouse Management in AX ‘7’ (kashperuk.blogspot.com). The ASN creates an inbound load and a packing structure for a Purchase Order in Dynamics. I identified 2 distinct scenarios:

  • Multi-SKU: The packing structure contains multiple items in one single box (or on one pallet). Here one needs to understand that the Import project in Dynamics Data management must still be “pre-conditioned” with an XML file containing nested cases (boxes) and all 6 entities in the composite entity “Inbound ASN” even though the real message will not be using either the WHSInboundLoadPackingStructureCaseEntity (representing the nested license plates i.e. packing structure cases) nor the WHSInboundLoadPackingStructureCaseLineV2Entity (the one with the items in the packing case). My file for the pre-conditioning is here: InboundASN_ASNEntityConditioning, while the real message can be stripped down to 4 entities
    the load Id
    … the purchase order(s) in that load
    …… the parent license plate(s)
    ……… the content of the license plate
  • Multi-case: the ASN contains a packing structure (max. 1 level of depth) where the boxes (packing cases) are on the Parent License plate (i.e. pallet or master box), and the multiple items are in their own cases (boxes). An example is here: InboundASN_NestedLPCase. Let’s state one thing straight: the process does not work in this scenario. Let’s explore, why.

Nested LP (multi case) scenario

Once the ASN has been imported, navigate to Warehouse management > Loads > Open loads, then open Ship and receive / Packing structure:

The cases (aka nested license plates) 00708581a and 00708581b are on the parent license plate 00708581 and contain the items. Use the Mobile menu item License plate receiving to process this ASN. It displays the list of the items and let the parent and the nested license plates emerge at the default receipt location (here: DOOR). The system registers the parent and the nested LPs all right, but the stock of the items is on the parent LP only!

This fundamental flaw in Dynamics is well documented here: License plate receiving via the Warehouse Management mobile app and therefore becomes a ‘feature’, not a ‘bug’ 😉 They further suggest using a Pack to nested license plates indirect menu item to distribute the stock over the nested LPs in accordance with the ASN, but here is how it is going to end:
Pack to nested license plates

This action culminates in an “insufficient on-hand” error, because the moment you receive the parent LP, it generates the put-away work and reserves the whole freshly received quantity for the same. The stock cannot be moved (because this is what the Pack to nested license plates really does: creates a series of movements between the parent and the nested licence plates).

The typical approach is to let the put-away work be omitted with a Work policy, or be automatically performed for the stock to stay at some logical staging location right after the receipt. The split nested LPs are then distributed into the main storage with a Movement by template menu item. However, a movement by template does not support either the Disposition codes or the Quality management (Quality management for warehouse processes – Supply Chain Management), because both the QC methods are only allowed for purchase orders and production orders, not the movements. This essentially rules out the standard WHS quality control.

The only viable solution is to elevate the cases to parent LPs in the ASN interface, i.e. to convert nested cases to multiple “parents” of their own. This effectively reduces the nested-LP scenario to a multi-parent, multi-SKU one:

Multi-SKU scenario

The list of the Cases in the Packing structure is empty now; instead, one or many parent license plates contain one or many items each:

Now, the secret of the proper work processing, deconsolidation and the proper location determination is the staged Work template for the purchase order receiving process:
Location DOOR → DECO → Final BIN or bulk location

The DOOR location is considered the staging area before the deconsolidation, while the DECO location (injected by the Directive code = Stage in the work template / location directive) is the staging area after the deconsolidation where the put-away work is sorted and clustered for further processing:
Purchase order work template
The process needs 3 mobile menu items: License plate receiving – Work (one Work class ID) – Work (another class ID).

The Print work type here substitutes the Print checkbox on the menu item, because the latter is printed earlier when the parent LP is at the DOOR while it is considered a Multi-SKU license plate: it is going to be printed only once and the item number and the location are going to be empty. Also note the Stop work break after the deconsolidation part (lines 1-4) to interrupt the flow at the DECO staging location and transfer the duties from one warehouse team to another.

The second piece of the puzzle is the Work header break by the Item number: it will create as many work headers as there are items, all for the same parent LP, with a unique final Put location each. This location is nicely printed on the label, along with the Item ID, i.e. we have successfully reduced a Multi-SKU case to a single-SKU one to locate a unique bin by item.

At the deconsolidation station, the same parent LP is scanned over and over again and it randomly directs to the next open purchase work = item to be taken out from the parent LP. A quality control is nicely tied in (however, the ASN quantity as a whole may be either accepted or rejected; a single damaged piece may only be split in a separate movement process at a QC location if fully rejected first):
Deconsolidation process

The last piece of the puzzle is the Generate license plate option at the menu item for the purchase work processing:

It replaces the ambiguous Parent LP number with a fresh unambiguous LP number (see the Confirm target license plate step above). The same is used by the “put-away people” to initiate the final movement into the destination bin / bulk location (lines 5-6 in the Work template):
PO put-away process

Bingo!

The last trick may be a batch job (Warehouse management > Periodic tasks > Change inventory status) updating the Inventory status from Blocked to Available in every bin, bulk, floor location every 2 minutes. The reason is a potentially early reservation of the goods in the receiving / staging locations while the quality inspection might not yet have taken place. The sales order location directives consider the regular bin/bulk/floor locations only, and the reservation in the receiving area results in an empty Pick location in the outbound work. Use the setting Warehouse management > Setup > Inventory > Default item status to enforce the Blocked, non-reserveable inventory status upon all purchase orders. With N items from M suppliers this requires N*M lines in that form, unfortunately 🙁

Auto-post inbound delivery notes in a batch

Auto-post inbound delivery notes in a batch

In order to register a manual or an OCR purchase invoice, the accountant should match the quantity against the delivery notes (en-us: packing slip) captured at the warehouse. But what if the inbound area is only equipped with mobile scanners? What if we do not have the carbon copy on hand, or just don’t care about the printed document at all? The shipment may be damaged or incomplete! Indeed, we should only pay for what we’ve physically received:
Register the actual quantity → Post the ‘Product receipt’ with that quantity → Match the invoice against the same → Claim the difference from the supplier, if any.

However, when registering the said delivery note against the purchase order with the Generate / Product receipt button or the respective periodic task, the user must provide the delivery note number as written by the supplier of the goods. This makes an automation with a batch job at the first glance impossible, because it requires human interaction.

Update product receipts

The automatic job Warehouse management / Periodic tasks / Update product receipts is the remedy. For every inbound load within the given constraints, it creates and posts a delivery note aka packing slip with the total registered quantity.
The inbound load does not necessary require any active management. The load may be…

  • Created manually out of the purchase order lines in the Load planning workbench
  • Imported from an ASN, but also
  • Added by the system automatically if the parameter Automatically create at purchase order entry is turned on


If the load is not confirmed, the Update product receipts will confirm it automatically first, then promote to the final status Received. The bogus delivery note number is like LOADID_N, where N is a running number. The quantity is the registered quantity versus the respective load line(s). It does not matter how the registration came about:

  • Mobile scanner PO line/item receiving or PO line/item receiving and put away
  • Mobile scanner License plate receiving or License plate receiving and put away [against an ASN]
  • Mobile scanner Load item receiving or Load item receiving and put away
  • Mobile scanner Mixed license plate receiving or Mixed license plate receiving and put away
  • the new simplified License plate receiving: license-plate-receiving-enhancements
  • the classic inventory Arrival journal
  • and last but not least, the classic Registration at the purchase order line level.

In essence, you just scan the last pallet of the PO and forget. At the end of the working day (or faster, depending on the batch job schedule) the system will process every In process load (i.e. where the receipt of at least one pallet has started) and make as many delivery notes as needed to update the purchase orders.

More on inbound loads

The only limitation is the use of the advanced Warehouse management processes at the warehouse, i.e. the inbound load may only be created at a WHS-enabled warehouse. More on inbound load handing here: https://docs.microsoft.com/en-us/dynamics365/supply-chain/warehousing/inbound-load-handling.

The recent features “Associate purchase order inventory transactions with load” and “Multiple product receipt postings per load” may be beneficial.

Revenue recognition with project budget shadow forecasts

Revenue recognition with project budget shadow forecasts

Recently I came across this: Idea: Automaticaly update the total forecast when budget is revised and I thought it is time to share with everybody my sacred knowledge in Dynamics 365 for Finance: the use of project budgets in the fixed fee project planning and revenue recognition. I encourage all my customers to consider the project budget as the only UI to maintain and keep the history of forecasts.

Introduction

It seems that the regular project review is the best practice in the construction industry and in the complex engineering. Once a month the project manager assesses the project progress, extracts the current actual cost, evaluates the cost “burn rate” and produces an Estimate at Completion (EAC), which is the forecasted cost of the project at its end. The new EAC is compared with the original (baseline) project forecast. The baseline (or the last adjusted) forecast is copied, updated and becomes the most recent forecast of the project:

Current Project Forecast := EAC

The ratio of the actual costs (Inception to Date, ITD) to the Project forecast is the new estimated Percentage of Completion (POC) of the project:

POC = Actual_cost_ITD / EAC = Actual_cost_ITD / Current_Forecast

The Estimated to Complete (ETC) is the forecasted cost still to occur:

ETC = Current_Forecast – Actual_cost_ITD

For a “Fixed fee” project, the contract amount is fixed and the current estimated revenue in line with IFRS 15 can be calculated as

Revenue to Date = Contract amount * POC%

In Dynamics 365 for Finance, the process of the PoC estimation and revenue recognition is called an “Estimation” (About estimates | Microsoft Docs), the forecast is called … well, a Forecast, and the actual cost is recorded by the Project posted transactions. The percentage of completion revenue recognition method is called Completed percentage in the Project group:

The problem with the D365 forecasts is that

  • There are three of them: Hour forecasts, Expense forecasts, Item forecasts. There is a view All forecasts, but it is not editable.
  • There is no facility to aggregate forecasts, e.g. Item IDs → Item Project categories
  • There is no adequate tracking of forecast revisions other than with the static forecast models (‘Jan’, ‘Feb’ and so on).

Basically, the project forecast UI in Dynamics 365 for Finance is unusable, but there is a trick:

Project budgets

In one form Project budget one can manage all 3 types of costs: Hours, Expenses (procurement category-based costs) and Items (costs for stocked products). To start using the project budgets, activate Use budget control in the project master (and project management parameters) and make sure that the Project budget number sequence is set. Independent budgeting… is advised. There must be an [automatic] budget approval and budget revision workflow configured, too.

The planned hours may be quickly Imported into the project budget from the Work breakdown structure with an aggregation by the project category (i.e. reduced by the WBS Task IDs).
One useful feature is missing: an ability to import Item requirements and compress them by the Category ID. Anyway, a project budget by category may be entered in 2 minutes, while maintaining the project forecasts for the same in 3 different forms may take 20 minutes.

There is an instant totals calculation. There is a (mandatory) approval workflow, which is a common process in large engineering companies. There is a strong history of Revisions and a workflow for their approvals.

Here comes the surprise: on an approval in the Workflow, the project budget [revision] creates 2 shadow forecasts (“original” and “remaining”, here: PRJ-O, PRJ-R) you can use in the PoC calculation or elsewhere.

The “original” forecast is what was called Current forecast or EAC above: on any project budget [revision] the Original forecast is updated with the budget values.

The “remaining” forecast is what was called ETC. I do not consider it useful, because the actual costs ITD to be subtracted from the “Original forecast” are taken at the moment of the budget revision approval. However, if the burning rate lays within the predicted limits, there is no practical need to make or submit a new project budget revision, and the Remaining forecast becomes outdated. There is an ability to update the Remaining forecast on-line by choosing the forecast model (here: PRJ-R) in the Project management and accounting parameters, but I do not recommend that: this online update on every project transaction seems to be buggy and brings errors and warnings across the whole system.

To create the PRJ-O and PRJ-R models, use the Project management and accounting > Setup > Forecasts > Forecast models. Choose the Budget type = Original budget or Remaining budget, respectively, otherwise you won’t be able to pick the models in the Project budget form.

However, if you do, so, the model becomes automatically Stopped. This will prevent it from being mis-used in the revenue recognition later. You should use the trick of exporting and updating them in Excel: Overwrite a read-only configuration in D365FO.

To display the shadow forecasts once the budget [revision] is approved in the workflow, remove the default filter Budget type = None in the forecast form(s):

The Cost price = Total budget = Original budget + Approved revisions. The shadow forecast models only work properly with amounts but not quantities: the quantity in the forecast is always 1. One can enter a budget line, and click Details then break the hours into multiple lines for different resources, but they are rolled up and applied as 1 hour for the total Budget line amount. There are some bugs with regards to hour indirect costs too.

Revenue recognition (estimation)

To use the ‘shadow forecasts’ in the Project Estimation, configure an appropriate Project management and accounting > Setup > Estimates > Cost template and Cost lines:

The Cost to complete method must be Total forecast – actual, because we will be hijacking the “Original forecast” PRJ-O. Tick Percentage of completion where appropriate. In the construction industry the Item line may be de-selected. As the great Rav Lal once explained to me, “Having all the materials delivered to the construction site doesn’t mean the house has been erected”.

If you don’t want your users asking for the right forecast model every time, pre-populate the revenue recognition periods (Project management and accounting > Setup > Timesheets > Timesheet period types, button Periods) with the Model = PRJ-O.

The proper estimation mode will be then From cost template – From cost template – PRJ-O, unless for the last estimation at the end of the project where Cost to complete method = Set cost to complete to zero.

Data migration

The only area where the project budget falls short is the data migration. As of today, there are no entities for it. For the total project contract, you can use my voodoo practice Electronic reporting for data migration
For the forecasts, there are 3 entities:

  • Project hour forecasts
  • Project expense forecasts
  • Project item forecasts

If the number of projects is low, import the 3 parts of the forecast for each project, scroll the projects one by one, click Project budget→ Import from Forecast → OK → Workflow → Submit. An experienced PC gamer with nimble fingers or a trained Tinder millennial may process up to 200 project budgets per hour. A larger volume may require a X++ job.