Gérez votre catalogue de bundles plus vite et plus sûrement : le Backoffice distingue les bundles et leurs composants des articles simples, et les relie entre eux.

Dans un catalogue qui mêle articles simples et bundles, il faut savoir immédiatement quel article en compose un autre. La page Articles identifie désormais clairement les bundles et leurs composants. La page détaillée d'un bundle liste les articles qui le composent avec leurs quantités, et celle d'un composant indique les bundles auxquels il appartient. Chaque article cité renvoie directement à sa propre page détaillée. 

Ce que cela signifie concrètement :

• Repérez instantanément les articles bundle en parcourant la page Articles du Backoffice.

• Consultez les articles et quantités associés à un bundle ou un composant directement depuis sa page détaillée.

• Naviguez directement d'un article vers les bundles auxquels il appartient, et inversement, grâce à des liens directs.

Diagnostiquez un échec d'étiquette transporteur directement dans le Backoffice, sans enchaîner les échanges entre vos équipes, le support OneStock et celui du transporteur. 

Quand une demande d'étiquette échoue en magasin, la cause peut venir de votre configuration comme du transporteur, et la trouver mobilise souvent plusieurs équipes de support. L'historique d'une commande affiche désormais les appels envoyés au transporteur et leur résultat. Vos équipes distinguent ainsi un modèle d'étiquette mal configuré d'une indisponibilité passagère du transporteur, et savent immédiatement qui doit agir. 

Ce que vous pouvez faire avec cette évolution :

• Étiquette bloquée en magasin : vérifier depuis l'historique de la commande si l'erreur vient du modèle d'étiquette ou du transporteur. Corriger une adresse mal renseignée afin que votre vendeur puisse expédier la commande.

Configurez votre promesse de livraison avec Robin, l'assistant IA de OneStock, de la mise en place initiale aux ajustements du quotidien, en gardant la main sur chaque mise en production. 

Configurer une promesse de livraison demande de l'expertise et du temps, et la modifier en production appelle de la prudence. Robin connaît chacune de ses entités (modes de livraison, transporteurs, routes, zones, restrictions) et les liens entre elles. Il vous guide pas à pas, applique vos modifications sur simple demande et propose des valeurs standards à chaque création. Chaque changement reste en brouillon jusqu'à votre validation. 

Ce que vous pouvez faire avec cette évolution :

• Obtenir une promesse fonctionnelle en quelques minutes, avec Robin qui vous guide à chaque étape de la configuration

• Appliquer une modification unitaire ou en masse en une seule demande, par exemple : « Décale tous les horaires d'enlèvement de 17h à 18h »

• Créer des entités complètes dès le départ : Robin suggère des coûts, délais et horaires standards pour que rien ne manque et que tout fonctionne immédiatement

Obtenez l'aide de Robin dans tous les onglets de configuration, sans activation préalable, avec la même expérience que pour la promesse de livraison. 

Robin s'ouvre désormais dans le même panneau latéral que pour la promesse de livraison, avec la même façon d'échanger. Ses réponses sont structurées et vous mènent directement à la page de configuration concernée. 

Ce que vous pouvez faire avec cette évolution :

• Accéder directement à la bonne page de configuration : Robin vous y redirige automatiquement

• Passer plus vite à l'action grâce à des réponses structurées et claires

• Obtenir de l'aide immédiatement, sans activation ni paramétrage préalable

Configurez votre connecteur Shopify plus simplement : les paramètres sont regroupés par domaine métier, et le suivi des flux dispose de sa propre zone.

Un connecteur Shopify touche à la fois aux commandes, au stock, à la livraison et à la boutique en ligne, et chacun de ces sujets a ses propres paramètres. Son interface s'organise désormais en deux zones. Settings range les paramètres par domaine : Connexion, Commandes, Stock, Livraison, Storefront. Monitoring suit les flux entre Shopify et OneStock : webhooks, produits, stock. Les libellés des paramètres ont aussi été clarifiés.

Ce que cela signifie concrètement :

• Mise en service d'une nouvelle boutique : configurer le connecteur domaine par domaine, de la connexion à la storefront.

• Incident de synchronisation : vérifier au même endroit les webhooks et les flux produits et stock entre Shopify et OneStock.

Décidez vous-même, champ par champ, comment une commande Shopify devient une commande OneStock, et testez votre mapping sur de vraies commandes avant de l'activer.

Chaque enseigne a ses propres marchés, champs personnalisés et metafields, et leur traduction dans OneStock relève de sa configuration. Le mapping des commandes se configure désormais pour chaque instance du connecteur, dans un éditeur JSON avec auto-complétion des champs disponibles. Un cycle de versions « Brouillon » et « Actif » et un mode test protègent la production. La documentation fournit une structure JSON commentée, des cas d'usage types et un prompt IA prêt à l'emploi. 

Ce que vous pouvez faire avec cette évolution :

• Adapter le mapping à vos marchés, champs personnalisés et metafields dans un éditeur JSON, avec auto-complétion des champs disponibles. 

• Travailler sur un brouillon en toute sécurité : la version active reste en lecture seule, la publication demande une confirmation et vous pouvez revenir à la dernière version active en un clic. 

Sécurisez les échanges entre Shopify et OneStock : chaque webhook passe par une file d'attente, les erreurs temporaires sont retentées automatiquement et les événements en échec peuvent être rejoués. 

Les échanges entre Shopify et OneStock reposent sur des webhooks, exposés aux erreurs temporaires d'un côté comme de l'autre. Tous les webhooks du connecteur, des commandes aux statuts des colis, passent désormais par une file d'attente traitée par un worker dédié, qui détecte les doublons. Une erreur temporaire déclenche une nouvelle tentative automatique, sans que Shopify ne désactive le webhook. Les événements en échec sont mis de côté, consultables dans un historique et rejouables. 

Ce que vous pouvez faire avec cette évolution :

• Compter sur une reprise automatique en cas d'erreur temporaire, sans désactivation du webhook.

• Retrouver les événements en échec, mis de côté, et les rejouer.

• S'appuyer sur un traitement unique de chaque événement, jamais en double.