Settings¶

Delivery Date keeps its settings in OpenCart's own setting table, under the module_delivery_date group. You set them at Admin > Extensions > Extensions > Modules > Delivery Date.

Each key below carries where it applies. per store means a multi-store install can hold a different answer per storefront, and both are honoured: a read takes what that store holds, then what the default store holds, then the shipped default. install-wide means one thing serves every storefront, and the key's own description names that one thing.

Scope¶

Key	Default	What it does
`module_delivery_date_status` install-wide	`0`	Whether the module is enabled. Off on install: an extension that started changing what a storefront promises the moment it was installed would be making a decision the merchant has not made. Set by the Status switch on this extension's own settings screen.

Calendars¶

calendar — per store

One delivery week, with its own numbers and its own closures. Every store has a baseline calendar, and a store may add calendars of its own that speak for particular shipping methods. A method calendar inherits from the baseline rather than replacing it, and it inherits per column: a blank cutoff or horizon takes the baseline's, inherit_days decides whether the week's offered slots are the baseline's, and the lead days compose by max rather than overriding — which is a different rule from preorder's ladder, where an explicit row beats the one above it wholesale. Per store because the row carries its own store_id, which is also why two storefronts can each bind the same shipping method to a calendar of their own.

name — What the calendar is called on your screens. Never shown to a customer. Starts at empty.
status — Whether the calendar offers anything at all. Off, it is configured and dormant rather than deleted. Starts at 0.
inherit_days — Whether the week's offered slots come from the baseline. Off, this calendar's own week is the whole answer. It governs the offers and nothing else — the numbers and the closed dates compose either way. Starts at 1.
lead_days — Preparation days this calendar adds, combined with everything else that says so by taking the largest rather than by adding them up. 0 adds nothing, which is why this is not blankable: "not set" and "adds nothing" are the same statement and a second spelling of it would be a second thing to explain. Starts at 0.
cutoff — The time of day after which today stops counting as a day you can prepare on. Blank inherits the baseline's, which is what makes it different from a cutoff of midnight. Starts at empty.
horizon_days — How far ahead the picker offers days. Blank inherits the baseline's. Starts at empty.

week_offers — per store

Which slots a calendar offers on each weekday, and the cap on each of them — the grid on the Calendars screen. Kept as one JSON column on the calendar row rather than as a table of its own because it holds no id from outside this extension, is written whole and is never searched across: preflight's job record is the precedent. Weekdays are ISO-8601, 1 being Monday, which is what every other weekday in this extension counts by.

weekday — The day of the week the offer is on, 1 through 7 with Monday first. A weekday absent from the grid offers nothing, which is how a day off is stored. Starts at empty.
slot_id — Which of the calendar's slots is offered on that weekday. Starts at empty.
cap — How many deliveries that weekday's slot takes. Blank means the slot's own cap applies; a number here overrides it for this weekday only. Starts at empty.

day_limits — per store

A ceiling on a whole weekday, under whatever its slots allow between them — the answer to "the van does twelve drops a Monday however the morning and afternoon rounds are sized". Kept as one JSON column on the calendar row for the same reason the offers are.

weekday — The day of the week the ceiling is on, 1 through 7 with Monday first. Starts at empty.
limit — The most deliveries that weekday takes in total. Blank is no day-level ceiling, and the slots' own caps are then the whole answer. Starts at empty.

closed_dates — per store

The dates a calendar is shut — public holidays, a works closure, a week in August. Ranges rather than single days, because a fortnight typed one day at a time is a fortnight typed wrong once. They compose regardless of whether the calendar inherits its week: a store closed on the 25th is closed on the 25th on every calendar it has.

from — The first day of the closure. Starts at empty.
to — The last day of it. Blank is a one-day closure rather than an open-ended one. Starts at empty.
note — Why, for the person reading the screen next year. Never shown to a customer. Starts at empty.

calendar_method — per store

