In the recently released CU10 update we are introducing a few new replenishment features that will increase warehouse productivity and save effort and time. This blog post will take you through the details of the features and for which scenarios they are aimed for.
In this blog we will cover following:
Relation between replenishment work, demand, and cancelation of the demand.
Directive code capabilities on work template for replenishment
How did it work previously, and what was the challenge?
In Microsoft Dynamics AX 2012 R3, min/max replenishment and demand replenishment did not recognize one another, and both types of replenishment did not recognize existing replenishment work that was in progress or not started yet. Sales demand and existing replenishment work generated for the demand, did not know each other’s status.
That resulted in the following 3 problems and possible obsolete replenishment work transactions and waste of time in the warehouse facility:
If we had let’s say sales demand work of 10 each, and demand replenishment setup has generated replenishment work of e.g. 1 Pallet (100 each) due to setup and that replenishment work is not yet processed. If new sales demand of 10 each comes, what will happen is that demand replenishment setup will again generate the new replenishment work of 1 Pallet (100 each) due that there is no increase in quantity. In this case we will end with 2 work with 1 pallet on each that in total is 200 each and in total sales demand is only 20. This tells us that second sales demand could have been covered with the first replenishment work due to that there was 90 each not yet reserve.
Many customers will run min/max replenishment in the morning as a batch job, and generate a series of replenishment work to fill up their locations. Before CU10, what was happening is that if min/max replenishment work was not processed before demand is sent to the warehouse, demand replenishment as the exception management will create new replenishment work for the demand. Result will possibly be, that we will have two replenishment work generated using two different strategies, min/max and demand replenishment. However, if the demand replenishment was aware that there was the existing min/max replenishment not started with free unreserved quantities of item with same dimensions there would be no problem.
The other problem was that if e.g. sales demand triggers generation of replenishment work, and replenishment work has not been processed, but sales demand work is cancelled and sales order line deleted, replenishment work will still stay open. This challenge potentially resulted in replenishment work being open that are not needed or even will not fit at the locations due to that demand being cancelled.
All of the above was potentially creating noise and unnecessary open work transactions, overload of the items on the target replenishment locations, or a huge manual workload to synchronize demand and open replenishment work. For any warehouse facility with large number of locations that are either being replenished with min/max or/and demand replenishment, the above challenges are not acceptable.
What was our goal?
Create awareness and link between different types of open replenishment work.
Cancel the existing demand replenishment work that has not been started if the demand has been cancelled and there is no other demand work related to replenishment work.
Deduct new demands from existing min/max or demand replenishment work in order to minimize amount of work transactions, if there are unreserved quantities on the existing replenishment work. First after all available quantities is deducted new replenishment should be created.
Make setup flexible
How did we solve above challenges?
In the new CU10 update, the replenishment setup for both demand and min/max replenishment, we have added the ability to define if the replenishment template, from generated work, will allow unreserved quantities to be used and deducted from by new demand quantity.
In the same setup we have added the ability, to define if the replenishment work should be cancelled if the demand has been cancelled (please note that if there is any existing work that is related to that replenishment work it will not be cancelled).
In the above setup all of the replenishment work generated and not processed will include new demands if the unreserved quantity allows. After all is used and deducted, new replenishment work will be created if needed.
In same way, if there is a min/max replenishment template that is configured to allow demand to use unreserved quantities, and has generated work, even if demand replenishment method is enabled it will first see if any of the quantity from existing work can be used.
This minimizes amount of the work lines created, where quantities can be deducted from existing replenishment work.
Please note that setup is template centric, which means that we can allow deduction and cancellation on one, but not the other template.
Directive code enabled on work templates for replenishment work order type!
In CU10, we have also enabled configuration of the directive code for replenishment work order type.
Continue to second replenishment template sequence capability if put location is not resolved in previous sequence line!
Before the CU10 update, having several sequence lines in the Replenishment template lines where first one could not solve the demand, system was not continuing to another line sequence. This only counts if PUT location could not be resolved due to a location failure or stocking limits.
Now if the first sequence line fails to resolve put location and fulfil replenishment, next line in sequence will be processed.
Please note: In order to proceed to another replenishment template line, you need to setup Location directive failures to stop work on Replenishment failures, as shown below. If not set, it will end with an empty put location, and will not proceed to next sequence line in Replenishment template.
This feature is useful if we e.g. have stocking limits on a locations or locations fail for some reason due to other restrictions or setup. In that case system will proceed to another template and use put from location directives connected, that could be as for example an overflow location.