Vente incitative de règles cibles


9

J'ai un problème étrange avec la vente incitative de la règle Magento Target.

Scénario: Magento EE 1.12. Plus de 30 vues de magasin sur la même instance Magento. 30k + produits. La plupart des produits ont les mêmes paramètres sur toutes les vues de magasin. J'ai créé une règle pour afficher les ventes incitatives comme suit. "Afficher les produits de la même catégorie avec un prix de 100% ou plus que le produit actuel". Paramètres d'affichage des ventes incitatives: «Basé sur les règles uniquement» (le problème se reproduit pour «Basé sur les règles et sélectionné»). J'ai sauvegardé la règle. tout réindexé. Tout semble correct, les ventes incitatives apparaissent (pour les produits que j'ai testés) comme défini par la règle, MAIS… Après un certain temps pour le même produit sur une vue de magasin, les ventes incitatives apparaissent et sur d'autres vues de magasin, elles ne le font pas. Le produit a les mêmes paramètres sur toutes les vues de magasin. (et il devrait avoir les mêmes ventes incitatives.)

Si je modifie quelque chose dans la règle et l'enregistre à nouveau, les ventes incitatives commencent à apparaître sur toutes les vues de magasin, mais après un certain temps, le problème se reproduit.

Après avoir creusé dans le code, j'ai découvert que les ventes incitatives générées par la règle cible sont conservées dans la table enterprise_targetrule_index_upsell pour éviter d'analyser toutes les règles à chaque fois. Voici comment cela fonctionne. (le tableau est tronqué lors de l'enregistrement d'une règle) S'il y a des ventes incitatives de «règle cible» dans le tableau que j'ai mentionné, elles sont récupérées. Si ce n'est pas le cas, les règles sont analysées et le résultat est placé dans la table d'index. Voici quelques enregistrements de ce tableau pour un produit spécifique.

+-----------+----------+-------------------+---------------------------------------------------------------------+---------------------+
| entity_id | store_id | customer_group_id | product_ids                                                         | customer_segment_id |
+-----------+----------+-------------------+---------------------------------------------------------------------+---------------------+
|     17372 |        2 |                 0 | 17373,350,583,487,17664,29737,14719,443,445,29502,17666,17667,17668 |                   0 |
|     17372 |        5 |                 0 | 17373,350,583,487,17664,29737,14719,443,445,29502,17666,17667,17668 |                   0 |
|     17372 |       17 |                 0 | 17373,350,583,487,17664,29737,14719,443,445,29502,17666,17667,17668 |                   0 |
|     17372 |       18 |                 0 | 17373,350,583,487,17664,29737,14719,443,445,29502,17666,17667,17668 |                   0 |
|     17372 |       19 |                 0 | 17373,350,583,487,17664,29737,14719,443,445,29502,17666,17667,17668 |                   0 |
|     17372 |       20 |                 0 |                                                                     |                   0 |
|     17372 |       21 |                 0 | 17373,350,583,487,17664,29737,14719,443,445,29502,17666,17667,17668 |                   0 |
|     17372 |       22 |                 0 | 17373,350,583,487,17664,29737,14719,443,445,29502,17666,17667,17668 |                   0 |
|     17372 |       23 |                 0 | 17373,350,583,487,17664,29737,14719,443,445,29502,17666,17667,17668 |                   0 |

Comme vous pouvez le voir, les ventes incitatives pour le produit avec l'ID 17372 sont toutes les mêmes sur toutes les vues de magasin sauf store_id 20 qui est vide. Le magasin 20 n'a rien de spécial. Tous les produits concernés ici sont disponibles dans tous les magasins.

Une idée?

Merci. Marius.


1
Votre est-il croncorrectement configuré? IIRC les règles sont reconstruites tous les soirs et sans un actif cronproduira un comportement étrange
Ben Lessani - Sonassi

Le cron est actif et fonctionne chaque matin sans problème.
Marius

J'ai trouvé une autre chose. Après avoir enregistré la règle, la table 'enterprise_targetrule_product' contient tous les produits mais après un certain temps, ils ont tous disparu sauf un, pas toujours le même. Tant que les identifiants des produits sont dans le tableau ci-dessus, tout fonctionne.
Marius

1
lors de l'enregistrement d'un produit, les règles cibles sont indexées pour ce produit et cela finit par le faire: (Mage_Rule_Model_Resource_Abstract :: bindRuleToEntity ()) $ adapter-> delete ($ this-> getTable ($ entityInfo ['associations_table']), $ adapter -> quoteInto ($ entityInfo ['rule_id_field']. 'IN (?) AND', $ ruleIds). $ adapter-> quoteInto ($ entityInfo ['entity_id_field']. 'NOT IN (?)', $ entityIds); Cela supprime tous les autres produits de la liste des produits concernés. Si je règle le mode de l'index de la règle cible sur "manuel", le problème ne se reproduit pas. Mais cela ne le résout pas. Il le masque simplement.
Marius

Une raison pour laquelle quelqu'un vote contre cela?
FlorinelChis

Réponses:


7

Dans EE 1.13, ce bogue semble être corrigé (mais EE 1.13 a disparu)

Dans Enterprise_TargetRule_Model_Resource_Index::saveProductIndex, la ligne avec le problème a été remplacée par (indice: 4ème paramètre "faux")

$targetRule->bindRuleToEntity($ruleId, $productId, 'product', false);

et, dans Mage_Rule_Model_Resource_Abstract, la fonction a bindRuleToEntityété remplacée par:

public function bindRuleToEntity($ruleIds, $entityIds, $entityType, $deleteOldResults = true)

et la ligne a $adapter->delete(...)été enveloppée dans

if ($deleteOldResults) {
    $adapter->delete($this->getTable($entityInfo['associations_table']),
           $adapter->quoteInto($entityInfo['rule_id_field']   . ' IN (?) AND ', $ruleIds) .
           $adapter->quoteInto($entityInfo['entity_id_field'] . ' NOT IN (?)',  $entityIds)
    );
 }

Un autre bogue, shell / indexer.php --reindex targetrule ne fait rien, donc, vous ne pouvez pas réindexer via cron / console, corrigez en ajoutant Enterprise_TargetRule_Model_Index:

public function reindexAll() {
    return $this->_getResource()->cleanIndex();
}

PLUS TARD: voir ce patch https://github.com/magendooro/targetrulefix


Je suis sur 1.13.1 et j'ai un Integrity constraint violation:for key '5B1C775075460366570ABDA2839BC68A'-> cette clé vient de enterprise_targetrule_index_related... avez-vous une idée si elle est liée aux changements mentionnés?
Fra

1

J'ai décidé d'ajouter ce que j'ai trouvé comme réponse afin que cette question ne soit pas marquée comme sans réponse.

lors de l'enregistrement d'un produit, les règles cibles sont indexées pour ce produit et cela finit par le faire :( Mage_Rule_Model_Resource_Abstract::bindRuleToEntity())

$adapter->delete($this->getTable($entityInfo['associations_table']), $adapter->quoteInto($entityInfo['rule_id_field'] . ' IN (?) AND ', $ruleIds) . $adapter->quoteInto($entityInfo['entity_id_field'] . ' NOT IN (?)', $entityIds); 

Cela supprime tous les autres produits de la liste des produits concernés. Si je règle le mode de l'index targetrule sur «manuel», le problème ne se reproduit pas. Mais cela ne le résout pas. Il le cache simplement.

De mon point de vue, c'est un grave bug Magento EE.


La réponse acceptée a-t-elle résolu votre problème? J'ai le même problème dans EE 1.11.1.0
dchayka

Ça l'a fait pour moi ..
Marius
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.