Commerce

cmssy embarque un panier, des commandes, des remises et un pipeline de commandes. Rien de tout cela n'est un module à part : un produit est un enregistrement de modèle, la boutique parle à la même API de diffusion que le reste, et le bureau des commandes est l'admin.

La capacité est un drapeau du plan - canUseCart dans get_workspace_info - lisez-le plutôt que de le supposer.

Les produits sont des enregistrements

Il n'existe pas de type produit dans cmssy. Vous créez un modèle - product, plan, ticket, quel que soit votre catalogue - et la configuration panier de l'espace de travail le relie au panier via une source de produits : quel modèle, quel champ est le prix, lequel le stock, lesquels les variantes.

C'est pourquoi un catalogue peut venir de plusieurs modèles à la fois, et pourquoi le même bloc qui affiche n'importe quel enregistrement affiche un produit.

Ce que la boutique peut appeler

L'espace cart est public : sans jeton, porté par la session, et c'est la seule partie de l'API de diffusion qui écrit.

• cart.get(workspaceId) - lignes, subtotal, tax, shippingTotal, discountedTotal, totalGross, currency, pricesIncludeTax, availableShippingMethods, appliedDiscount, taxSummary.
• cart.addItem - { recordId, quantity, variantSelections, notes }. La ligne référence l'enregistrement, elle n'en est pas une copie.
• cart.updateItem, cart.removeItem(itemId), cart.clear.
• cart.applyDiscount(code), cart.removeDiscount, cart.setShippingMethod(shippingMethodId).
• cart.merge - fusionne le panier de session anonyme avec celui du membre connecté. À appeler une fois, juste après l'authentification.
• cart.checkout - { customerEmail, customerNote, poNumber, shippingAddress } transforme le panier en commande.

Les totaux reviennent calculés. N'additionnez pas les prix dans le navigateur : mode de TVA, remises et livraison se décident côté serveur, et une seconde implémentation dans votre frontend est une seconde réponse.

Suivi de commande sans compte

public.order.byToken renvoie une commande - orderNumber, items, paymentStatus, fulfillmentStatus, amountPaid, balanceDue, invoiceUrl - pour le jeton émis au checkout. C'est ainsi que fonctionne une page « suivre ma commande » pour un invité.

Ce que configure l'espace de travail

public.siteConfig.publicCart est la projection sûre des réglages du panier : defaultCurrency, pricesIncludeTax, taxRates, shippingMethods, productSources, maxItemsPerCart, maxQuantityPerItem, enableSavedCarts, enableQuoteRequests. Lisez-la une fois et laissez-la façonner l'interface : format de devise, limites de quantité, et si une demande de devis est proposée du tout.

Les commandes sont du back-office

Tout ce qui suit le checkout est autorisé : l'admin, ou le serveur MCP avec un jeton dont le rôle le permet. Les commandes se listent et se lisent, se créent à la main, s'éditent ligne par ligne, se marquent payées en totalité ou en partie, se remboursent, s'annulent, avancent dans le fulfillment, reçoivent une facture et se déplacent le long d'un pipeline configurable. Les remises se créent, se modifient et s'activent de la même façon ; les produits se modifient ou se suppriment en masse, ou reçoivent des paliers de prix.

Les prestataires de paiement n'en font pas partie : cmssy enregistre ce qui s'est passé - mark_order_paid, record_order_payment, refund_order - et votre intégration décide quand cela s'est passé.

Étapes suivantes

• Modèles de données - les enregistrements dont un catalogue est fait.
• API de diffusion GraphQL - comment une écriture publique est cadrée.
• Webhooks - les dix événements order.*.