Which shipping methods a calendar speaks for. A reference belongs to at most one calendar per store, which the table's UNIQUE makes structural rather than a rule somebody remembers — and it is keyed on the store as well as the reference precisely so that two storefronts can each bind the same method to a calendar of their own. A method nothing names falls to the store's baseline.

reference — The shipping method, as <extension code>.<quote key> — pickup.pickup, flat.flat — or code.* as a wildcard for a third-party method that mints its keys at quote time. Starts at empty.

calendar_customer_group — per store

Which customer groups a method calendar speaks for. No rows is every group. A shopper outside the listed groups is, for that method, a shopper nothing is bound for, and falls to the store calendar the way an unbound method does. Group narrows, method selects: the group never picks a calendar on its own.

customer_group_id — A core customer group the calendar is offered to. Starts at empty.

slot — per store

A delivery window a calendar may offer, with a cap and a position. A slot belongs to one calendar, so it is per store through the calendar that owns it.

sort_order — Where the window sits among the day's others, on the picker and on the planner. Starts at 0.
cap — How many deliveries the window takes on a day nothing says otherwise about. Blank is uncapped; a per-weekday cap in the week grid overrides it where one is set. Starts at empty.

slot_description — per store

What a slot is called, per language, which is the one thing about a slot a customer ever reads — on the picker and in the confirmation email. Keyed by OpenCart's own language_id rather than by a language code, because a slot name is a thing the merchant created rather than a sentence this extension ships and there is no English default behind it to fall back to.

name — The window's name in that language, as the customer reads it — "Morning", "09:00–12:00", "Saturday round". Starts at empty.

Preparation¶

product_lead — install-wide

How long one product takes to prepare, in days, set on that product's own screen. The combining rule is this ladder's own and is stated here rather than assumed, because the repository has two of them and they disagree — these combine by taking the largest, where preorder's rows resolve by precedence. A store that needs a day in general plus a product that needs five needs five, not six: summing double-counts the same preparation, and a merchant who declared five days meant five. Not set is the absence of a row, and a product with no row contributes nothing rather than the store's own figure, which is already inside the maximum. A line that does not ship contributes nothing either. Product level only and install-wide: there is no option-value granularity, because there is one scalar per product and nothing to vary by option, and no store dimension, because preparation time is a warehouse fact about the product while per-store visibility is already oc_product_to_store's job.

lead_days — Days this product adds to the preparation the cart needs. Setting it to 0 deletes the row rather than storing a zero, because absence and zero already say the same thing. Starts at 0.

Key	Default	What it does
`module_delivery_date_lead_basis` per store	`open`	Whether preparation time counts delivery days or calendar days. Delivery days by default, because calendar-day counting quietly under-delivers the preparation it promises: a Friday order with a two-day lead lands Sunday, snaps to Monday, and the store got one working day for something it said needed two. The days counted are the store baseline's, never the chosen carrier's — and that baseline is the shopfront's own, which is why this is per store too: a shopfront whose week is a different week is a shopfront that may want a different thing counted over it.

Picker¶

Key	Default	What it does
`module_delivery_date_scarcity` install-wide	`2`	How few places have to be left on a window before the picker says how many. Above it the picker says nothing about how full a day is, which is the difference between a store that is busy and a store that looks like it is about to run out. Zero switches the sentence off entirely.
`module_delivery_date_visible_days` install-wide	`6`	How many days the picker shows before show more. It bounds what a customer reads at a glance and not what they may choose: the days behind the button are the same days, and how far ahead they run at all is the calendar's horizon.

Bookings¶

