selling.php utilise la table TMP_ARTICLE_SEARCH (mise Ă jour par le CRON)
detail-article.php lit directement ARTICLE_EXISTER_CONDITIONNEMENT (données en temps réel)
Si le CRON n'a pas tourné correctement ou si les données ont changé depuis, il y a des incohérences.
Ces articles apparaissent comme indisponibles (0€ ou pas de conditionnement) sur selling.php mais ont des conditionnements disponibles dans la base.
Nombre d'articles concernés : 0
Ces articles ont un prix sur selling.php mais aucun conditionnement avec BE_AEC_DISPO=1 dans la base.
Nombre d'articles concernés : 0
| Statistique | Valeur |
|---|---|
| Total d'articles actifs | |
| Articles disponibles sur listing (TMP_ARTICLE_SEARCH) | |
| Articles disponibles sur détail (ARTICLE_EXISTER_CONDITIONNEMENT) | |
| Incohérences détectées | 0 |
Si le CRON n'a pas tourné depuis plusieurs jours, TMP_ARTICLE_SEARCH contient des données obsolètes.
Le CRON utilisait DELETE + INSERT au lieu de INSERT ... ON DUPLICATE KEY UPDATE, ce qui pouvait causer des pertes de données.
Le CRON incluait les tarifs à 0€ dans le calcul du prix minimum, affichant 0€ au lieu du vrai prix.
Si des conditionnements ont été ajoutés/modifiés manuellement sans relancer le CRON.
Relancer le CRON manuellement pour reconstruire TMP_ARTICLE_SEARCH avec les données à jour.
Commande : php /home/ubuntu/_CRON/cron_maj_site_xml_abelia_test.php