La carte « Valeur retournée (résolue) » du tableau de bord Analyses additionne désormais le montant que l'acheteur a réellement payé, remises appliquées. Elle utilisait auparavant le prix catalogue de l'article : dans les boutiques qui vendent avec des remises, le chiffre ressortait donc au-dessus de la réalité.
Ce qui change dans la carte « Valeur retournée »
Quand l'acheteur sélectionne des articles précis de sa commande, returnEasier additionne la valeur de ces articles. Jusqu'ici il prenait le prix catalogue de chaque ligne ; à partir d'aujourd'hui il prend le prix unitaire remisé, c'est-à-dire ce qui a effectivement été encaissé.
- Si votre boutique n'applique pas de remises ni de promotions, le chiffre ne bouge pas.
- Si vous en appliquez, vous verrez un montant plus bas et plus honnête pour la même période. Aucune donnée n'est perdue : c'est le même retour, correctement valorisé.
- Sur les commandes anciennes qui n'ont pas enregistré le montant payé, nous continuons d'utiliser le prix catalogue par défaut.
Le contexte complet du tableau de bord se trouve dans le guide analyses et alertes.
Votre offre n'est plus rétrogradée à cause d'un nom inconnu
returnEasier demande à Shopify quelle est votre offre active pour savoir quelles fonctions ouvrir. Si le nom d'offre renvoyé par Shopify ne correspondait à aucun des nôtres — après avoir renommé une offre, par exemple —, l'application le lisait comme « aucune offre » et pouvait laisser un marchand qui paie avec les fonctions de l'offre gratuite.
Désormais, une offre que nous ne reconnaissons pas signifie « on n'y touche pas » : votre offre enregistrée reste telle quelle. Les résiliations et les expirations font toujours passer à Free, exactement comme avant, car ce sont des signaux clairs. Une offre inconnue ne déclenche plus non plus les avis de quota d'essai, et le bouton légal de rétractation reste actif dans tous les cas. Pour revoir la synchronisation de l'offre, consultez le guide changer d'offre et facturation.
« Approuver + étiquette » vérifie l'adresse complète
Générer une étiquette de retour avec votre compte Sendcloud (offre Scale) exige vos clés et une adresse de retour complète. Le contrôle précédent se contentait de l'existence d'une adresse, même incomplète, et l'échec apparaissait plus tard, au moment de demander l'étiquette à Sendcloud.
returnEasier exige maintenant nom, adresse, code postal, ville et pays avant de proposer l'action. S'il en manque un, vous verrez l'invitation à configurer Sendcloud dans Paramètres → Étiquettes de retour au lieu d'une erreur en cours de route. Détails dans le guide étiquettes d'expédition avec Sendcloud.
Le journal d'audit, verrouillé dans la base de données
L'historique de chaque demande est une chaîne d'événements liés par hachage : c'est ce qui permet de prouver lors d'un contrôle que rien n'a été modifié. Que cette chaîne soit linéaire était jusqu'ici une règle respectée par notre code ; depuis cette version, c'est aussi une contrainte de la base de données (un seul maillon par maillon précédent, et un unique événement d'origine par demande). Si quelque chose tentait de la bifurquer, returnEasier s'arrête au lieu de choisir une branche.
Vous n'avez rien à faire : vos demandes existantes restent inchangées et l'export auditable continue de signaler toute chaîne problématique.