Customer Promised Date¶

We have changed the field description ‘Promised Date’ to ‘Cust. Promised Date’.

Lead Times Report

We have added customer promised date, days late and total average days late to this report.

Reports > System Reports
There is a new report to show customer promised date < required date. This is in Reports > System Reports. The layout contains:
Order id, order date, customer, contact name, required date, customer promised date.

Order Processing > Orders

It is no longer possible to have a required date or a promised date before the current date.

We have added ‘Promised Date’, ‘Order Manufactured Date’, ‘Despatch Date’ and ‘Order Source’ to the column choices. The column choices now also display in alphabetical order.

If you enter an order and you specify a 'Required Date' & ' Promised Date' and then add or amend the blinds/components on the order previously both dates would revert back to the default lead time date.

The only way to hold the altered required date was if the required date was entered after all the detail lines had been added.
However sometimes users are forgetting about this, and the required date is getting changed back without them realising.

We have made the following change.
If this happens and the required date is going to be set back to the ‘lead time’ date, then a message appears saying ‘You have already altered the required date for this order.
Do you want to keep the date you entered?’.
If the answer is yes, then the required date that was entered manually remains.

Out Of Stock Management Form

There is a new form called ‘Out Of Stock Management’. This show a list of all out of stock detail lines. The following fields are displayed: Order number, order date, operator, stock code, stock description, when due back in stock (promised date), Update From Purchasing, Customer contacted, Follow Up Contact. It is also possible to enter text in the last three fields.
There is a new menu option for this in ‘Order Processing’ called ‘Out Of Stock Management’, which also has a menu permission in Administration > Users.

Order Processing > Orders

Promised Date to Default to Blank Parameter

There is a new parameter in Administration > Parameters called ‘Set Promised Date to Required Date’, which defaults to true.
If set to false, the ‘Promised Date’ in order entry is left blank.

Previously, when an order was created either manually, or via the EDI import, the promised date got assigned to the original required date.

Remake/Repair/Redespatch & Copy

Previously, when you copied an order, or when you generated a remake/repair/redespatch from the archive, the new order created had the same promised date as the original order.
This is now blank as the new order created will not have a promised date in these situations.
The promised date is only copied across to a new order if the original is split as the promised date will apply to both orders.

Order Processing > Orders > OOS Actions

There is a new flag in the OOS Action Outcomes system table called ‘Require Promise Date’.
If an outcome is selected in OOS Actions that has this flag ticked, then the user must enter a promised date. If ‘Require Promise Date’ is not ticked, then promised date is not mandatory.

Order Processing > Order Enquiry > OOS Scan

There is a new parameter in Administration > Parameters called ‘Re-schedule on Promised Date’.
The following functionality will only be applied if this parameter is switched on, and only affects the ‘Blind In Stock’, ‘Blind Out Of Stock’, ‘Order In Stock’ and ‘Order Out Of Stock’ buttons in Order Processing > Order Enquiry.

When any of the Out of Stock scan functions were run in the Order Enquiry screen, the order was removed from the schedule.
This has changed this, so that the order is rescheduled into the ‘promised date’ on the order.
The promised date is the date the customer is told their order will be back in stock.
This will help production keep track of capacity as previously out of stock orders were not accounted for.

When the scan takes place, the order is removed from its current scheduled slot.
It is then re-scheduled based on the order ‘Promised Date’.
If there is not enough capacity on the ‘Promised Date’ then the order is scheduled into the next available slot after the Promised Date.
If the quantity is less than the Large Quantity figure on the Manufacture Location system table, then the whole order is scheduled on the same day as normal.
If the quantity is greater than the Large Quantity then it is split over multiple days, starting from the Promised Date.

Lastly, if the Promised Date is blank, or is less than the current date, then the order remains unscheduled.
Also, the Required date on the order is set using the normal rules taking consolidated days into consideration.

Order Processing > Order Enquiry > BIS Scan

Along with the above changes to the OOS scan, the BIS (Back in Stock) scan has also changed slightly. The BIS scan function will no longer re-schedule the order. It will only remove the OOS flag from the order. The exception to this will be if there was a problem with the Promised Date and the order was not scheduled during the OOS scan. In this case, the BIS scan will schedule the order into the next available slot as it does currently.

Again, this functionality is only applied if ‘Re-schedule on Promised Date’ is switched on.

If a ‘Promised Date’ is changed in an order, it is now possible to record the reason for the change.
This is separate from the standard order amend reason code but the reason codes are held in the existing ‘Amendment Reason’ system table. There is a new flag to this table to indicate which codes are ‘Promised Date Reasons’.

When a promised date is changed on an order, the user is prompted for a reason code as per the standard functionality, but the list is limited only to the selected Promised Date Reasons.
This reason code is then recorded in history.
A reason code is not required when a promised date is first added (ie when the field is blank).
Also, note that this is separate from the standard amendment reason functionality and is not be dependent on this being activated.

There is now a parameter called ‘Promised Date Amendment Reason’.
If this is switched off, then the user does not have to enter an amendment reason if the promised date is changed.
The parameter defaults to false.

Order Processing > Orders

If ‘Promised Date Amendment Reason’ is switched on, then an amendment reason should be given if the promised date was amended.
If the promised date was set up so that it was always blank by default until a user entered a value, then it was asking for an amendment reason.
This now only happens if the promised date is being changed – not when first entered.

Order Processing > Bought In Order Tracking (re-release of 6.1.6 required)

There is now a new selectable column on the Bought In Order Tracking form for the order ‘Promised Date’.
This appears to the right of ‘Order Date’.
Also, when the ‘Approx Due Reciept Date’ is updated using the ‘Manufactured’ button, the ‘Promised Date’ is updated in the sales order.

Order Processing > Orders
If an entered promised date in the order entry is not for one of the delivery days held in the customer record, then a message now appears saying – This customer is only set up for the following delivery days: Someday’.

Order Enquiry
Notes 2 field is now a column choice, also Cust Promised Date

Mandatory Customer Promised Date
There is a new flag called ‘Customer Promised Date’ in Parameters > Order/Quotation Processing > Mandatory Fields.

Order Processing > Order Enquiry
The ‘Customer Promised Date’ now has a field colour for it in Administration > Parameters > Forms tab, but the colour only appears if the ‘Customer Promised Date’ is the current date or before.

Order Processing > Orders > Customer Promised Date
We have added 'Default No. Days for Cust. Prom. Date' Parameter for this.