Product Return Manager — Guide complet

DataFirefly Product Return Manager transforme la gestion des retours PrestaShop 8 en un flux automatisé de bout en bout : demande client en self-service (compte client ou invité), étiquette PDF avec code QR, validation par scan à réception, analytics à 13 axes, bon d’achat ou remboursement, retour manuel admin, traduction automatique des raisons via ChatGPT et intégration ERP via hook. Cette documentation couvre l’installation, la configuration complète et l’usage quotidien.

Installation

Installation standard PrestaShop : allez dans Modules → Gestionnaire de modules → Installer un module, sélectionnez le fichier dfproductreturn.zip, et confirmez. Le module crée automatiquement 9 tables préfixées df_return_* et df_product_return*, installe des raisons de retour par défaut, enregistre ses hooks (displayCustomerAccount, displayMyAccountBlock, displayHeader, etc.) et ajoute deux entrées de menu au back-office : Retours produits (gestion) et Analytics retours (statistiques).

Configuration

Rendez-vous dans Modules → Gestionnaire de modules → DataFirefly Product Return Manager → Configurer. Les réglages principaux :

• Délai de retour (jours) — fenêtre pendant laquelle le client peut demander un retour après sa commande. 30 jours par défaut. Ne s’applique qu’aux retours initiés côté client ; le retour manuel admin l’ignore.
• Statuts de commande éligibles — seuls les commandes dans ces statuts affichent le bouton « Demander un retour » (typiquement « Livré »).
• Activer le bon d’achat — propose l’option bon d’achat comme mode de compensation.
• Activer le remboursement — propose l’option remboursement sur le moyen de paiement d’origine.
• Email admin — adresse notifiée à chaque nouvelle demande de retour.
• État remboursement partiel / complet — les deux états de commande appliqués selon le type de remboursement effectué.
• Clé API OpenAI — requise uniquement pour la traduction automatique des raisons de retour via ChatGPT (voir section dédiée).

Raisons de retour et catégories

Le module organise les raisons sur deux niveaux : des catégories (« Problème produit », « Problème logistique », « Changement d’avis »…) et des raisons rattachées à chaque catégorie (« Taille incorrecte », « Article défectueux », « Livraison trop longue »…). Cette hiérarchie alimente les analytics : vous voyez la répartition macro par catégorie, puis le détail par raison.

Gérez-les depuis l’onglet Raisons de la configuration : création, édition, désactivation, ordre d’affichage. Des raisons par défaut sont installées avec le module — adaptez-les à votre catalogue.

Traduction automatique via ChatGPT

Une fois votre clé API OpenAI renseignée dans la configuration, un bouton Traduire apparaît sur chaque raison et catégorie. Un clic traduit le libellé dans toutes les langues activées de la boutique, avec un vocabulaire e-commerce contextualisé. Les traductions restent éditables manuellement après génération. Obtenez votre clé sur platform.openai.com — le coût par traduction est négligeable (fractions de centime).

Parcours client (compte client)

Le client connecté voit un lien « Mes retours » dans son espace client. Pour initier un retour :

1. Il ouvre la commande éligible et clique « Demander un retour ».
2. Il coche les produits à retourner et ajuste les quantités.
3. Il choisit une catégorie de raison, puis une raison précise, et ajoute un commentaire optionnel.
4. Il valide — le retour passe en statut « En attente » et deux emails partent : confirmation au client avec le PDF d’étiquette en pièce jointe, notification à l’admin.

Le client suit ensuite l’état de son retour (en attente, accepté, refusé, remboursé) depuis « Mes retours », avec la possibilité de re-télécharger son étiquette PDF à tout moment.

Retour invité (v1.7+)

Les clients ayant commandé sans créer de compte accèdent au retour depuis la même URL que les clients connectés. Un visiteur non authentifié voit un formulaire « Numéro de commande + email » à la place de la liste « Mes commandes ». Le fonctionnement :

• La validation est faite côté serveur : le couple référence de commande + email doit correspondre exactement à une commande existante (comparaison insensible à la casse sur l’email).
• En cas de non-correspondance, le message d’erreur est volontairement générique — protection anti-énumération, aucune information sur les références existantes n’est révélée.
• Une fois validé, le visiteur accède au flux de retour standard pour cette commande uniquement (session PrestaShop scoped).
• Le PDF d’étiquette reste accessible depuis le lien reçu par email sans login, protégé par un token aléatoire de 64 caractères unique au retour.
• Un bandeau « Use a different order » permet de réinitialiser la session invité et de basculer sur une autre commande.

Le PDF d’étiquette et le code QR

Chaque retour génère un PDF contenant : l’adresse de retour, le numéro de retour, la liste des produits et quantités, les instructions, et un code QR unique incluant un token de vérification cryptographique. Le client l’imprime et le colle sur son colis.

Adresses de retour multiples

Configurez plusieurs adresses dans l’onglet Adresses (entrepôt principal, site de traitement des gros volumes, adresse UE vs hors UE…). Chaque retour est associé à une adresse qui apparaît sur son étiquette.

Validation par scan QR à réception

Quand le colis arrive, votre opérateur scanne le QR avec un téléphone ou une douchette USB. Le scan ouvre la page de validation sécurisée — une session admin PrestaShop active est requise ; sans session, la page redirige vers le login back-office. L’opérateur voit alors le détail complet du retour, contrôle l’état physique des produits, et clique Valider ou Refuser.

La validation déclenche en cascade : passage de la commande dans l’état configuré (remboursement partiel ou complet), génération du bon d’achat ou remboursement, email de mise à jour au client, et dispatch du hook actionOrderSlipAdd pour les intégrations tierces.

