> ## Documentation Index > Fetch the complete documentation index at: https://storekit.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Commandes Stream > Comment les commandes storekit parviennent à Stream : envoi, mise en tampon, contenu, mises à jour de statut, annulations et gestion des échecs. Dès qu'une boutique est connectée à Stream, chaque commande qui y est passée est automatiquement mise en file d'attente vers Stream. Stream transmet la commande à votre POS et renvoie l'information au fil de sa progression. ## Comment une commande parvient à Stream 1. Le client termine le paiement et la commande est créée dans storekit. 2. storekit met la commande en file d'attente vers Stream : immédiatement pour une commande ASAP, ou de manière différée pour une précommande quand **Buffer Orders** est activé. 3. storekit construit la commande Stream et l'envoie. Si Stream refuse la requête, storekit réessaie jusqu'à six fois de plus en l'espace de quelques secondes. 4. Stream signale **accepted** : la commande est marquée **Accepted** dans storekit et la timeline enregistre le changement de statut en provenance du POS. 5. Stream signale un changement de statut ou une annulation au fur et à mesure de la progression de la commande. > [!NOTE] > > Les commandes partent vers Stream dès qu'elles sont passées : il n'y a pas d'étape d'acceptation préalable dans storekit. Les commandes multi-vendeurs sont fusionnées en une seule commande Stream avant envoi, si bien qu'un client qui commande auprès de plusieurs vendeurs à la fois apparaît au POS comme un seul ticket. ## Ce que contient la commande | storekit | Stream | | - | - | | Articles, variations et modificateurs | Envoyés avec leurs identifiants Stream (les IDs importés lors de la [synchronisation du menu](/docs/fr/guides/integrations/pos/stream/menu-sync)), les quantités, les prix et les notes par article. Les modificateurs imbriqués sont envoyés sous leur modificateur parent. | | Méthode d'exécution | **Pickup** → `pickup`, **Delivery** → `merchant_managed_delivery`, **Curbside** → `curbside`, **In Store** et **Add to Bill** → `dine_in`. | | Client | Nom, e-mail et téléphone. Un nom manquant est envoyé sous *Placeholder*, et un téléphone manquant sous le numéro fictif `+447700900000`, afin que le POS dispose toujours d'un contact. | | Heure demandée | Envoyée comme heure estimée de disponibilité, et la commande est marquée comme future lorsqu'il s'agit d'une précommande. | | Pourboire et frais de service | Les deux sont envoyés ensemble comme pourboire de la boutique par défaut. Si le support storekit a activé la gestion des frais de service sur la boutique, ils sont envoyés comme frais de service à la place. | | Frais de livraison et adresse | Envoyés sur les commandes de livraison, avec les notes de livraison du client comme instructions d'exécution. | | Remises | Le montant de la remise, avec le code de remise le cas échéant. | | Couverts | Le choix de couverts du client est envoyé sous *include utensils*. | | Paiement | Les commandes sont toujours envoyées comme payées : Stream ne collecte jamais de paiement pour les commandes storekit. | La taxe n'est pas détaillée par ligne sur la commande Stream ; les prix sont envoyés tels qu'ils apparaissent sur le menu storekit. ## Notes de commande **Order Note Template** sur la page **Stream Integration** contrôle la note envoyée avec chaque commande. Le support peut cliquer sur **Insert Variable** pour voir les variables disponibles et sur **Preview** pour vérifier le résultat avec des données d'exemple. Les notes propres au client sont ajoutées après le modèle, séparées par un tiret. Sans modèle, la note est celle du client. Pour les commandes en magasin sans modèle, storekit préfixe la note par *Table \* et envoie le nom du client sous la forme *\
(\)* pour que le ticket indique clairement à quelle table il correspond : voir [Sur place](/docs/fr/guides/integrations/pos/stream/dine-in). ## Mise en tampon des précommandes Par défaut, une précommande est envoyée à Stream immédiatement, ce qui peut encombrer la cuisine plusieurs heures à l'avance. Pour la différer, demandez au [support storekit](/docs/fr/getting-started/contact-support) de : 1. Activer **Buffer Orders**. 2. Définir **Buffer Value** : la commande est envoyée ce nombre de minutes avant l'heure d'exécution demandée. Cette valeur doit être au moins 1 (*Buffer value must be greater than 0*). Lorsque **Buffer Orders** est activé sans **Buffer Value** enregistré, storekit utilise le calcul habituel du temps de préparation de la boutique pour décider du moment d'envoi. Les commandes sans heure demandée ne sont jamais mises en tampon. > [!TIP] > > 15 à 30 minutes constituent un bon point de départ pour une cuisine chargée. ## Mises à jour depuis Stream Stream peut modifier la commande dans storekit après son acceptation : * **Changements de statut** : `ready_for_pickup`, `out_for_delivery` et `completed` en provenance de Stream font passer la commande à **Ready for Pickup**, **Out for Delivery** ou **Completed** dans storekit, et déclenchent les notifications client habituelles pour ces statuts. Les autres statuts Stream sont ignorés. * **Annulation depuis Stream** : la commande est annulée dans storekit, avec la source enregistrée comme Stream. * **Annulation depuis storekit** : annuler une commande dans le dashboard envoie une demande d'annulation à Stream afin que le ticket POS soit annulé. Les annulations issues de Stream ne sont pas renvoyées. ## Lorsqu'une commande échoue Une commande Stream peut échouer de deux manières : * **Stream refuse la requête.** Si l'API de Stream refuse la commande après les réessais de storekit, la commande est marquée **Failed** et l'équipe storekit est alertée. Aucune raison d'échec n'est enregistrée sur la commande dans ce cas, la page de commande n'affiche donc que le statut **Failed**. * **Stream signale un échec.** Si Stream accepte la requête mais que le POS échoue ensuite sur la commande, Stream envoie un événement d'échec avec une raison. storekit marque la commande **Failed**, enregistre la raison de Stream mot pour mot sur la commande, et envoie un e-mail à la boutique. ### L'e-mail de commande en échec L'e-mail est envoyé lorsque Stream signale l'échec, avec pour objet `Stream Issue: Order # for store: ` et la raison de l'échec dans le corps. Il part vers la liste **Email address** de la boutique dans **Stores** → votre boutique → **Settings** → **General** : la première adresse comme destinataire, les autres en copie cachée. Si cette liste est vide, aucun e-mail n'est envoyé. Lorsque storekit reconnaît la raison, l'e-mail inclut également des conseils sur la marche à suivre. ### Renvoyer une commande en échec Ouvrez la commande dans le dashboard et choisissez **More actions** → **Resend order to POS**. storekit remet la commande en file d'attente vers Stream (en respectant le tampon des précommandes). L'option n'est proposée que tant que la commande n'a pas de reçu POS, et le renvoi est refusé avec *This order has already been sent to the POS. Resending it would create a duplicate POS order.* dès que Stream a accepté la commande, même si le POS l'a ensuite fait échouer. Dans ce cas, vérifiez le POS plutôt que de renvoyer. ## Étapes suivantes > **[Sur place](/docs/fr/guides/integrations/pos/stream/dine-in)** > > Comment les commandes à table parviennent à Stream > **[Dépannage](/docs/fr/guides/integrations/pos/stream/troubleshooting)** > > Commandes qui n'atteignent pas Stream, ou qui échouent après leur envoi ## Related topics - [Stock et disponibilité Stream](/docs/fr/guides/integrations/pos/stream/stock-and-availability.md) - [Sur place Stream : tables](/docs/fr/guides/integrations/pos/stream/dine-in.md) - [Stream](/docs/fr/guides/integrations/pos/stream/overview.md) - [Dépannage Stream](/docs/fr/guides/integrations/pos/stream/troubleshooting.md) - [Connecter Stream](/docs/fr/guides/integrations/pos/stream/connect.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.