# Operations Forms > A functional description of the forms an admin uses to run the shop day-to-day — processing orders, managing customers, moderating reviews, configuring trans… Source: CBX documentation, version 3.x (released). Canonical page: https://docs.configbox.at/docs/functional/operations. Last updated 2026-08-01. --- 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: 1. Orders 2. Order Slip 3. Customers 4. Reviews 5. Notifications (transactional emails) 6. Dashboard 7. Post-install wizard 8. 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): ```mermaid stateDiagram-v2 state "Not ordered" as S0 state "In Checkout" as S1 state "Ordered" as S2 state "Paid" as S3 state "Confirmed" as S4 state "Shipped" as S5 state "Cancelled" as S6 state "Refunded" as S7 state "Saved" as S8 state "Incorrect amount paid" as S9 state "Quotation sent" as S11 state "Quotation requested" as S14 [*] --> S0 S0 --> S1: checkout begins S1 --> S2: order placed S1 --> S8: cart saved for later S1 --> S14: quote requested instead of buying S14 --> S11: quote issued S2 --> S3: payment received S2 --> S9: payment mismatch S3 --> S4 S4 --> S5 S2 --> S6: cancelled S3 --> S7: refunded ``` ### 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: ```mermaid stateDiagram-v2 state "Temporary (guest, in progress)" as T state "Permanent customer" as P [*] --> T: guest starts an order T --> P: purchase completes T --> P: admin clears the flag T --> [*]: pruned by maintenance ``` --- ## 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. ```mermaid sequenceDiagram participant Admin participant CBX participant Customer participant Manager as Shop Manager Admin->>CBX: Set order status (e.g. Shipped) CBX->>CBX: Match notification by status code, fill placeholders CBX-->>Customer: Email, if "to customer" is enabled CBX-->>Manager: Email, if "to shop manager" is enabled ``` --- ## 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) 1. A customer places an order → it enters at **Ordered** (or, for the alternative flows, **Quotation requested** / **Saved**). 2. Payment (via the chosen PSP) moves it to **Paid** (or **Incorrect amount paid**); offline methods may be confirmed manually. 3. Status changes **fire Notifications** to the customer and shop manager. 4. 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). 5. The admin progresses the order: **Confirmed → Shipped**, or **Cancelled/Refunded**; production uses the **Order Slip** to build/pack it. 6. **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.