Operations Forms
- Version
- 3.x
- Updated
A functional description of the forms an admin uses to run the shop day-to-day — processing orders, managing customers, moderating reviews, configuring transactional emails, monitoring shop health, and first-run onboarding. Usage-centric (a behavior spec for the refactor), not implementation. For how these are stored/processed, see the technical docs.
Where the configuration, configurator-building and commerce-setup docs describe setting the shop up, these forms describe operating it once customers start using it.
Forms covered:
- Orders
- Order Slip
- Customers
- Reviews
- Notifications (transactional emails)
- Dashboard
- Post-install wizard
- License
1. Orders
The central operations screen: every order/quotation/saved-cart, with a status lifecycle and fulfilment actions.
Order list
- Columns: ID, Order ("Display" link), Customer (links to the customer record), Status, Time Created.
- Filters (verified live): customer search, date from / date until, and a status dropdown; paginated. Guest/in-checkout rows show "No customer account".
Order detail (a frozen snapshot)
The order detail is essentially read-only: at checkout the configuration, prices, addresses, tax/currency and reference data are snapshotted into the order, so what the admin sees is the order exactly as placed — it does not change if products are later edited. It shows the customer and billing/ delivery addresses, the configured line items and their selections, payment method, shipping, taxes and totals, and the current status. The admin doesn't edit the order's content; they drive it forward with actions.
Verified live: the order detail explicitly states "You cannot change an order's billing and shipping information" (it's stored separately from the customer account, with a "Go to customer account data" link). It also renders tax notes such as "No tax is charged. The tax liability is shifted to the recipient of the supply." for reverse-charge/VAT-free orders — confirming the EU-VAT handling in the commerce-setup doc.
Order status lifecycle
Orders move through these statuses (extendable by payment connectors):
| Code | Status | Meaning |
|---|---|---|
| 0 | Not ordered | cart not yet submitted |
| 1 | In Checkout | customer is in the checkout flow |
| 2 | Ordered | order placed, awaiting payment |
| 3 | Paid | payment received |
| 4 | Confirmed | order confirmed/accepted |
| 5 | Shipped | dispatched |
| 6 | Cancelled | cancelled |
| 7 | Refunded | refunded |
| 8 | Saved | a saved cart (save-for-later) |
| 9 | Incorrect amount paid | payment mismatch |
| 11 | Quotation sent | a quote was issued |
| 14 | Quotation requested | a quote was requested (RFQ) |
The typical progression (the admin's status dropdown can also set any status directly):
Admin actions
Verified live, the order detail groups these as Status, Invoice, and Manufacturing Slip:
- Change status — a status dropdown + Update button; moving the order (e.g. Confirmed → Shipped) can trigger a notification email (see §5) and other status-driven behavior.
- Invoice — shows e.g. "Invoice 12 is released." with a Download link; depending on the invoicing mode the admin Generate & release (Automatic after Clearance) or Upload a custom invoice PDF (After Manual Upload).
- Manufacturing Slip — a Download link that generates the production/packing PDF (see §2).
- Cancel / Delete the order.
(The exact actions available depend on the invoicing mode set in Configuration and on the order's status. Whether prices/quotes were shown depends on the customer's group permissions.)
2. Order Slip ("Manufacturing Slip")
An on-demand manufacturing / packing slip for a given order — a printable PDF generated on the fly (no stored record). Used by fulfilment/production staff to see exactly what to build/pack for an order. Functionally a "print this order for the workshop" action. In the UI it's the "Manufacturing Slip → Download" group on the order detail.
3. Customers
The customer records behind orders. Each customer has full billing and delivery address sets plus account/metadata.
Billing
Company name, salutation, first/last name, address 1 & 2, ZIP, city, country, state, county, city, email, phone.
Delivery
The same set of address fields for a separate shipping address.
Other
- VAT IN — the customer's VAT identification number (validated for EU B2B; affects VAT handling).
- Customer Group (
group_id) — the CBX group the customer belongs to. Affects their pricing, tax mode, discounts and feature access (see commerce-setup → Customer Groups). - Platform user (
platform_user_id) — the linked host CMS (e.g. Joomla) user account. - Language — the customer's preferred language.
- Newsletter — newsletter opt-in state.
- Temporary (
is_temporary) — marks a guest/in-progress record; permanent accounts are created when a purchase completes, and temporary ones are pruned by maintenance. An admin can effectively promote a guest to a permanent customer by clearing this. - Custom 1–4 — free-form customer attributes.
Functionally, this screen lets the admin look up, edit and segment customers, fix addresses/VAT numbers, move a customer to a different group, and link/unlink platform accounts.
The guest-record lifecycle behind the Temporary flag:
4. Reviews
Moderation of customer product reviews.
- Name — the reviewer's display name.
- Rating — the star rating.
- Comment — the review text.
- Creation date — when it was submitted.
- Product — the product reviewed.
- Language — the review's language (reviews are shown per language).
- Active (
published) — whether it's visible on the storefront.
New reviews arrive unpublished (a moderation queue); the admin approves them by activating, and can edit/remove inappropriate ones. A notification address (set in Configuration) is alerted on new submissions.
Functional gap to note for the refactor: reviews are currently not purchase-gated — anyone can submit one, though the intent is to restrict reviews to registered customers who bought the product. (See the user-stories doc, US-8.2.)
5. Notifications (transactional emails)
Templates for the automatic emails sent as orders change status. Each notification is tied to an order status and can send to the customer and/or the shop manager.
- Name — the template's name.
- Status Code — the order status that triggers this notification (e.g. "Paid", "Shipped"). Affects when the email is sent.
- E-Mail to Customer: Send email toggle, Subject, Email HTML (body).
- E-Mail to Shop Manager: Send email toggle, Subject, Email HTML (body).
Bodies/subjects support placeholders for order/customer/shop data so each email is personalized. Functionally this is how the shop communicates order progress (confirmation, payment received, shipped, etc.) to both the buyer and the back office. Changing an order's status (§1) is what fires the matching notification.
6. Dashboard
A read-only health & diagnostics screen — the admin's at-a-glance operational status, not a CRUD form. It reports:
- Current stats — database/server stats (e.g. InnoDB buffer pool, query cache, APCu cache state), and shop figures.
- Performance tips — suggestions to improve speed (caching, DB settings).
- Critical issues — actionable problems, e.g. low PHP memory limit, no shop country set, missing/expired license, outdated ionCube loader, missing DB privileges for foreign-key constraints, failed upgrade detected, non-writable data/temp/log folders, missing PHP extensions (mbstring/SOAP/Imagick formats), broken language-override files, and platform conflicts.
- License status — warns when the license is missing or expired (a warning, not a block).
Functionally it's the first place to look when something's wrong; it surfaces the conditions that would otherwise cause silent failures (e.g. uploads failing due to folder permissions, or the migration system halted by a failed upgrade).
7. Post-install wizard
A guided first-run setup that gets a new shop to a usable state in a few steps:
- Store license key — enter the product/license key.
- Store shop data — shop name, website, email (writes the Shop Data identity used on invoices/emails).
- Store tax data — set a single tax rate across all tax classes, set the shop country, and flip every customer group to B2B or B2C in one shot (a fast way to configure tax mode shop-wide).
- Store language tags — choose the active languages and the default.
- Store currencies — bulk-create the base and any foreign currencies.
Functionally it front-loads the most essential Configuration / commerce-setup choices so the admin isn't faced with the full settings surface on day one. After completion it's marked done.
8. License
A small screen to store the product/license key (the same value also editable in Configuration). The key is validated against the license servers; an invalid/expired key produces a Dashboard warning but does not disable the shop.
9. How operations fit together (order lifecycle)
- A customer places an order → it enters at Ordered (or, for the alternative flows, Quotation requested / Saved).
- Payment (via the chosen PSP) moves it to Paid (or Incorrect amount paid); offline methods may be confirmed manually.
- Status changes fire Notifications to the customer and shop manager.
- Depending on the invoicing mode, an invoice is auto-generated on order/after clearance, or the admin uploads one; it's then released (and optionally emailed).
- The admin progresses the order: Confirmed → Shipped, or Cancelled/Refunded; production uses the Order Slip to build/pack it.
- Customers are managed alongside (addresses, VAT, group, guest→permanent), Reviews are moderated, and the Dashboard is watched for issues.
10. Notes for the refactor (functional observations)
- The order is an immutable snapshot. Order content is frozen at checkout; admins act on state and documents, not content. A refactor should keep this audit-grade immutability (orders must stay accurate even after catalog changes) while making the status lifecycle an explicit, extensible state machine (today it's integer codes 0–14 with gaps, extendable by connectors).
- Status changes drive side effects (notifications, invoice generation). Modeling order status as events/transitions with hooks would make these explicit rather than scattered.
- Invoicing has three modes (automatic / after clearance / manual upload) that change which order actions exist — a clear candidate for a small strategy/policy.
- Customer "temporary" lifecycle (guest → permanent on purchase, pruned if abandoned) is real behavior to preserve; model guest vs. registered explicitly.
- Reviews need purchase-gating (currently missing) — a known functional gap to implement in the refactor, not replicate.
- Notifications are status-triggered templates with placeholders — a clean, generic "transactional email per event" system worth keeping (and extending to more events).
- Dashboard encodes operational preconditions (folder permissions, extensions, license, failed upgrades). These are effectively the app's runtime health checks — valuable to carry forward as explicit self-diagnostics.