Commandes

Résultat : suivez séparément le cycle commercial, le paiement, le remboursement et la couverture de stock avant de préparer ou expédier une commande.

Cycle commercial

Le remboursement est un axe séparé : aucun, partiel ou total. Une commande traitée puis remboursée reste traitée avec son badge financier.

Transitions et réconciliation

Les actions normales font passer une commande en attente vers payée ou annulée, une commande payée vers traitée, et une impayée trop ancienne vers expirée. Une commande payée ne s’annule normalement qu’après remboursement intégral.

Forcer le statut sert uniquement à réconcilier un cas anormal. Il exige un motif et n’effectue ni capture, ni remboursement, ni correction de montant ou devise. Repasser une commande annulée ou expirée à payée retente l’allocation de stock : relisez toujours la couverture avant fulfillment.

Liste et détail

La liste s’ouvre avec Action requise activé. Elle peut être filtrée par statut commercial, remboursement, action requise, identifiant public ou email acheteur.

Le détail affiche séparément :

• client et adresses snapshotées ;
• lignes, options et montants exacts ;
• livraison promise et coût transporteur ;
• paiements et remboursements ;
• réservations et action requise ;
• documents, médias, historique et workflow.

L’onglet Écarts de prix compare la livraison promise au tarif courant sans recalculer la commande.

Snapshot de vente

À la création, la commande fige notamment les lignes, SKU, options, prix, adresses, zone, livraison promise, taxes et éventuelle conversion de devise. Une modification ultérieure du catalogue ou des grilles ne réécrit jamais ce snapshot.

Les prix sont TTC. Les taxes affichées décomposent le montant déjà inclus ; elles ne sont pas ajoutées une seconde fois. Toute arithmétique monétaire et toute conversion sont calculées par le serveur.

Réservations

La réservation est tentée avant le paiement. Son résumé peut être :

Action requise peut signaler un manque, mais aussi une réservation sur un entrepôt de priorité zéro qui exige un dispatch manuel.

L’allocation automatique utilise les entrepôts publiés, d’abord par priorité puis par proximité, et protège le stock de sécurité. Une ligne sans stock requis peut être vendue ; son stock existant reste néanmoins réservé en best effort.

Actions disponibles :

• Compléter automatiquement retente l’allocation.
• Changer d’entrepôt libère la source puis réserve sur la cible.
• Libérer retire une réservation active.
• Acquitter masque l’action humaine sans créer, déplacer ou consommer du stock.

Le plan complet permet de répartir manuellement les lignes. Il remplace atomiquement toutes les réservations actives et refuse une version devenue obsolète. Il peut utiliser un entrepôt non publié et le stock physique libre sans protéger le seuil de sécurité : contrôlez chaque quantité avant validation.

Fulfillment, annulation et expiration

Le fulfillment d’une commande payée consomme les réservations actives, diminue le stock physique correspondant et passe la commande à traitée. Une couverture incomplète exige un motif ; seules les quantités réellement réservées sont consommées.

Annuler ou expirer une commande impayée libère les réservations sans augmenter le stock physique. Une réservation déjà consommée n’est jamais recréée par ces transitions. Le fulfillment ne peut pas être annulé pour fabriquer du stock.

Création boutique ou admin

Le checkout verrouille le panier, relit version, conditions de vente, géographie, livraison, prix et stock, puis crée une commande de façon idempotente pour une même tentative. Une tentative rejouée avec un contenu différent est refusée.

Une commande au nom d’un client utilise le même moteur, mais conserve la dérogation explicite des lignes admin et n’invente aucune acceptation des conditions. Voir Commandes au nom d’un client.

Paiement

Le statut du prestataire, la validation de sa preuve et le statut de commande restent trois axes indépendants. Stripe converge depuis un événement fiable ; PayPal exige une capture après approbation ; un total serveur exact de zéro utilise un paiement local gratuit.

Une commande ne devient payée que lorsque montant et devise correspondent exactement à son snapshot, ou lorsqu’un marchand atteste un règlement hors ligne. Une reprise ou un webhook rejoué ne doit pas produire un second effet métier.

Consultez Anomalies de paiement avant toute correction incertaine et Remboursements avant de restituer des fonds.

Devis et facture

• Le devis est disponible tant que la commande attend son paiement. Il est rendu à la demande et ne modifie rien.
• La facture est disponible une fois la commande payée. Son numéro et sa date sont attribués une seule fois puis réutilisés.

Le HTML est rendu à la demande avec l’identité et le modèle courants. ModuShop ne stocke pas automatiquement un PDF légal immuable ; utilisez l’impression locale si elle convient à votre obligation d’archivage.

Les médias joints à la commande ne génèrent ni facture, ni reçu, ni étiquette.

Récupération

Voir aussi

• Stock et entrepôts
• Tarification de la livraison
• Paiement
• Workflow de commande