Annulation automatique des commandes impayées

Faites passer automatiquement les commandes impayées à l'état Annulé après un délai de grâce configurable, en restituant le stock réservé sans aucune intervention manuelle.

remarque

Disponible depuis la v1.0.3

Vue d'ensemble

Lorsqu'un client passe une commande et choisit un mode de paiement hors ligne — virement bancaire, mandat ou tout autre mode que vous avez configuré — le stock est bloqué mais aucun paiement n'est encore arrivé. Si le client ne paie jamais, ces articles restent indisponibles pour les autres acheteurs et vos niveaux de stock deviennent inexacts.

La fonctionnalité d'annulation automatique résout ce problème en assignant une échéance à chaque commande impayée. Une fois l'échéance dépassée, la tâche cron fait passer le statut de la commande à Annulé, ce qui déclenche le pipeline d'annulation standard de PrestaShop : les quantités en stock sont restituées, l'historique de la commande est mis à jour et le client reçoit l'e-mail de confirmation d'annulation standard de PrestaShop.

Il existe deux méthodes indépendantes pour déclencher une annulation, et elles peuvent coexister :

1. Délai global — un nombre de jours unique qui s'applique à toutes les commandes impayées, quel que soit le mode de paiement. Toute commande dépassant cet âge est annulée automatiquement, indépendamment des messages de rappel que vous avez configurés.
2. Annulation par message — un message de rappel spécifique peut être désigné comme « dernier avertissement ». Lorsque le cron envoie ce message, il annule immédiatement la commande après l'envoi de l'e-mail. Cette approche vous donne un contrôle précis sur le moment exact de l'annulation et vous permet d'envoyer un avertissement final personnalisé au préalable.

Vous pouvez utiliser les deux méthodes simultanément. Si une annulation par message se déclenche avant que le délai global ne soit atteint, la commande est annulée à ce moment-là et le délai global ne s'applique pas.

Configuration

Étape 1 : Activer la fonctionnalité d'annulation globale

1. Allez dans Modules > Gestionnaire de modules, trouvez Order Payment Reminders Pro et cliquez sur Configurer.
2. Cliquez sur l'onglet Paramètres généraux.
3. Réglez Activer l'annulation automatique des commandes sur Oui.
4. Saisissez un nombre dans Annuler la commande après (en jours). Par exemple, entrez 10 pour annuler toute commande impayée datant de plus de 10 jours.
5. Cliquez sur Enregistrer.

Si votre boutique utilise le module Virement bancaire de PrestaShop, la description du champ affiche la valeur recommandée tirée du paramètre Période de réservation de ce module afin que vous puissiez les synchroniser.

Champs de l'onglet Paramètres généraux :

Champ	Valeurs	Défaut	Description
Activer l'annulation automatique des commandes	Oui / Non	Non	Interrupteur principal du système d'annulation automatique. Aucune annulation ne se produit lorsque cette option est désactivée, même si des indicateurs d'annulation par message sont activés.
Annuler la commande après	Nombre (jours)	0	Nombre de jours après la création de la commande avant qu'elle ne soit annulée. Une valeur de 0 désactive le délai global même si la fonctionnalité est activée.

Étape 2 : (Facultatif) Désigner un message de rappel comme déclencheur d'annulation

Si vous souhaitez envoyer un e-mail personnalisé de « dernière chance » au moment de l'annulation, en remplacement du délai global ou en complément :

1. Dans l'onglet Messages de rappel, cliquez sur Modifier pour le message que vous souhaitez utiliser comme dernier avertissement, ou créez un nouveau message avec le planning approprié (par exemple, 9 jours après la création de la commande).
2. Faites défiler jusqu'à la section Options avancées dans le formulaire du message.
3. Réglez Annuler la commande après ce message sur Oui.
4. Enregistrez le message.

Lorsque le cron traite une commande ayant atteint l'heure planifiée de ce message, il envoie l'e-mail puis annule immédiatement la commande. Le compte à rebours du délai global continue de s'exécuter en parallèle — c'est le premier seuil atteint qui s'applique.

Formulaire de message de rappel — Options avancées :

Champ	Valeurs	Défaut	Description
Annuler la commande après ce message	Oui / Non	Non	Lorsque réglé sur Oui, le cron annule la commande immédiatement après l'envoi de ce rappel. Le statut de la commande passe à Annulé et le stock est restitué.

Étape 3 : Vérifier que la tâche cron est active

