Reference

The enumerable part of this section is written from Delivery Date's own code by oce docs:reference, so it matches what the version you installed does:

• Settings: everything you may set, whether it is a setting key, a calendar, a slot or a product's own preparation time, with what each one starts at, and what Delivery Date fixes on purpose and why.
• The API: the one read resource an integration may call, every field on it, and what the promise covers.
• Personal data: every column that holds something about a person, why it is there, how long it is kept and what removes it.
• Security verdict: each control of the shared security baseline, and where Delivery Date stands against it.
• What it costs: the queries and bytes it adds to nineteen stock pages.

The rest of this page is the part a generated list cannot say: what Delivery Date puts in your database, what it hangs off, and what a calendar is made of.

What a calendar holds

A calendar is one delivery week. Your store has exactly one store calendar, which every other calendar composes against, and as many method calendars as you need, each bound to one or more shipping methods.

Slots	The named windows a customer picks from: Morning, 18:00-21:00. Named per language. Each has a cap, and blank means no limit.
The week	Which slots run on which weekday, with a per-day cap that overrides the slot's own where you set one.
Orders a day	A cap for the whole weekday whatever the window, for a store that thinks in vans rather than in windows.
Closed dates	Single days or ranges the store is shut, with a note. They apply whatever the week says, and no method calendar can open one.
Preparation time	How long before a delivery can go out, counted in whichever days the settings screen says.
Cut-off	The deadline that decides which day's batch an order joins. Nothing else. Blank means no deadline, which is a different store from one whose deadline is 00:00.
Take orders up to	The horizon, in calendar days from today.

A shipping method belongs to at most one calendar, which is enforced when you save as well as by the database. Methods are named as code.key (flat.flat, pickup.pickup, weight.weight_3), and the picker on the calendar form generates the list from what you have installed. The free-text box beside it takes code.key for a third-party method that mints its keys when it quotes, or code.* for every key that extension quotes; an exact key on another calendar still wins over a wildcard.

The screens

Screen	Where
Settings and the store calendar	Extensions → Extensions → Modules → Delivery Date
The list of calendars	Delivery calendars, from the button on that screen
A product's preparation time	The Delivery Date tab on core's own product form
The day sheet and the week's occupancy	Sales → Delivery Days
The delivery day of one order	Core's own order page, between Shipping Method and Payment Method
Orders with no delivery day	The red banner on any day of the planner
What is held about one person	Customers → Personal Data
Removing every booking at once	Show me what is held, and how to remove it, on the settings screen

The tables

Eight, all prefixed with your store's table prefix. None of them is removed when Delivery Date is uninstalled.

Table	Holds
delivery_date_calendar	One delivery week: its days, slots, caps, closures and numbers. The store calendar is a row like any other.
delivery_date_calendar_method	Which shipping methods a calendar speaks for, unique per store.
delivery_date_calendar_customer_group	Which customer groups a method calendar is offered to. No rows means every group.
delivery_date_slot	A window and its cap.
delivery_date_slot_description	The window's name, per language.
delivery_date_product	Per-product preparation days. Sparse: no row means nothing declared.
delivery_date_booking	One row per order: the day, the window, and the day the customer originally chose where it moved.
delivery_date_memory	What has to outlive an uninstall: the settings copy and the identifier of the owned order status.

What it hangs off

Twenty-seven event registrations, all removed when you uninstall. They are pairs more often than not, because two of OpenCart's own model triggers are spelled differently on the two releases and both spellings are registered:

• The checkout picker and the notice: the shipping-method block, and the confirm block underneath it.
• The booking: written when an order is added or edited, at the model layer, so a storefront checkout, the admin order editor and the API all write one.
• Firming and the review status: on the order history call, when the order first leaves the incomplete status.
• The confirmation email and the customer's order page: the delivery day under the shipping method, on both.
• The product form's tab, and the save behind it.
• The admin order page and order list, and the Sales menu entry.
• Core's printed invoice and shipping list: the delivery day under the shipping method, on both.
• Delivery Date's own language files, in the admin and on the storefront, so its strings are served in the language your store is registered as.
• Customers → Personal Data: the menu entry, and the answer Delivery Date gives that screen about one person.

The order status

Awaiting Delivery Date is created at install and kept, by identifier, for ever after. It flags an order whose delivery day moved after the customer stopped looking, or which could not be given a day at all. Point Flag a moved delivery as at a status of your own if you would rather route those orders into a queue you already have, and read what the customer sees before you do, because the status is on their order page too.