Key	Default	What it does
`module_delivery_date_hold_minutes` install-wide	`30`	How long a shopper who has reached checkout keeps holding the slot they picked, in minutes. A provisional booking has to count, or ten shoppers in checkout at once are all offered the last slot and all ten get it. It counts only while they are live: the hold is a comparison against this window rather than a state anything transitions out of, which is what makes an abandoned checkout age out of the count by itself with nothing sweeping up after it. Install-wide because capacity is counted over one booking table, which has no store of its own — the day and the window are the van's, whichever storefront the order came through.
`module_delivery_date_released_statuses` install-wide	`7,8,9,10,11,12,13,14,16`	The order statuses on which a booking gives its slot back, as core order status ids. Everything else occupies — including Pending, which is where this parts company with core's stock rule on purpose: a Pending order is still coming and it still needs a place on the van. Install-wide because it names core's order statuses, which have no store of their own.
`module_delivery_date_review_status_id` install-wide	empty	The order status appended when a booking moved at firming or could not be scheduled at all. Empty means the status this extension owns, "Awaiting Delivery Date"; a merchant who would rather route those orders into a queue of their own points this at it instead. Install-wide for the same reason: an order status has no store of its own.

What the customer is told¶

Key	Default	What it does
`module_delivery_date_copy` per store	empty	The wording of the "no delivery day yet" sentence, per language code. Read whole to render one page and written whole by one form POST, so it is one setting key holding an array rather than a table. Empty for a language means the sentence this extension ships, which is what the box shows in grey. Per store as well as per language, because two shopfronts under one installation are two voices as surely as two languages are, and the sentence is read on the shopfront's own checkout.

Advanced¶

Key	Default	What it does
`module_delivery_date_diary_verbose_until` install-wide	`0`	When detailed logging stops, as a unix timestamp, and `0` is off. Turning Detailed logging on from this extension's settings form stores the moment two days from now; the writer compares that against the clock every time it is asked for a `DEBUG` line, so the window closes on its own with no scheduled task and nothing to clean up. While it is open this extension records what it did in far more detail, and the shared diary consequently holds less history.
`module_delivery_date_api_enabled` install-wide	`0`	Whether the extension answers API requests at all. Off, every API route answers `404 api_disabled` in the API's own JSON envelope, so an extension with its API off is shaped like one that has none. Read once for the whole installation from the default store rather than per store, because the one thing it serves is OpenCart's own API user, which has no store of its own. It is a separate switch from the extension's own Status, and the two are read independently: the API answers whether or not the checkout picker is on, because what each order was promised is the merchant's own record and a storefront switch should not hide it. The API only ever reads bookings; calendars, slots and capacity are not readable through it, and nothing can move a delivery through it.

What you cannot change, and why¶

These are fixed on purpose. Each one is a decision with a reason beside it rather than a setting nobody got round to adding.

Calendars¶

A slot carries a name and never a start and an end instant, and that is this extension's answer to daylight saving rather than a feature nobody got to. Nothing anywhere parses "09:00–12:00" into a moment, so a 09:00–12:00 round is 09:00–12:00 in July and in January and spring-forward cannot delete one. Name a window whatever your customers should read; the cutoff, the capacity and the planner all work on the day and the window rather than on a clock.

A slot has no on-and-off switch of its own. A window that appears in no weekday's offers is not offered, which is one representation of "off" rather than two — and two would be a screen where a slot can be offered on Monday and switched off at the same time.

The store calendar is offered to every customer group, and cannot be limited. It is what every shopper falls to when no method calendar speaks for them, so a limited store calendar would leave a group with no delivery week at all, which is the module switched off for them without anyone having switched it off.

Bookings¶

The planner screen shows a week, and how many days that is is not a setting. The screen is a week grid with a week's arrows on it and every one of this extension's three JSON columns keys by weekday, so a fortnight would be a different screen rather than a longer one. What the arrows move is the day the sheet is for; the week shown is whichever week that day falls in.

A reassignment cannot put an order on a closed date. A closure means the store is shut, and that is as true for the person at the admin as for the shopper at checkout. Reopen the date first if the store is in fact open.

A reassignment does not message the customer. It changes the booking, and telling the customer is core's order history with Notify ticked, in words the merchant writes for this one customer. A generated 'your delivery moved' mail would say it to somebody who arranged it on the phone ten minutes ago.