Retour manuel admin (v1.6+)

Le SAV peut créer un retour pour n’importe quelle commande, indépendamment du délai de retour configuré et du statut de la commande — conçu pour les gestes commerciaux, les retours négociés au téléphone et les régularisations rétroactives.

1. Cliquez « Create manual return » dans le header de la liste des retours en back-office.
2. Étape 1 — saisissez la référence ou l’ID de la commande (une commande de 2022, annulée ou en brouillon est acceptée).
3. Étape 2 — cochez les produits à retourner, leurs quantités, leur raison, le type de compensation (bon d’achat ou avoir), et ajustez si besoin le montant remboursé par ligne.
4. Validez : le retour est traité immédiatement — bon d’achat ou avoir généré sur le champ, stock réintégré, état de commande mis à jour, hook Fastmag dispatché.

Une case « Notifier le client » (décochée par défaut) envoie l’email de confirmation standard si vous le souhaitez. Une note admin libre peut être attachée au retour.

Le montant remboursé personnalisable (v1.7+)

Chaque ligne du retour manuel a un champ « Refund amount » éditable. La valeur par défaut (prix unitaire × quantité) est recalculée automatiquement quand la quantité change, jusqu’à saisie manuelle — la valeur saisie est alors respectée telle quelle. Le ratio proportionnel des remises de la commande, appliqué aux retours client classiques, est désactivé pour les retours manuels : le montant saisi est exactement le montant remboursé. Utile pour un remboursement partiel (produit endommagé remboursé à 50 %), un geste commercial ou une régularisation. L’avoir généré conserve la ventilation HT/TTC proportionnelle au taux de TVA de la ligne d’origine.

Bon d’achat ou remboursement

Selon votre configuration, la validation d’un retour produit soit un bon d’achat (règle de panier PrestaShop native, utilisable sur une prochaine commande), soit un remboursement à traiter sur le moyen de paiement d’origine. Les deux états de commande dédiés (partiel / complet) permettent de distinguer les cas dans vos exports et rapports comptables.

Dashboard Analytics

Le menu Analytics retours expose 13 axes d’analyse, tous filtrables par période et par boutique :

• KPI globaux — volume de retours, taux de retour, valeur retournée, répartition bon d’achat / remboursement.
• Par catégorie de raison et par raison — identifiez les causes dominantes.
• Par pays — repérez les anomalies géographiques (transporteur défaillant sur une zone).
• Top produits retournés — les références à examiner (guide de tailles, qualité fournisseur).
• Croisements raison × pays et raison × produit — le niveau de détail pour agir.
• Tendances mensuelle (12 mois) et journalière — saisonnalité et pics.
• Temps moyen de traitement — la performance de votre SAV.
• Répartition par jour de semaine et top clients retourneurs — détection des abus.

Le bouton Export CSV télécharge l’ensemble des retours de la période filtrée (n° retour, commande, client, produits, raison, statut, dates, montant) pour analyse externe ou import BI.

Intégration Fastmag et ERP

À chaque retour validé, le module dispatche le hook PrestaShop actionOrderSlipAdd avec la commande, la liste des produits et les quantités. Tout module écoutant ce hook (module Fastmag DataFirefly, connecteurs ERP, Systempay…) reçoit la notification en temps réel. Les retours manuels admin dispatchent le même hook.

Le bouton « Re-sync past returns to Fastmag » (barre d’outils de la liste des retours) re-déclenche le hook sur tous les retours passés — indispensable après l’installation d’un connecteur ERP postérieure à ce module, ou après un incident de synchronisation.

Emails transactionnels

Trois emails automatiques, fournis en 6 langues (FR, EN, ES, IT, PT, DE) : confirmation de demande au client (avec PDF joint), notification à l’admin, mise à jour de statut au client (validation / refus / remboursement). Sur les retours manuels admin, l’email client est optionnel (case décochée par défaut). Personnalisez les templates dans modules/dfproductreturn/mails/<langue>/ ou via le système de traduction email natif de PrestaShop.

Multi-boutique

Toutes les tables portent un id_shop : chaque boutique a ses raisons, ses adresses de retour et ses analytics propres. Le sélecteur multi-boutique du back-office filtre naturellement la liste des retours et le dashboard.

Dépannage

Le bouton « Demander un retour » n’apparaît pas

Vérifiez trois points : la commande est dans un statut éligible (configuration), le délai de retour n’est pas dépassé, et le module est actif sur la boutique concernée (contexte multi-boutique). Rappel : pour un retour hors délai, utilisez le retour manuel admin.

Le formulaire invité rejette une commande valide

L’email saisi doit être exactement celui de la commande (la casse est ignorée, mais pas les fautes de frappe). Vérifiez la référence de commande — c’est la référence alphanumérique (ex. XKBKNABJK), pas l’ID numérique.

Le scan QR affiche « Access denied »

C’est le comportement attendu sans session admin : l’opérateur doit être connecté au back-office PrestaShop sur le même navigateur. Connectez-vous puis re-scannez.

La traduction ChatGPT échoue

Vérifiez la clé API dans la configuration, le crédit disponible sur votre compte OpenAI, et que votre serveur autorise les connexions sortantes vers api.openai.com (port 443).

Fastmag ne reçoit pas les retours

Vérifiez que le module Fastmag est installé et accroché au hook actionOrderSlipAdd, puis utilisez « Re-sync past returns to Fastmag » pour rattraper l’historique.