Troubleshooting¶

If Delivery Date will not open at all (a blank page, or a bounce back to the dashboard), that is an install problem rather than a Delivery Date one. See troubleshooting an install.

Whatever the symptom, Delivery Date wrote down what it did and what it refused to do, in a file your own admin downloads in one click. See what Kyvero extensions log.

Everything below is about a Delivery Date that is running and doing something you did not expect.

There is no date picker at checkout¶

Work down this list:

The module is off. Delivery Date is off until you enable it, at Extensions → Extensions → Modules. Nothing appears at checkout until you do.
The basket does not ship. A basket of downloads only has no shipping method block, and the picker lives inside that block. This is correct: there is no van.
The customer has not reached the shipping-method step. The picker sits under the shipping methods, so it appears when they do.
The theme replaced the shipping-method block wholesale. Delivery Date appends itself to the end of the checkout's shipping-method template, the one your theme renders there. A theme that draws its shipping methods through a template of its own under another name leaves it nowhere to go.
It is a second shopfront nobody has opened the settings screen for. A shopfront's store calendar is created the first time you open the settings screen with that shopfront picked, and until then its checkout shows no picker.

The picker says no date can be offered¶

The rail is empty and the customer is told you will contact them. Every reason is in the calendar, and the fastest way to see which is the What a customer would be offered preview on the settings screen: it prints the reason beside each of the next fortnight's days.

Every day inside the horizon is full. Raise a cap, add a window, or take orders further ahead.
The horizon is shorter than the preparation. Preparation of five days with a horizon of three leaves nothing to offer, on any day.
A closed date covers the range, or the week has no day ticked.
The chosen shipping method's calendar is closed even though the store's is open. That calendar's own form has a preview of its own; compare the two.

Every date offered is later than it should be¶

The preview explains the arithmetic in one line (ordered, cut-off, batch day, preparation, earliest offered), so read that line first. The usual causes:

A product in the basket declares a long preparation time. The picker names the product responsible in its why line. Preparation is the largest one in the basket, never the sum.
The cut-off has passed, so the order is in tomorrow's batch.
Preparation is counting delivery days, which is the default, so a two-day preparation over a Monday-to-Friday week skips the weekend.

A day is offered that the store is closed on¶

A shipping method's calendar can open a weekday the store calendar closes. That is how a Saturday pickup service is configured. The calendar list flags it as a warning so you can see it was deliberate.

What cannot happen is a closed date being opened. If a specific date is still being offered, it is not covered by a closed date: check the From and To of the range, remembering that To blank means a single day.

A calendar seems to do nothing¶

The calendar list raises the reasons it can see, at the top of the screen:

The calendar is bound to a shipping method that is switched off in Extensions → Extensions → Shipping.
The calendar is bound to no shipping method at all.
The calendar names an extension that is not installed: a leftover reference after a shipping extension was removed.

A shipping method belongs to one calendar. If the one you want is greyed out on the form, the message names the calendar already holding it; take it off there first.

A window reads 6/4¶

You lowered its cap after those orders were booked. Nobody has been un-booked, because Delivery Date will not take a date away from a customer who was promised one, so the day reads over capacity until those orders ship.

A customer says their delivery day changed¶

Open the order. Where the day moved, the order page shows the day it was moved from, the order history carries a line explaining it in the customer's own words, and the order carries the Awaiting Delivery Date status. The day sheet badges the same orders with was Sat 22 Aug.

The day only ever moves forward, and only when the day the customer chose could not be kept, usually because the last place in it was taken by an order that confirmed first.

An order has no delivery day at all¶

There is a red banner on every day of Sales → Delivery Days while any exist, and a list behind it. These are orders the calendar could offer nothing to at the moment they were paid for. Nothing else in the store will mention them, which is why the banner is there. Ring the customer, agree a day, and give the order that day on its own page; see give an unscheduled order a day.

The banner counts the default shopfront's orders only. An order from a second shopfront with no delivery day carries the Awaiting Delivery Date status, so filter the order list by it.

That screen has a permission of its own:

extension/delivery_date/sale/planner

Your group is granted it when you install the extension, but you have to log out and back in for it to take effect. Grant it to other groups under System → Users → User Groups, under Access Permission. The menu entry is hidden rather than shown and then refused, because a link a user cannot open only shows them the route.

The dates are a day out¶

Delivery days are worked out in the timezone set at System → Settings → Local, not in your browser's. The store calendar screen prints the zone and the time it currently is there. If that clock is wrong, fix that setting.

The picker does not update when the customer changes shipping method¶

Delivery Date watches the checkout's own requests and refreshes the rail when the shipping method changes. A heavily rewritten theme can make requests it cannot see, and the rail then keeps showing the previous method's days.

The date is re-checked on the server when the order is placed, so nothing wrong is ever stored: the customer's choice is re-resolved against the method they actually chose, and they are told if it moved. The re-check on the server is what guarantees this; the live refresh only keeps the rail current.

Orders in the admin order editor¶

An order created or edited in the admin gets a booking too, resolved by the same calendar. There is no date picker on that screen. The order takes the earliest day the calendar can offer it, and the delivery day is shown on the order page afterwards, where you can give it another day.

Nothing here matches¶

Get in touch. Include the version of OpenCart, what the preview line says on the settings screen, and the order id if it is about one order.