La logique d'annulation automatique ne s'exécute que lorsque l'endpoint cron est appelé. Si le cron n'est pas configuré, aucune annulation ne se produira, quels que soient vos paramètres.

1. Allez dans l'onglet Configuration du Cron du module.
2. Copiez l'URL cron affichée (elle contient votre token sécurisé).
3. Ajoutez une tâche cron serveur quotidienne qui appelle cette URL, par exemple à minuit.

Consultez le guide de configuration du Cron pour des instructions détaillées.

Étape 4 : Tester avant la mise en production

Avant d'activer l'annulation automatique sur une boutique en production :

1. Allez dans Paramètres généraux et activez le Mode test.
2. Saisissez une adresse e-mail de test.
3. Déclenchez manuellement l'URL cron dans votre navigateur.
4. Le module affiche un résumé de ce qu'il ferait — les commandes qu'il annulerait apparaissent sous la forme « Direct Cancel Order [id] » sans que leur statut ne soit réellement modifié.
5. Une fois satisfait du résultat, désactivez le Mode test.

Fonctionnement

Le délai global

À chaque exécution du cron, le module récupère toutes les commandes impayées pour les modes de paiement pour lesquels vous avez configuré des messages. Pour chaque commande, il calcule le nombre d'heures écoulées depuis sa création.

Si Annuler la commande après est réglé sur une valeur supérieure à 0, le module convertit ce délai en heures (jours × 24). Toute commande plus ancienne que ce seuil est annulée immédiatement — aucun e-mail n'est envoyé au préalable par cette voie, et aucun message de rappel n'a besoin d'exister pour que l'annulation se produise.

Le flux d'annulation :

1. L'objet OrderHistory de PrestaShop fait passer la commande à l'état Annulé.
2. Le pipeline d'annulation standard de PrestaShop s'exécute : il restitue les quantités en stock des produits et, si l'état de la commande est configuré pour envoyer un e-mail, envoie l'e-mail d'annulation PrestaShop par défaut au client.
3. L'entrée dans l'historique de la commande est ajoutée sans employé associé — le module agit automatiquement.
4. Si le pipeline d'annulation de PrestaShop échoue pour une raison quelconque (par exemple, un problème de compatibilité sur certains environnements PS 8), le module bascule vers une mise à jour directe du statut en SQL, de sorte que la commande est tout de même marquée comme annulée même si les e-mails de restitution du stock ne peuvent pas être déclenchés.

Annulation par message

Lorsque le cron traite une commande ayant atteint l'heure planifiée d'un message et que ce message a Annuler la commande après ce message réglé sur Oui :

1. Le module envoie d'abord l'e-mail de rappel au client.
2. Une fois l'e-mail envoyé (ou tenté), il annule la commande en utilisant le même pipeline décrit ci-dessus.

Le client reçoit ainsi un dernier e-mail lui expliquant la situation avant que l'annulation ne prenne effet.

Interaction avec le mode test

Lorsque le Mode test est activé :

• Les commandes qui seraient annulées via le délai global apparaissent sous la forme « Direct Cancel Order [id] (référence) » dans la sortie du cron — elles ne sont pas réellement annulées.
• Les commandes qui seraient annulées via un déclencheur par message apparaissent sous la forme « Cancel Order [id] (référence) » — elles ne sont pas non plus annulées.

Aucune annulation réelle ne se produit en mode test, vous pouvez donc simuler en toute sécurité une exécution complète du cron sur une boutique en production.

Interaction avec l'e-mail récapitulatif admin

Si vous avez activé l'E-mail récapitulatif administrateur dans les Paramètres généraux, le récapitulatif s'exécute au début de chaque exécution du cron, avant tout traitement d'annulation ou de rappel. Il examine la même liste de commandes impayées et signale les commandes qui se trouvent dans la fenêtre d'alerte que vous avez configurée avant l'échéance d'annulation. Vous recevez ainsi un avertissement quotidien vous permettant d'intervenir manuellement si nécessaire.

Par exemple, si votre délai global est de 10 jours et votre alerte récapitulative de 24 heures, vous recevez chaque jour un e-mail listant les commandes impayées depuis 9 jours ou plus — vous laissant une dernière chance de contacter le client avant que le système n'annule automatiquement.

Consultez E-mail récapitulatif administrateur pour les détails de configuration.

Exemples d'utilisation

Exemple : Délai simple de 14 jours

Vous acceptez les paiements par virement bancaire et souhaitez annuler toute commande non payée dans les 14 jours afin de correspondre à la période de réservation de votre banque.

