Simon Martinsson Functional consultant

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.