# einfach-produktiv — Frontend Next.js frontend for [einfach-produktiv.mk360.de](https://einfach-produktiv.mk360.de), Coolify-managed and deployed from this repo (`git.mk360.de/Marco/einfach-produktiv`). For the VPS-wide infrastructure this app runs on (Caddy, Coolify, Gitea, the shared Payload instance), see `~/dev/README.md` — this file only covers what's specific to this project. ## Stack - **Next.js 16.2.9** (App Router, `output: "standalone"` for a small Docker image — see `AGENTS.md` before touching anything version-specific, this Next.js release differs from older training-data conventions) - **React 19.2.4**, **Tailwind CSS 4**, **Motion** for animation - **`@react-pdf/renderer`** for invoice PDF generation (see "Invoice PDFs" below) — no headless-browser dependency - No local database — all editable content (and now orders/customer accounts) lives in the shared Payload CMS at `payload.mk360.de` (see below). Customer auth is Payload's own (a second, separate `auth: true` collection there, `customers` — not this app's own user store), bridged via an httpOnly session cookie this app mints itself; see "Orders & customer accounts" below. ## Getting started ```bash npm install npm run dev ``` Open [http://localhost:3000](http://localhost:3000). `npm run build && npm run start` reproduces the production build locally — do this before pushing, since Coolify builds with `--no-cache` and a failed build only surfaces there otherwise. **Environment variables:** `PAYLOAD_URL` (defaults to `https://payload.mk360.de` if unset, see `app/lib/payload.ts`). `PAYLOAD_PREVIEW_SECRET` (no safe default — required for Live Preview, see below; must match the value set on the Payload backend). `NEXT_PUBLIC_PAYLOAD_URL` (optional, defaults to the same `https://payload.mk360.de` — only needed if the client-side Live Preview components should ever point somewhere else). `DISCOUNT_SERVICE_SECRET` (no safe default — required for discount codes to validate/redeem at all; must match the value set on the Payload backend). `ORDER_SERVICE_SECRET` (no safe default — required for `/api/checkout` to persist an order in Payload at all, for `/api/account/verify-email` to look up a customer by their verification token, and for `getCompanySettings()` to read the `company-settings` collection (seller data for invoice PDFs); must match the value set on the Payload backend — also used there for the same header). `SMTP_USER`/`SMTP_PASSWORD` (no safe default — required for `app/lib/alertAdmin.ts`'s critical-failure alerts and resend-verification emails; **does not** need to match anything on the Payload side — this app's SMTP connection is deliberately independent, see the "Monitoring & alerting" section). Set in Coolify's app settings for production, not in a committed `.env`. ## Pages | Route | Purpose | |---|---| | `/` | Home — hero, product spotlight, tools grid, trust row | | `/shop` | Product grid (all active products for this tenant) | | `/blog`, `/blog/[slug]` | Blog overview + post detail | | `/cart` | Cart (localStorage-backed, see below) | | `/checkout` | Shipping + payment method selection, order summary | | `/bestellbestaetigung` | Order confirmation — reads the one-time snapshot `/checkout` wrote | | `/konto/login` | Customer login | | `/konto/bestellungen`, `/konto/bestellungen/[orderNumber]` | Order history + order detail (own orders only) | | `/konto/profil` | Profile/address editing + password change | | `/challenge` | "Mini-Challenge" tool | | `/todo-cards` | "Todo-Karten" tool | | `/newsletter` | Newsletter signup | | `/versand` | Shipping policy (timeframes, costs) | | `/impressum`, `/datenschutz`, `/agb`, `/widerruf` | Legal pages (from Payload, see `legal-pages` below) | ## Content backend: Payload CMS This app is one **tenant** in a shared, multi-tenant Payload instance also used by other projects on the same VPS (see `docker/payload/` in the infra repo). All content queries go through `app/lib/payload.ts`, which hardcodes `TENANT_SLUG = "einfach-produktiv"` and filters every request with `where[tenant.slug][equals]=einfach-produktiv` — the tenant field itself is injected automatically into every collection below by Payload's `multiTenantPlugin`, not defined in this app. `/api/products` is this app's own same-origin proxy route (`app/api/products/route.ts`) in front of `getProducts()` — used by client components (cart, related products) that need the catalog reactively, so they don't talk to Payload's API directly and reuse Next.js's fetch cache instead of an extra round trip. ### Collections used by this tenant Most reads are public (`access.read: () => true`); writes are always admin-gated in the Payload admin UI at `payload.mk360.de/admin`. A growing subset below is **not** public-read at all (`discount-codes`, `orders`, `customers`, `number-ranges`, `company-settings`) — each row says so and explains what does have access instead. | Collection (slug) | Used for | Key fields | |---|---|---| | `products` | `/shop` grid, homepage spotlight, cart, checkout | `name`, `slug` (cart item id — **not** Payload's numeric id, so existing localStorage carts survive catalog changes), `description`, `price`, `compareAtPrice` (optional strikethrough), `image`, `detailHref`, `sortOrder`, `active` (hides a product from the shop grid/spotlight/related-products only — cart/checkout/its own detail page still resolve it regardless, see Discount codes section below for the same opt-in-filtering principle), `spotlight` + `spotlightEyebrow`/`spotlightHeadline`/`spotlightText`/`spotlightImage` (homepage "Neu im Shop" section — falls back to `image` if no dedicated spotlight image is set; forced onto the sole active product when exactly 1 exists, see `getSpotlightProduct()`), `taxRatePercent` (optional per-product VAT override, see "Product bundles & per-product tax rates" below), `bundleItems` (optional — makes this product a bundle) | | `discount-codes` | Cart discount input (`/cart`, display-only on `/checkout`) | `code`, `type` (`percent`/`fixed`), `value`, `validFrom`/`validUntil`, `minOrderValue`, `maxRedemptions`, `redemptionCount` (server-incremented only), `active`. **Not public-read** — see Discount codes section below | | `posts` | `/blog`, `/blog/[slug]` | `title`, `slug`, `category` (relation to `categories`), `excerpt`, `thumbnail`, `content` (richText), `readTime` (auto-calculated on save from word count), `featured` (shown as the `/blog` hero post; most-recently-published wins if several are marked), `publishedAt`, `quoteLabel` (label + icon + underline shown next to every blockquote in `content`, default `"Merke dir:"` — leave empty to hide that framing, the blockquote text itself still renders), `relatedProduct` (optional relation to `products`, powers the "Passend dazu" card at the end of the post — leave empty to hide that card, or empty if the linked product has no `detailHref`) | | `categories` | Blog post categorization | `name`, `slug` (unique per tenant, not globally) | | `legal-pages` | `/impressum`, `/datenschutz`, `/agb`, `/widerruf` | `type` (`impressum`/`datenschutz`/`agb`/`widerruf`, one doc per type per tenant), `title`, `content` (richText), `attachment` (optional file, e.g. the Muster-Widerrufsformular PDF) | | `trust-badges` | Horizontal "Schneller Versand / Versandkostenfrei / Mit Liebe verpackt" row — shown on `/shop`, `/cart`, `/checkout`, `/widerruf`, `/agb`, 404 | `title`, `description` (supports `{{lieferzeit}}`/`{{kostenfreiab}}` placeholders, resolved by the frontend from `shipping-settings`/`shipping-methods` at render time — not by Payload itself), `icon`, `sortOrder` | | `cart-trust-badges` | Sidebar bullets on `/cart` (title only) and `/checkout` (title + description) — deliberately a separate collection from `trust-badges` so the two pages can't drift into showing different claims | `title`, `description`, `icon`, `sortOrder` | | `shipping-methods` | `/checkout` shipping selection | `title` (no day-range in the title text — that lives in `shipping-settings` now, keeping both in one title used to drift), `description`, `price`, `freeShippingThreshold` (per-method, optional — leave empty for a method that should never be free, e.g. Express), `active` (inactive methods are hidden, not shown disabled), `sortOrder` | | `shipping-settings` | Delivery-time disclosure shown on `/shop`, homepage spotlight, ToDo-Karten, `/cart`, `/checkout`, `/versand` (Art. 246a §1 Abs.1 Nr.8 EGBGB requires this visible before checkout) | `handlingDaysMin`/`handlingDaysMax` (processing time before it ships), `transitDaysMin`/`transitDaysMax` (carrier time) — the app derives the combined total itself. One row per tenant. | | `payment-methods` | `/checkout` payment selection | `title`, `icons` (array — e.g. 3 logos for "Kreditkarte"), `active`, `sortOrder` | | `werkzeuge-cards` | Homepage "Meine Werkzeuge" 3-card grid | `title`, `description`, `icon`, `ctaLabel`, `ctaHref`, `sortOrder` | | `testimonials` | Customer testimonial grids on `/todo-cards`, `/newsletter`, `/challenge` | `quote`, `name`, `role`, `avatar`, `page` (`todo-cards`/`newsletter`/`challenge` — which page's grid this appears in), `sortOrder`. The single-quote "photo band" testimonials on `/not-found` and `/bestellbestaetigung` are a different shape (no avatar/role) and stay hardcoded, not part of this collection. | | `media` | Shared upload collection backing every `image`/`icon`/`thumbnail`/`attachment` field above | `alt` (required for images), `title` (optional display name for download links) | | `orders` | Persisted checkout orders, `/konto/bestellungen*` | `orderNumber`, `invoiceNumber`/`invoiceIssuedAt`, `correctionInvoiceNumber`/`correctionInvoiceIssuedAt` (see "Invoice PDFs" below), `status` (`received`/`processing`/`shipped`/`delivered`/`cancelled`/`return_requested`/`returned` — the first 4 maintained by hand in the admin, no carrier API; the rest see "Order cancellation & returns"), `returnReason` (captured from the customer on a return request), full address/items (each with a snapshotted `taxRatePercent`/`bundleContents`)/totals at order time. **Not public-read** — created only via `ORDER_SERVICE_SECRET`, read/updated by admin or the order's own customer | | `customers` | Storefront accounts — register/login/order-history, a second `auth: true` collection separate from the Payload admin's own `users` login | `customerNumber`, `firstName`/`lastName`/`email`, one default address, `cart` (server-side mirror), `emailVerified` (non-blocking). **Not public-read** — see "Orders & customer accounts" below | | `number-ranges` | Admin-configurable prefix + running counter for customer/order/invoice numbers — one row per tenant | `customerPrefix`/`customerNext`/`customerPadding`, `orderPrefix`/`orderNext`/`orderPadding`, `invoicePrefix`/`invoiceNext`/`invoicePadding`. **Admin-only**, no frontend read at all — internal to the two `beforeChange` hooks that assign these numbers | | `email-templates` | Editable subject/heading/body/footer for all 6 transactional emails this shop sends (see "Email templates & Live Preview" and "Status-change emails" below) | `type` (`order-confirmation`/`password-reset`/`order-shipped`/`order-cancelled`/`order-return-requested`/`order-returned`), `subject`, `heading`, `bodyText`, `footerText`. Public-read, has a Live Preview button | | `company-settings` | Structured business data for invoice PDFs *and* every email footer's company line (see "Invoice PDFs" below) — one row per tenant, own **Company** admin group (not Commerce — this is business identity, not a storefront concern) | `sellerName`/`sellerStreet`/`sellerZip`/`sellerCity`/`sellerCountry`/`sellerEmail`, `vatId`, `taxRatePercent` (admin-editable, not hardcoded), `bankDetails`. **Not public-read** — admin or `ORDER_SERVICE_SECRET`. Has a Live Preview button — see "Company Settings & Live Preview" below | All of the above except `company-settings`, `media`, `users`, `tenants` are grouped in the Payload admin sidebar under **Commerce** (`products`, `discount-codes`, `orders`, `customers`, `number-ranges`, `email-templates`, `shipping-methods`, `shipping-settings`, `payment-methods`, `trust-badges`, `cart-trust-badges`) or **Content** (`posts`, `categories`, `legal-pages`, `werkzeuge-cards`, `testimonials`). `company-settings` sits in its own **Company** group; `media`/`users`/`tenants` sit under **Platform** — `users` and `tenants` are hidden from non-super-admins' nav entirely, and every tenant-scoped collection's own "assigned tenant" field is hidden from non-super-admins in the edit view (though not yet the list view's column — see the infra README's Payload CMS section for why that one's a harder fix). **What an admin can actually configure without a code deploy, at a glance:** product/shipping/payment catalog data and `active` toggles (incl. per-product tax-rate overrides and defining a product as a bundle), discount codes, all page content (blog/legal/testimonials/trust badges), delivery-time disclosure (`shipping-settings`), order/customer/invoice numbering schemes (`number-ranges`), all 6 email wordings (`email-templates`, with Live Preview), and invoice seller data, bank details, and VAT rate (`company-settings` — also what every email's footer company line is sourced from). What still requires a code change: adding a new *field* to any collection (needs a migration), payment processing itself (not built), and anything structural in `orders`/`customers` beyond `status`/`returnReason` and the profile fields already exposed on `/konto/profil`. Adding a *new field* to any collection above requires editing the collection file in `docker/payload/src/collections/` and a migration, which does need a deploy of the Payload service. ### Live Preview `posts`, `legal-pages`, and `testimonials` support Payload's Live Preview — opening a document in the Payload admin shows this app's real rendered page in an iframe, updating as you type, no save required. `email-templates` also has Live Preview, but against a synthetic page + sample data rather than one of these three's own real page — different enough to cover separately, see "Email templates & Live Preview" further below. - **`app/api/preview/route.ts`** — validates `PAYLOAD_PREVIEW_SECRET` (matching value required on the Payload side too, or this route 401s) and a `path`, enables Next.js Draft Mode, then redirects into the real page. This is the link Payload's `livePreview.url` resolvers point at (see `docker/payload/src/lib/previewUrl.ts` in the infra repo) — never the page directly. - Each supported page checks `draftMode().isEnabled` and renders a `"use client"` Live-Preview-aware component instead of the plain static one only when it's `true` — ordinary visitors are never in Draft Mode, so they always get the plain version with zero extra client JS: - `app/components/LiveRichText.tsx` — the 4 legal pages' body content (their headings/sidebars are hardcoded per page, not CMS-sourced, so `content` is the only field worth live-previewing there) - `app/blog/[slug]/components/LivePostContent.tsx` — title/excerpt/ thumbnail/body of a blog post (the author bio card, "Weiterlesen" card, and Footer stay static — they either aren't post-specific or are about a *different* post, not the one open in the admin) - `app/components/LiveTestimonialsGrid.tsx` — the one testimonial currently open in the admin, merged by `id` into the rest of that page's already-fetched grid (Live Preview is inherently single-document, but this page renders several at once) - All three use `@payloadcms/live-preview-react`'s `useLivePreview` hook and reuse the same mapping functions (`mapPayloadPost`, `mapPayloadTestimonial`, exported from `app/lib/payload.ts`) the plain server-side fetchers use, so the two code paths can't silently drift apart. - `app/lib/payload.ts` deliberately never imports `next/headers` itself — callers (the Server Component pages) call `draftMode()` themselves and pass the result in as a plain `{ draft: boolean }` option. Importing `next/headers` anywhere in that module breaks the production build the moment a `"use client"` component (which also needs this file's mapping functions/types) tries to bundle it — a real RSC-boundary regression hit once already when adding this feature. ## Discount codes Applied in `/cart` only (`/checkout` displays the already-applied result, no second input) — real server-side validation, not just a client-side check against Payload's public API, unlike most content on this site. - **No manual input field anymore** — the Rabattcode section on `/cart` (`CartContent.tsx`) only renders at all when a code is actually applied; there's no open "enter a code" box for every visitor (Nutzer-Entscheidung: less visual noise, and codes are meant to be shared as marketing links, not guessed/typed in). Instead, `?code=SAVE10` on the `/cart` URL auto-applies once on arrival (a `useEffect` reading `useSearchParams()` — requires `/cart`'s `page.tsx` to wrap `CartContent` in ``, a Next.js requirement for any `useSearchParams()` consumer). A code that arrives via the URL but turns out invalid/expired still shows an inline error, just without an input box to attach it to. - **`app/lib/discountServer.ts`** (server-only, imported exclusively by the two route handlers below — never by a `"use client"` component, same reasoning as Live Preview's `next/headers` lesson above) talks to Payload's `discount-codes` collection using an `x-discount-service-secret` header (`DISCOUNT_SERVICE_SECRET`), since that collection isn't public-read. - **`app/api/discount/validate/route.ts`** — read-only check (active / validity window / minimum order value / remaining redemptions), called when a shopper clicks "Anwenden" in the cart. - **`app/api/discount/redeem/route.ts`** — re-validates, then increments the collection's `redemptionCount`. Called exactly once, from `CheckoutContent.tsx`'s `handlePurchase()`, right before the `OrderSnapshot` is written — a code that expired or hit its redemption cap between being applied in the cart and the actual purchase click fails the purchase with an inline error instead of silently completing. - **`app/lib/discount.ts`** mirrors `lib/cart.ts`'s exact `localStorage` + `useSyncExternalStore` pattern, so the applied code survives the `/cart` → `/checkout` navigation the same way the cart itself does. - **`app/lib/cartTotals.ts`** — `computeSubtotal()`/`computeCartTotals()`, factored out of what used to be independently-duplicated subtotal/ savings/total math in `CartContent.tsx`, `CheckoutContent.tsx`, and `BestellbestaetigungContent.tsx`; now also folds in the discount amount (clamped so a total can never go negative). `OrderSnapshot` persists the applied `discountCode`/`discountAmount` so the confirmation page shows what actually happened, not a fresh re-derivation. - Known, accepted limitation: the redeem route's read-then-increment isn't atomic against a true concurrent race on a capped code's very last redemption — not worth custom atomic SQL at this shop's traffic level. ## Cart & checkout - **Cart** (`app/lib/cart.ts`) is entirely client-side, stored in `localStorage` under `ep_cart`, keyed by each product's `slug`. Still the source of truth while browsing — the server-side mirror (see below) only exists to carry a logged-in customer's cart across devices/browsers. - **`app/cart/components/RelatedProducts.tsx`** only ever suggests products not already in the cart — it stopped falling back to re-suggesting an already-in-cart product just to pad the grid out to 3 cards, so with a small catalog it can render fewer cards (down to 1, centered in the 12-column grid) rather than recommending something already added. - **`/checkout`'s "Jetzt kaufen" always goes through `POST /api/checkout`.** That route re-prices the entire cart server-side from Payload's live product data (never trusts client-submitted prices), re-validates+redeems a discount code exactly once, registers a new account inline if nobody's logged in yet ("Konto Pflicht" — see below), and only then creates the order in Payload's `orders` collection via `app/lib/orderServer.ts`. `app/lib/order.ts`'s `OrderSnapshot` is still written to `sessionStorage` for `/bestellbestaetigung` to read once, but its `orderNumber`/`orderDateIso` now come back from that Payload create call, not generated client-side. - **Order confirmation email** is sent from `/api/checkout/route.ts` right after a successful `createOrder()` — fire-and-forget (`app/lib/orderEmail.ts`'s `sendOrderConfirmationEmail()`), never blocks or fails the checkout response itself; a send failure alerts admin instead (`sendCriticalAlert`, lower severity than the "order not persisted" alert, since the order itself is safe either way). Content comes from the **published** `order-confirmation` row in Payload's `email-templates` collection — see "Email templates & Live Preview" below for how that's edited/previewed. As of the invoice PDF feature (see below), this same send also carries the order's invoice PDF as an attachment. - Still not built: real payment processing — the checkout button is labelled "zahlungspflichtig" but nothing actually captures a payment yet. See `project_backend_checkout_plan` in the assistant's own memory. ### Product bundles & per-product tax rates Both resolved server-side in `/api/checkout/route.ts`, at the same point prices are already being re-derived from live Payload data (never trusted from the client): - **Tax rate**: `product.taxRatePercent ?? companySettings.taxRatePercent` — a product's own override if set, otherwise the tenant-wide default from `company-settings` (fetched alongside the product catalog, `Promise.all([fetchProductsBySlug(), getCompanySettings()])`). Snapshotted onto `orders.items[].taxRatePercent` at order creation — see the Payload README's "Per-product tax rates" section for why this has to be a snapshot, not a live lookup. - **Bundles**: `describeBundleContents()` resolves a product's `bundleItems` (Payload relationship, populated via `fetchProductsBySlug()`'s `depth: 2` fetch — one level deeper than the `depth: 1` `image` alone needs, since `bundleItems.product` is a relationship nested inside an array field) into a plain string like `"2× ToDo-Karten, 1× Wochenplaner"`, snapshotted onto `orders.items[].bundleContents`. A bundle is otherwise just a regular product everywhere else in this app — same cart/checkout/ pricing code path, no special-casing needed, since it's just a product with an extra field (see the Payload README's "Product bundles" section for why it's modeled that way instead of a separate collection). ## Invoice PDFs Generated **synchronously at checkout** and attached to the order confirmation email — not just an on-demand download — per an explicit product decision that a customer should always have the invoice in their inbox, not only in `/konto/bestellungen`. - **`app/lib/invoicePdf.tsx`** — a `@react-pdf/renderer` `Document` (`InvoiceDocument`), not HTML-to-PDF or a headless browser (Puppeteer/ Chromium would be a heavier footprint on a VPS already running several other containers). Built-in Helvetica rather than a registered web font — this renders inside a fire-and-forget checkout step, and a font-fetch failure there would be one more way to silently lose the attachment for no real design benefit; brand color/spacing still carries the visual identity via `StyleSheet`. - **Layout**: a header separated by a bold brand-colored rule (not a filled color band — a plain line reads cleaner than a solid block of color across the top) with the wordmark + "RECHNUNG" label, seller/buyer addresses, invoice number/date/order-reference/USt-IdNr. shown as small bordered "meta boxes" rather than a plain text row, a rounded/bordered item table with alternating row shading, and a shaded summary card for the totals — deliberately closer to the site's own card-based UI language than a generic invoice template. The footer is pinned to the bottom of the page (`position: absolute` + react-pdf's `fixed` prop), not just wherever the content flow happens to end. - **"Bereits beglichen" badge**: shown next to the meta boxes whenever `order.paymentMethodTitle` is anything other than `"Überweisung"` (bank transfer) — Kreditkarte and PayPal both settle at checkout, so the invoice says so explicitly (`isPaidImmediately()` in `invoicePdf.tsx` — "Überweisung" is the one method named explicitly as the exception, rather than hardcoding a list of "immediate" titles that would need updating every time a new payment method is added in Payload). - **Bank details**: `company-settings.bankDetails`, when set, prints in the footer as "Bankverbindung (für Überweisung): …" — for the case a customer paid (or still needs to pay) by bank transfer and needs the account details to do so. Currently seeded with a placeholder IBAN/BIC, same caveat as the rest of `company-settings`' seller data below. - **Per-tax-rate summary**: line items are grouped by their own snapshotted `taxRatePercent` (see the Payload README's "Per-product tax rates" section) and the summary prints one "Netto (X%)" / "zzgl. X% MwSt." pair per distinct rate actually present in that order — a plain single pair in the common case (one rate for the whole order), a real multi-rate breakdown the moment a product with a different rate is involved. The order-level discount/shipping are distributed proportionally across each rate group before computing net/tax, so the grouped totals still reconcile exactly to `order.total`. - **Bundle contents**: an item row for a bundle product also shows the small muted `bundleContents` sub-line snapshotted at order time (see the Payload README's "Product bundles" section). - **`app/lib/invoiceData.ts`** — `generateInvoicePdf(order, seller)` / `generateCorrectionInvoicePdf(kind, order, seller)`, the render entrypoints every caller below goes through. `seller` (`company-settings` data) is passed in rather than fetched inside these functions, so a caller that also needs it for something else in the same request (e.g. `orderEmail.ts`'s email footer, see "Configurable company data" below) fetches it once via `getSellerForInvoice()`, not twice. - **Original invoice — called from two places, same render function:** `app/lib/orderEmail.ts` (checkout attachment — a PDF-generation failure here does **not** sink the confirmation email itself, it just sends without the attachment and alerts admin) and `app/api/account/orders/[orderNumber]/invoice/route.ts` (GET, customer's own order only, "Rechnung herunterladen" on `/konto/bestellungen/[orderNumber]`) — a re-download always matches what was originally emailed, since `invoiceNumber`/`invoiceIssuedAt` are assigned exactly once, server-side, at order creation (Payload's `orders.ts` `beforeChange` hook — see the Payload README) and never regenerated. - **Correction invoice (Stornorechnung/Gutschrift) — same "no file storage" approach.** The *real* document is generated once, Payload-side, the moment an order reaches `cancelled`/`returned` (see the Payload README's "How a Stornorechnung/Gutschrift relates to the original invoice" section for the full legal/mechanical reasoning) and attached to that status email. `app/lib/correctionInvoicePdf.tsx` is a **frontend port** of that same renderer (visually identical, ported not shared — two separate deployments, same relationship as `emailShell.ts`) used purely so `/konto/bestellungen/[orderNumber]` can offer a "Stornorechnung/ Gutschrift herunterladen" download button (`app/api/account/orders/[orderNumber]/correction-invoice/route.ts`) without storing the PDF as a file anywhere: `correctionInvoiceNumber`/ `correctionInvoiceIssuedAt` are immutable once set (Payload's `beforeChange` hook), so re-rendering from the order's own stored data always reproduces the identical document. Deliberately not persisted to disk/S3/Media — the underlying data is already durable in Postgres, and deterministic regeneration needs no cleanup or storage cost, same reasoning already applied to the original invoice. - **`company-settings`** (Payload collection, structured seller data — name/address/`vatId`/`taxRatePercent`/`bankDetails`) is fetched via `getCompanySettings()`/`getSellerForInvoice()`, authenticated the same way as order creation (`x-order-service-secret` header, `ORDER_SERVICE_SECRET`) since it's not public-read (holds bank details) but does need to be reachable from this app's own server-side code, not just from inside Payload's admin. **Currently seeded with placeholder data** ("Björn Wendt", "Musterstraße 12", USt-IdNr. "DE123456789", a placeholder IBAN/BIC) mirroring the Impressum's own placeholder content — real business details need to be entered in the Payload admin before an invoice generated from this is legally valid. `taxRatePercent` is deliberately a configurable admin field, not a hardcoded `19` in the renderer, per an explicit decision to keep the VAT rate editable without a code change. - §14 UStG line items: seller/buyer address, invoice number + date, order reference, per-item quantity/price, net subtotal per rate, tax rate + amount per rate, gross total — all on the PDF, not just the summary the confirmation email's HTML already shows. ### Company Settings & Live Preview `company-settings` has a Live Preview button too, like `email-templates` — but instead of an HTML page, it's a **live, in-browser rendered PDF**: opening the document in the Payload admin shows the actual invoice layout updating as the admin edits `sellerName`/address/`taxRatePercent`/ `bankDetails`, no save required. - **`app/company-settings-preview/page.tsx`** + **`components/LiveCompanySettingsPreviewClient.tsx`** — same entrypoint pattern as `/email-preview/[type]` (Draft Mode via `app/api/preview/route.ts`), but no `[type]` segment — there's only one kind of document here, unlike the 6 email types. **Actually gated on `draftMode().isEnabled`** (calls `notFound()` otherwise), unlike `/email-preview` — this data includes a real bank IBAN/address once filled in, not just marketing email copy, so it must not render for an unauthenticated visitor who happens to find the URL. - **`@react-pdf/renderer`'s ``** (not `renderToBuffer()`) is what makes this a *live* preview rather than a static download — it's a browser-only component that renders a `Document` straight into an embedded PDF viewer `