Comparer un montant et un moment précis
Une promotion devait commencer aujourd’hui, mais la fiche affiche encore le tarif normal, ou le prix change à une autre heure que prévu. Commencez par relever le produit, la variation éventuelle, le montant attendu et la période décidée. Un prix de parent variable, un prix de variation et un total de panier ne représentent pas forcément la même donnée.
Notez l’heure d’observation et le contexte : visiteur connecté ou non, devise, quantité et éventuelle localisation utilisée pour les taxes. Comparez le même cas avant de conclure que la programmation est en panne. Un changement de taxe affichée ou une règle de rôle peut expliquer un écart de montant sans déplacer les dates.
Ouvrez la fiche d’édition et relevez les valeurs actuellement enregistrées. Une promotion saisie mais non sauvegardée n’est pas une action planifiée en retard. Une date passée ou une remise non valide demande aussi une correction de données avant toute recherche dans les tâches de fond.
Le présent guide vise une promotion native par produit ou variation. Un code promotionnel, une règle de tarification dynamique ou une campagne fournie par une extension suit un autre mécanisme. Identifiez l’outil qui possède réellement le prix avant de modifier le tarif normal.
- Prix ou dates incorrects dans la fiche : corrigez la donnée native.
- Variation seule concernée : examinez son propre calendrier.
- Données justes, changement attendu non appliqué : consultez l’action liée au produit.
- Données et action cohérentes, affichage ancien : comparez cache et contexte de prix.
Préparer un retour ciblé sans toucher aux commandes
Ces parcours supposent WooCommerce installé et un compte autorisé à modifier les produits, sur un site auto-hébergé ou une boutique WordPress.com qui utilise WooCommerce. L’administration des actions peut demander des droits supplémentaires. En multisite, vérifiez la boutique ouverte avant de relever son fuseau et ses prix ; les sous-sites ne partagent pas nécessairement ces réglages.
Conservez l’ID du produit, les tarifs normal et promotionnel, les dates, le type et les valeurs des variations concernées. Un export ciblé et des captures des champs complètent le relevé. Notez aussi les synchronisations qui peuvent remettre les prix ou dates depuis une source externe.
Pour les essais, utilisez une copie isolée et un produit de démonstration. Faites neutraliser les courriels sortants, webhooks, paiements réels et synchronisations de stock ou de catalogue vers la production. Vérifiez ce point avec la personne qui prépare la copie. Aucun encaissement ni commande réelle n’est nécessaire : la fiche et une ligne de panier de test permettent de comparer les montants.
Définissez le retour arrière avant la correction : rétablir les champs de cette fiche et les seuls réglages comparés. Une restauration complète de boutique pourrait supprimer des commandes ou contenus plus récents. Elle ne constitue pas le premier choix pour un tarif mal programmé sur un seul produit.
Le résultat attendu est un état initial lisible et un cas de vérification limité. Ne modifiez pas les commandes déjà enregistrées pour les aligner automatiquement sur le nouveau prix du catalogue. Leur traitement commercial et leur historique sont distincts de la programmation des prochaines ventes.
Parcours 1 : vérifier les tarifs sur le bon objet
Une promotion native demande un tarif promotionnel renseigné et inférieur au tarif régulier. Un champ vide ou une valeur égale ou supérieure ne définit pas la réduction attendue. Pour un produit variable, chaque combinaison possède ses prix et ses dates : la fourchette du parent ne démontre pas que toutes les variations sont en promotion.
Ne changez pas la devise ni les taxes globales pour compenser une valeur incorrecte dans cette fiche. Lorsqu’une conversion ou un tarif par rôle intervient, relevez d’abord la donnée native avant de chercher la règle qui la transforme.
Le résultat attendu est une paire de tarifs conservée sur le bon objet après rechargement. Le retour arrière rétablit les champs relevés, en préservant les autres changements légitimes. Ne remplacez pas toutes les variations par un montant unique pour corriger une seule combinaison.
- Dans Produits, Tous les produits, modifiez la fiche identifiée par son ID ou son SKU. Ouvrez Données produit et vérifiez son type.
- Pour un produit simple, ouvrez Général et relevez Tarif régulier et Tarif promotionnel. Pour un produit variable, ouvrez Variations, dépliez la combinaison visée et relevez ses propres champs, pas ceux d’un autre produit au nom identique.
- Corrigez seulement les valeurs approuvées pour ce produit ou cette variation. Ouvrez Planifier pour relire les dates associées avant de sauvegarder : un tarif correct peut encore appartenir à une période passée.
- Enregistrez les modifications des variations si nécessaire, puis mettez le produit à jour. Rechargez l’administration et vérifiez prix et dates sur la même combinaison.
- Comparez la fiche de test avec tous les attributs sélectionnés. Si les champs ont changé de nouveau après l’enregistrement, recherchez l’import ou la synchronisation qui possède ces données avant de recommencer.
Lire les dates comme un calendrier de vente
À côté du tarif promotionnel, ouvrez Planifier. Dans l’éditeur natif classique vérifié avec WooCommerce 11.2.1, le début est enregistré à 00:00:00 et la fin à 23:59:59, dans le fuseau du site. Les champs représentent des journées, pas un sélecteur d’heure libre. Une intégration externe qui fournit des horodatages doit être examinée séparément.
Par exemple, une période du 10 au 12 novembre inclut la journée du 12 : elle ne finit pas dès son commencement. Relevez les deux dates et vérifiez qu’elles ne sont ni inversées ni déjà dépassées. Définissez ce que l’équipe attend au début et à la fin avant de corriger le calendrier.
Dans Réglages, Général de WordPress, relevez le fuseau du site et l’heure locale affichée. Ne comparez pas seulement l’horloge de votre ordinateur ou un journal en UTC. Pour un site utilisant les changements d’heure saisonniers, un fuseau de ville correspondant à son fonctionnement peut être plus approprié qu’un décalage fixe.
Ne changez pas le fuseau global pour corriger une seule promotion sans examiner les autres programmations du site. Si le réglage était erroné, préparez sa correction avec le responsable, relevez les campagnes et publications concernées puis vérifiez leurs échéances après modification.
Le résultat attendu est une période comprise dans le bon référentiel horaire. Le retour arrière rétablit les dates ou le fuseau sauvegardés, mais doit tenir compte des événements déjà exécutés pendant l’essai. Remettre une ancienne heure ne retire pas automatiquement les prix qui ont déjà été appliqués.
Préserver les dates pendant les imports et éditions groupées
Si la promotion a disparu après une mise à jour du catalogue, retrouvez l’action qui a modifié les prix. Dans Produits, Tous les produits, l’édition groupée native des tarifs concerne les produits simples et externes ; elle ne règle pas individuellement les prix des variations. Elle peut effacer les dates promotionnelles existantes lors d’un changement de tarif. Les commandes groupées de la zone Variations constituent un autre parcours : ne transposez pas automatiquement le même diagnostic.
Pour un import CSV, repartez d’un export de la boutique cible et limitez les colonnes au besoin réel. Si vous devez conserver ou modifier les dates, contrôlez leur mapping et leur format dans l’importateur utilisé. Une colonne vide ou une source de fournisseur qui ignore les promotions peut remettre une configuration différente de celle créée manuellement.
Sur une copie, traitez un seul produit puis rechargez ses champs de prix et calendrier. Pour un produit variable, examinez chaque variation touchée ; les valeurs du parent ne permettent pas de conclure que toutes les dates ont été conservées. Gardez l’ID et le rapport de cette opération.
Si une synchronisation réécrit les données, corrigez sa source ou sa règle de priorité. Réappliquer la promotion à la main après chaque passage ne constitue pas une solution durable. Définissez quel système possède le tarif régulier, le tarif promotionnel et les dates.
Le résultat attendu est une configuration qui reste stable après le prochain traitement prévu. Le retour arrière utilise les anciennes valeurs des seules fiches touchées et le fichier source conservé. Ne rejouez pas tout l’ancien catalogue pour remettre quelques dates, au risque de réappliquer aussi des stocks ou descriptions devenus obsolètes.
Parcours 2 : examiner l’action de début ou de fin du produit
Le calendrier par produit est vérifié ici dans le code officiel de WooCommerce 11.2.1. Celui-ci utilise les actions wc_product_start_scheduled_sale et wc_product_end_scheduled_sale, dans le groupe woocommerce-sales. Le mécanisme existe depuis 10.5 ; sur une version plus ancienne ou une campagne tierce, identifiez d’abord le système réellement utilisé.
Une échéance déjà passée au moment de l’enregistrement ne crée pas une nouvelle action future pour cette date. L’absence de ligne en attente ne suffit donc pas à diagnostiquer une panne. Inversement, une action en attente dont l’heure est encore à venir est normale. Aucun calendrier ne garantit une exécution à la seconde si les tâches de fond sont retardées.
Si une ligne a échoué, relevez son erreur et son heure. Le responsable technique peut rapprocher ces indices des journaux dans WooCommerce, État, Journaux, puis corriger la cause sur la copie. Ne publiez pas un journal complet. Une reprise ne se décide qu’après vérification du bon produit et de l’effet commercial attendu.
Le contrôle suivant reste en lecture seule. Ne cliquez pas sur Exécuter pour avancer artificiellement une échéance et ne lancez pas toute la file. Une correction de dates peut remplacer sa planification : vérifiez alors les nouvelles lignes. Le retour arrière restaure les données voulues, sans effacer l’historique ni supposer qu’une action terminée puisse être annulée.
- Ouvrez WooCommerce, État, Actions planifiées. Affichez d’abord toutes les situations pour ne pas masquer une action terminée ou échouée.
- Recherchez wc_product_start_scheduled_sale. Dans les résultats, comparez le groupe, les arguments et la valeur product_id avec l’identifiant relevé ; pour une combinaison, il s’agit de l’ID de la variation, pas du parent.
- Relevez la date, l’état et le journal de la ligne correspondante. Lisez le fuseau indiqué dans l’interface avant de comparer cette date au calendrier du produit.
- Répétez avec wc_product_end_scheduled_sale pour examiner la fin. Si aucun résultat ne correspond, recherchez aussi l’identifiant dans les arguments et vérifiez la version, les dates enregistrées et leur position dans le passé ou le futur.
Parcours 3 : comparer le prix enregistré et le prix affiché
Si les champs et l’événement sont cohérents, comparez la fiche directe, la carte du catalogue et une ligne de panier de test sur l’environnement autorisé. Gardez la même variation, la même quantité et le même contexte utilisateur. Une fourchette du parent peut rester différente du prix de la combinaison choisie sans être erronée.
Vérifiez les réglages de taxes affichées et la devise de la session. Le tarif saisi dans le produit et le montant présenté au visiteur peuvent suivre des conventions différentes. Relevez ces conditions avant d’interpréter un écart comme une promotion absente. Ne modifiez pas les taux pour faire correspondre artificiellement un exemple.
Si une extension applique un tarif de rôle, de quantité, de lot ou de devise, comparez ses règles sur la copie. Désactivez ou neutralisez uniquement la règle suspecte pour ce cas, puis remettez-la pour confirmer son effet. Le prix natif peut être correct et ensuite remplacé par une autre logique commerciale.
Retirez ensuite le cache de la fiche ou de la collection concernée avec l’outil déjà utilisé. Vérifiez une session propre et la session habituelle. Une carte ancienne et un panier actualisé indiquent un problème de présentation ou de cache différent d’un tarif réellement resté au prix normal.
Le résultat attendu est un montant expliqué dans chaque surface. Le retour arrière rétablit les règles et préférences comparées ; il ne change pas les commandes historiques. Gardez la distinction entre prix natif, transformation commerciale et réponse visuelle pour préparer la correction dans la bonne source.
Vérifier les limites de la période sur une copie
Préparez sur la copie un produit de démonstration et une période adaptée au contrôle. Notez les montants et les moments attendus avant de modifier les champs. Les essais de début et de fin doivent rester isolés des vrais clients et des services externes ; aucun paiement n’est nécessaire pour observer le catalogue et un panier de test.
Un contrôle complet observe l’état avant la période, pendant sa validité puis après sa fin, avec le prix public et les actions concernées. Avec des dates à la journée, prévoyez les observations autour des échéances locales. Ne changez pas l’horloge du serveur et n’exécutez pas une action future pour accélérer l’essai. Enregistrer une période déjà passée permet de contrôler un état, mais ne prouve pas que la transition automatique fonctionne.
Pour les produits variables, vérifiez une variation en promotion et une variation qui ne l’est pas. Contrôlez aussi la fourchette du parent et le badge promotionnel. Une campagne limitée à une combinaison ne doit pas appliquer silencieusement la même réduction aux autres.
Vérifiez l’enregistrement après un passage d’import ou de synchronisation si ce flux intervient normalement. Le calendrier doit rester celui décidé. Comparez également les caches des surfaces utilisées, afin que la fin de promotion ne laisse pas une carte annoncer un ancien prix.
Le résultat attendu est une chronologie vérifiée sur l’environnement de test, avec des observations explicites. Si vous n’avez pas réalisé cette séquence, notez-la comme vérification restante. Une lecture de code ou la présence d’une action future ne permet pas d’affirmer que toute la campagne a été testée.
Terminer avec une correction durable et un retour clair
Consignez l’identifiant du produit ou de la variation, les tarifs, les dates et le fuseau retenus. Ajoutez les actions de début ou de fin examinées et leur résultat observé, sans recopier de données clients inutiles. La cause doit être formulée précisément : donnée incorrecte, calendrier, synchronisation, action en erreur ou affichage ancien.
Conservez les valeurs précédentes et le modèle de correction ciblée jusqu’à la validation de la campagne. Si une modification globale de fuseau ou de tarification a été nécessaire, contrôlez aussi les autres programmations concernées. Le retour arrière doit tenir compte des événements déjà exécutés et des mises à jour légitimes intervenues depuis.
Si la panne touche de nombreuses tâches de fond, poursuivez avec le diagnostic général de WP-Cron et d’Action Scheduler à partir des indices recueillis. Ne transformez pas ce guide de prix en procédure de relance générale sans comprendre les opérations en attente.
La résolution est acquise lorsque le bon objet porte le bon tarif pour la période décidée et que les surfaces publiques reflètent ce résultat dans le contexte prévu. Les commandes passées restent un historique distinct. Gardez une note de la source qui possède ces données pour éviter que le prochain import ne réintroduise le même défaut.
