Suggested by Simon Martinsson – Needs Votes
A customer that we work with has a great amount of sales orders going out each day and the confirmed receipt dates are used to communicate when the end customer can expect their delivery. To generate a confirmed receipt date, the ATP or CTP for planning optimization delivery date control methods are used, depending on the item settings.
However, when an item is set up with delivery date control = CTP for planning optimization, there is a big chance it will cause issues for certain end customers based on the below scenario:
SCENARIO
Available on hand: 43 pcs for item A (No ordered or on order transactions at the time). Item A is a BOM component.
ORDER #1
Created: 20241107
Requested ship date: 20241201 (future requested date)
Requested receipt date: 20241201 (0 days of transport lead time, this doesn´t really matter)
Quantity: 43 pcs for item B (Item A is included in the BOM)
After running the CTP for planning optimization, the confirmed ship date will be 20241201 since the available on-hand fulfill the required quantity.
ORDER #2
Created: 20241107
Requested ship date: 20241107 (today´s date, as soon as possible)
Requested receipt date: 20241107 (0 days of transport lead time, this doesn´t really matter)
Quantity: 10 pcs for item B
After running the CTP for planning optimization, the confirmed ship date will be 20241107 since the requirement date on order #2 is before the requirement date on order #1, even though order #1 is created before. A planned purchase order is then created to fulfill the remaining quantity for order #1. That means in theory that order #1, which we promised to the customer at 20241201, no longer can be promised on that date because the planned purchase order might take longer time to purchase and receive, and the MRP will suggest a potential delay for order #1.
The idea
It would be valuable if the CTP for planning optimization can respect the created date and time of the order line or ultimately respect when an order line has a confirmed delivery date. In the above case, such an improvement would mean that the quantity for order #1 is protected since the stock is allocated to the order line prior to order #2.
The above described scenario is for sure causing a negative impact for a customer that is placing a sales order well in advance, or basically any future requested date. The promised date to the customer might not be fulfilled since the system is generating new proposals based on the requirement dates with the current functionality.
Status Details
Thanks for your input! If it gets voted, we will consider revisiting this scenario.
Note that this issue is not only specific to "CPT for Planning Optimization" but you will also find it for "CTP" with both Planning Optimization and the deprecated planning engine.
When you promise a date to your customer, unless you do reservations, it is not ensured that the materials have been reserved and the capacity has been booked. It will always be the way planning works by planning from required date and trying to minimize delays.
Best,
Beatriz Nebot Gracia
Senior Product Manager, Microsoft
Looks good! :-)
Very good idea!
A supplementary function or parameter setting could be useful to not unnecessary "lock" the on hand components too far ahead, like a CTP fence. E.g if order line #1 is requested very far in the future and the lead time of the BOM component, Item A, is shorter than the requested date of order line #1 it would be unnecessary to lock those components for the future order line only, instead of being able to fulfill both orders up on each customers request.
It would be good with some options :
Would be good to be able to set this as a default parameter, but also as an overriding value of each single product to be flexible.
Very good idea!
A supplementary function or parameter setting could be useful to not unnecessary "lock" the on hand components too far ahead, like a CTP fence. E.g if order line #1 is requested very far in the future and the lead time of the BOM component, Item A, is shorter than the requested date of order line #1 it would be unnecessary to lock those components for the future order line only, instead of being able to fulfill both orders up on each customers request.
It would be good with some options:
Would be good to be able to set this as a default parameter, but also as an overriding value of each single product to be flexible.
We definitely need this. The main reason our customers cannot use both CTP and Batch CTP is that the confirmed orders are being delayed, while CTP priority is the new demand with an earlier requested date.
Hi Annika,
currently dynamics locks the on hand components even if you enter a new sales order line with a earlier date. You have to do a full run. With CTP and also with CTP for planning optimization a newly entered line is added on top of the last run. That´s why you cannot run "simulate delivery dates" until the next periodic planning optimization run has been executed.
This makes sure that delivery date control always takes all other demand into account to find a sutiable date.
@Simon, how about making a reservation for order 1. Would that solve or at least improve your problem?
Thanks for your ideas and feedback.
Ben
I would like to suggest ADDING another method: Leave CTP (Capable to promise) where it is, focused on earliest date, and add CATP (Capacity Available to Promise) that will not steal capacity from already Confirmed sales lines, even if they have a later date. Thoughts?
The issue is perhaps not so much 'CTP' but rather limiting 'Planning Optimization' from 'Optimizing'. The engine now tries to optimize and use existing supply and on-hand for the first orders that need to be shipped. There is no decent way of allocating a specific (firmed) future supply or on-hand to a specific demand besides either marking or reservation. But in a distributed supply chain, it's not so evident to mark or reserve.
The recent addition of 'Keep pegging for approved planned orders' is only working for planned orders. But once firmed, the pegging is not maintained leading to the issue described above.
Using 'batchid' as 'coverage planned' dimension can help in tying supply with demand but you may run into issues in case you want to configure Item coverage for these items as this in not supported at the moment. Therefore, support for itemcoverage for batchID in coverage planning could also be a solution to this issue.
@Simon Martinsson
Hi Simon,
I know this is an old case by now, but i hope you can help me out with a question.
I see that a few months ago, microsoft added a feature called "Keep pegging between approved planned orders for Planning Optimization", which by reading the description sounds like it would make sure that the planned orders maintain their association (pegging) with their original demand sources even after they are approved. Which, in your case you describe, would mean that the resources would not be reallocated for order #2, but rather be used to fulfill order #1.
Have you enabled this feature, and if so, have it solved the issue that you describe in your case?
regards
Andreas
Hi Andreas,
Thanks for your comment. As for our customer case, approving planned production orders is not applicable and therefore, this new feature is not applicable.
For our client, this scenario makes CTP unusable and we have to look for a solution outside of D365 FO.
This “Idea” solves this problem and has already received many votes.
What is the time Microsoft is considering adding it to the roadmap?