• Réglez Activer l'annulation automatique des commandes sur Oui.
• Réglez Annuler la commande après sur 14.
• Aucune annulation par message n'est nécessaire.

Chaque jour lors de l'exécution du cron, toute commande impayée datant de plus de 14 jours est annulée. Le stock est restitué automatiquement.

Exemple : Rappels progressifs avec un e-mail d'annulation final

Vous souhaitez envoyer trois rappels (jour 3, jour 7, jour 10) puis annuler au jour 10 avec un e-mail final personnalisé.

1. Créez trois messages de rappel : à 72 heures, 168 heures et 240 heures.
2. Sur le message du jour 10 (240 heures), réglez Annuler la commande après ce message sur Oui.
3. Laissez Annuler la commande après à 0 (désactivé), ou définissez une valeur supérieure à 10 comme filet de sécurité.

Lorsque le cron s'exécute au jour 10 pour une commande impayée, il envoie votre e-mail final personnalisé puis annule la commande. Si le cron n'est pas appelé pendant plusieurs jours et que la commande dépasse le jour 10, le délai global agit comme solution de secours.

Exemple : Délais différents selon le mode de paiement

Les commandes par virement bancaire doivent être annulées à 7 jours ; un mode de paiement hors ligne plus lent doit l'être à 14 jours. Comme le délai global est une valeur unique, utilisez l'annulation par message pour y parvenir :

• Créez un message pour le virement bancaire à 168 heures (7 jours) avec Annuler la commande après ce message réglé sur Oui.
• Créez un message pour l'autre mode de paiement à 336 heures (14 jours) avec Annuler la commande après ce message réglé sur Oui.
• Réglez Annuler la commande après sur 0 (désactivé globalement).

Chaque mode de paiement suit ainsi son propre calendrier.

Remarques importantes

• La fonctionnalité d'annulation automatique n'affecte que les commandes toujours impayées. Les commandes ayant été payées — même partiellement — ne sont pas concernées.
• Les commandes déjà à l'état Annulé sont ignorées ; le module vérifie l'état actuel avant d'appliquer une seconde annulation.
• Le module n'envoie pas son propre e-mail d'annulation. C'est l'e-mail d'annulation standard de PrestaShop (configuré dans Commandes > Statuts pour l'état Annulé) que le client reçoit, si cet état est configuré pour en envoyer un.
• Lors de l'utilisation de l'annulation par message sur une boutique multilingue, l'e-mail de rappel est envoyé dans la langue du client avant que l'annulation ne se produise.
• Dans une configuration multi-boutiques, Annuler la commande après (wr_cancel_days) et l'interrupteur d'annulation des commandes (wr_cancel_orders) sont des valeurs globales qui s'appliquent à toutes les boutiques. Les indicateurs d'annulation par message sont stockés par message et peuvent être limités à un module de paiement spécifique.
• La valeur Annuler la commande après est interprétée en jours entiers uniquement. Il n'est pas possible de définir un délai de, par exemple, 7,5 jours.
• Il n'existe pas de mécanisme d'annulation pour une annulation automatique. Si une commande est annulée par erreur, vous devez la restaurer manuellement dans le Back Office.

Résolution des problèmes

Problème	Solution
Les commandes ne sont pas annulées même si le délai est dépassé	Vérifiez que Activer l'annulation automatique des commandes est réglé sur Oui et que Annuler la commande après est supérieur à 0. Confirmez ensuite que la tâche cron s'exécute — ouvrez l'URL cron directement dans un navigateur et vérifiez la sortie pour les messages d'annulation.
Les commandes sont annulées trop tôt	L'âge est calculé à partir de la date de création de la commande, pas à partir du dernier rappel envoyé. Si votre cron s'exécute à des intervalles imprévisibles, une commande créée près de minuit peut sembler plus ancienne que prévu. Vérifiez l'heure de création de la commande dans le Back Office.
Le stock n'est pas restitué après l'annulation	La restitution du stock est gérée par le pipeline d'annulation de PrestaShop, pas par ce module. Vérifiez que l'état de commande Annulé est configuré dans Commandes > Statuts avec les paramètres de restitution du stock activés. Sur certaines anciennes versions de PS, la restitution du stock dépend du fait que la commande ait été validée ou non.
Le client n'a pas reçu d'e-mail d'annulation	Le module n'envoie pas son propre e-mail d'annulation. L'e-mail est envoyé par PrestaShop uniquement si l'état de commande Annulé a l'option Envoyer un e-mail au client activée dans Commandes > Statuts. Vérifiez ce paramètre.
L'annulation par message se déclenche mais la commande n'est pas annulée	Si le mode test est activé, les annulations sont uniquement simulées. Désactivez le mode test et relancez le cron. Si le problème persiste, consultez les journaux PrestaShop dans Paramètres avancés > Journaux pour les entrées WireTransferReminder décrivant un échec d'annulation.
La sortie du cron affiche « Direct Cancel Order » mais rien ne change	C'est la sortie du mode test. Cela signifie que la commande serait annulée mais que le mode test l'en empêche. Désactivez le mode test dans Paramètres généraux.
L'annulation SQL de secours s'est exécutée mais le stock n'a pas été restitué	L'alternative SQL directe met uniquement à jour la ligne de statut de la commande — elle n'exécute pas le pipeline d'annulation complet de PrestaShop. Il s'agit d'un chemin de dernier recours. Pour déclencher une restitution correcte du stock, modifiez manuellement le statut de la commande dans le Back Office, ce qui active le pipeline complet.

