Hi,

The wanted delivery date is the date on which the customer wants the order to be delivered at the customer's delivery address.

The target date/time is the estimated sales target date. This is the date used by the system for any recalculation, e.g., when changing the ship-via code. Initially this date is set to the same date as the wanted delivery date, and if the wanted delivery date gets updated, so will the sales target date. The target date can also be manually updated. It will then trigger a recalculation of planned delivery date where the system will try to meet the target date. Manually updating the target date to a different date than the wanted delivery date can be useful if there is a reschedule of dates. The purpose of this is to keep the original wanted delivery date unchanged as per when the customer originally requested the parts to be delivered on. The target date may be set to a date earlier than the wanted delivery date.

The planned delivery date is the date/time on which the goods are planned to be delivered to the customer's address. This date is communicated to the customer when printing the order confirmation. The date is initially set to the same date as the target date, but may be automatically adjusted by the system when using availability check or a route is applied to the planned ship date, where the planned delivery date in turn is calculated by adding transport lead time. The date can also be manually updated but may not be set to a date earlier than the target date. It can be a non-working day.

The promised delivery date/time is the date/time on which the goods are promised to be delivered to the customer's address. This is initially the same as the planned delivery date/time. This will change when the planned delivery date is updated as long as an order confirmation is not printed/sent. The date/time can be manually updated if the delivery time is changed because of unforeseen disturbances. The system will deliver a warning message if the order confirmation has been printed prior to the change of the promised delivery date.

Considering all the above dates, you can use promise delivery date to compare delivery date variances.  

Best Regards,
Rasika

@Janne 

Hello,

Even with the three dates you’ve mentioned and Rasika has explained, I believe you are understanding as we have that IFS doesn’t really give a method of measuring the On Time Delivery using the standard fields. We have added three additional date fields to Customer Order Header for the purposes of measuring and managing On Time.

Customer Wanted Date - this is always just the customer wanted date on their PO, whether it makes sense or is realistic or not, it is just a reference point for the customer request

Instron Ship Date - this is the promised delivery date to the customer, essentially the first communication point back to them of the intended delivery date.  This can be changed if there is a delay in the order for some reason or if the customer requests a delivery date change.

Measure Date - this is the date for measurement of on-time.  This date is Instron Ship Date at the moment of order release, we have an event that copies the Instron Ship Date to the Measure Date on that status change.  If there are no further changes to the order, the measure date changes.  If the order is delayed due to an issue on our end, the measure date doesn’t change.  Only if the customer has requested a delivery date change can the Measure Date be changed to adjust the On Time performance. 

We don’t attempt to lock these fields by permission, rather we track them by history and assume that our planner/schedulers operate by the established rules unless there is reason to think they’ve changed something in error.  

Because all of the out of the box scheduling functions in IFS related to MRP operate off of the Wanted Delivery Date, we have some custom RMB functions that use the Instron Ship Date to adjust the Wanted Delivery Date on the header and lines by an offset to ensure the order is ready in time for testing or customer demonstration if required.  We still use the standard IFS date fields for their intended purpose, we just don’t rely on them for On Time measurements.

Best Regards,

Shawn

Unfortunately I don’t don’t neither have clear answer for you, but some more variables to consider.
Delivery term; are goods sold on your premises or delivered to customer
Partial deliveries; how those should be counted

I assume there is no standard wayt to handle this, depends on company and business where they are. But if you can define rules how to calculate, that is most probably possible to implement to IFS with custom fields, LU’s and events.

 -Jouni-

This makes a lot of sense in practical “lean” point of view as standard IFS way is a bit over complicated. Need to examine further and make a smart copy.

@Janne  Just noticed the above sentence under Measure date should have read:  If there are no further changes to the order, the measure date never changes.   (it was likely obvious something was missing, but just wanted to clarify)

HI,

In purchasing we have put custom fields to show the planned receipt date at the time the order was confirmed and what the supplier lead time was at that point; which I have generated reports from. We had a to make a number of assumptions about the way the system is used - i.e. used correctly  - to give meaningful data.

You could do the same for Sales?