У меня странная проблема с продвижением правил Magento Target.
Сценарий: Magento EE 1.12. 30+ просмотров магазина на том же экземпляре Magento. 30к + продукты. Большинство продуктов имеют одинаковые настройки для всех видов магазина. Я создал правило для показа upsells следующим образом. «Показать товары из той же категории с ценой 100% или более, чем текущий товар». Настройки для показа upsells: «Только на основе правил» (проблема воспроизводится для «На основе правил и выбранных»). Я сохранил правило. переиндексировал все. Все выглядит хорошо, появляются продажи (для продуктов, которые я тестировал), как определено правилом, НО ... Через некоторое время для одного и того же продукта в одном представлении магазина появляются продажи, а в других - нет. Продукт имеет одинаковые настройки для всех видов магазина. (и он должен иметь такие же upsells.)
Если я изменяю что-то в правиле и сохраняю его снова, продажи начинают появляться во всех представлениях магазина, но через некоторое время проблема воспроизводится.
После анализа кода я обнаружил, что upsells, сгенерированные целевым правилом, хранятся в таблице enterprise_targetrule_index_upsell, чтобы избежать синтаксического анализа всех правил каждый раз. Вот как это работает. (таблица усекается при сохранении правила) Если в таблице, о которой я упомянул, есть какие-либо продажи «целевого правила», то они извлекаются. Если нет, то правила анализируются, и результат помещается в таблицу индексов. Вот некоторые записи из этой таблицы для конкретного продукта.
+-----------+----------+-------------------+---------------------------------------------------------------------+---------------------+
| 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 |
Как вы можете видеть, продажи товара с идентификатором 17372 одинаковы во всех представлениях магазина, кроме store_id 20, который пуст. В магазине 20 нет ничего особенного. Все продукты, представленные здесь, доступны во всех магазинах.
Есть идеи?
Спасибо. Marius.
cron
настроен правильно. IIRC правила перестраиваются по ночам и без активногоcron
выдают странное поведение