Foire aux questions

L'annulation d'une commande via ce module déclenchera-t-elle l'e-mail d'annulation standard de PrestaShop au client ?

Oui, si votre état de commande Annulé est configuré pour envoyer un e-mail dans Commandes > Statuts. Le module utilise le propre pipeline d'historique des commandes de PrestaShop, qui respecte ce paramètre exactement comme le ferait une annulation manuelle.

Puis-je définir des délais d'annulation différents pour différents modes de paiement ?

Le délai global s'applique à tous les modes de paiement à la fois. Pour obtenir des délais par mode de paiement, désactivez le délai global (réglez-le à 0) et utilisez à la place l'option d'annulation par message sur un message lié à ce mode de paiement spécifique, avec le planning correspondant à votre délai.

Que se passe-t-il si le cron ne s'exécute pas pendant plusieurs jours et que de nombreuses commandes dépassent le délai en même temps ?

Toutes les commandes éligibles sont annulées lors de la prochaine exécution du cron. Il n'y a pas de limite de traitement par lot : si 50 commandes ont dépassé le délai, les 50 sont annulées lors de cette unique exécution.

L'annulation automatique fonctionne-t-elle pour les commandes passées avec des modes de paiement autres que le virement bancaire ?

Oui. Depuis la version 1.2.0, le module prend en charge tout mode de paiement hors ligne. Le cron récupère les commandes impayées en fonction des modules de paiement pour lesquels vous avez créé des messages de rappel. Si vous avez configuré un message pour un module de paiement donné, ses commandes sont incluses dans la vérification d'annulation.

Si j'utilise à la fois le délai global et un indicateur d'annulation par message, lequel se déclenche en premier ?

Celui dont le seuil est atteint en premier par la commande. Si le planning par message (par exemple, jour 9) précède le délai global (jour 14), le message est envoyé et la commande est annulée au jour 9. Le délai global ne se déclenche jamais pour cette commande car elle est déjà annulée. Si le planning par message n'est jamais atteint (par exemple, le message a été supprimé), le délai global agit comme filet de sécurité.

Puis-je voir combien de commandes ont été annulées automatiquement dans le tableau de bord ?

Le tableau de bord des statistiques de récupération affiche un compteur « Total annulé » pour les commandes relancées qui ont fini dans l'état Annulé. Cela inclut les commandes annulées automatiquement et celles annulées manuellement, à condition qu'au moins un rappel leur ait été envoyé.

Le mode test protège-t-il mes commandes en production contre une annulation accidentelle ?

Oui. Lorsque le mode test est actif, aucune commande n'est modifiée. La sortie du cron décrit ce qui se passerait — vous pouvez l'examiner en toute sécurité sans affecter aucune commande.

Existe-t-il un moyen d'exclure des commandes spécifiques de l'annulation automatique ?

Pas via l'interface du module. Si vous devez préserver une commande spécifique, traitez-la manuellement (marquez-la comme en attente de paiement ou contactez directement le client), ou désactivez temporairement la fonctionnalité, gérez la commande, puis réactivez-la.

Fonctionnalités associées

• Messages de rappel — créez le déclencheur d'annulation par message et configurez l'e-mail de dernier avertissement.
• Configuration du Cron — la fonctionnalité d'annulation automatique ne s'exécute que lorsque le cron est actif.
• E-mail récapitulatif administrateur — recevez un avertissement quotidien avant le déclenchement des annulations pour pouvoir intervenir manuellement.
• Configuration générale — vue d'ensemble de tous les paramètres généraux, y compris le mode test.