Jetzt mit KI-gestütztem Page Building über den MCP-Server

Commerce

Produkte sind Model-Records, der Warenkorb ist ein öffentlicher Mutations-Namespace für deinen Shop, und Bestellungen leben im Admin.

cmssy bringt Warenkorb, Bestellungen, Rabatte und eine Bestell-Pipeline mit. Nichts davon ist ein eigener Produktbereich: Ein Produkt ist ein Model-Record, der Shop spricht mit derselben Delivery-API wie alles andere, und der Bestellschreibtisch ist der Admin.

Die Fähigkeit hängt am Plan - canUseCart in get_workspace_info - lies sie also aus, statt sie anzunehmen.

Produkte sind Records

Einen Produkttyp gibt es in cmssy nicht. Du legst ein Modell an - product, plan, ticket, was immer dein Katalog ist - und die Cart-Config des Workspace bildet dieses Modell über eine Produktquelle in den Warenkorb ab: welches Modell, welches Feld der Preis ist, welches der Bestand, welche die Varianten.

Deshalb kann ein Katalog aus mehreren Modellen zugleich stammen, und deshalb rendert derselbe Block, der jeden anderen Record rendert, auch ein Produkt.

Was der Shop aufrufen darf

Der cart-Namespace ist öffentlich: ohne Token, sitzungsbezogen, und der einzige schreibende Teil der Delivery-API.

  • cart.get(workspaceId) - Positionen, subtotal, tax, shippingTotal, discountedTotal, totalGross, currency, pricesIncludeTax, availableShippingMethods, appliedDiscount, taxSummary.
  • cart.addItem - { recordId, quantity, variantSelections, notes }. Die Position ist eine Referenz auf den Record, keine Kopie.
  • cart.updateItem, cart.removeItem(itemId), cart.clear.
  • cart.applyDiscount(code), cart.removeDiscount, cart.setShippingMethod(shippingMethodId).
  • cart.merge - führt den anonymen Sitzungswarenkorb nach dem Login mit dem des Mitglieds zusammen. Einmal aufrufen, direkt nach der Authentifizierung.
  • cart.checkout - { customerEmail, customerNote, poNumber, shippingAddress } macht aus dem Warenkorb eine Bestellung.

Summen kommen berechnet zurück. Addiere Positionspreise nicht im Browser: Steuermodus, Rabatte und Versand entscheidet der Server, und eine zweite Implementierung im Frontend ist eine zweite Antwort.

Bestellstatus ohne Konto

public.order.byToken liefert genau eine Bestellung - orderNumber, items, paymentStatus, fulfillmentStatus, amountPaid, balanceDue, invoiceUrl - zum beim Checkout ausgegebenen Token. So funktioniert eine „Sendung verfolgen“-Seite für Gäste.

Was der Workspace konfiguriert

public.siteConfig.publicCart ist die shop-sichere Projektion der Cart-Einstellungen: defaultCurrency, pricesIncludeTax, taxRates, shippingMethods, productSources, maxItemsPerCart, maxQuantityPerItem, enableSavedCarts, enableQuoteRequests. Einmal lesen und die UI davon formen lassen - Währungsformat, Mengenlimits, ob eine Angebotsanfrage überhaupt angeboten wird.

Bestellungen sind Backoffice

Alles nach dem Checkout ist autorisiert: der Admin oder der MCP-Server mit einem Token, dessen Rolle es erlaubt. Bestellungen lassen sich listen und lesen, manuell anlegen, Position für Position bearbeiten, ganz oder teilweise als bezahlt markieren, erstatten, stornieren, durch die Fulfillment-Stufen bewegen, mit einer Rechnung versehen und durch eine konfigurierbare Pipeline schieben. Rabatte werden genauso angelegt, aktualisiert und an- oder abgeschaltet; Produkte lassen sich in Bulk ändern, löschen oder mit Preisstaffeln versehen.

Zahlungsanbieter gehören nicht dazu: cmssy hält fest, was passiert ist - mark_order_paid, record_order_payment, refund_order - und deine Integration entscheidet, wann es passiert ist.

Nächste Schritte