Смысл в том, что если сделать так, как вы хотите. То каждую промо акцию надо применять к каждому продукту. В результате, поиск, фильтрация и просто загрузка страниц будет длиться вечно. Нужно всю логику переделывать, разработчики пока на это не идут
Вам можно сделать скрытую категорию, добавить товары со скидкой на нее как в доп. категорию и добавить соответствующий пункт в меню
Смысл в том, что если сделать так, как вы хотите. То каждую промо акцию надо применять к каждому продукту. В результате, поиск, фильтрация и просто загрузка страниц будет длиться вечно. Нужно всю логику переделывать, разработчики пока на это не идут
Вам можно сделать скрытую категорию, добавить товары со скидкой на нее как в доп. категорию и добавить соответствующий пункт в меню
Тоже подумал про скрытую категорию. Спасибо за пояснение.
Согласен с Vik18. Логика в автоматизации промо-акций есть, особенно когда товаров тысячи. Там и скидка автоматически рассчитывается, и период акции можно задать. Хотелось бы решений от разработчиков ))
Воз и ныне там
Я ставлю товару цену и рекомендованную - скидка 20 процентов. Для незарегистрированных. Гости довольны - 20%!
Я ставлю скидку на каталог/раздел каталога - скидку 5 процентов для группы покупателей. В результате, после авторизации они видят ЦЕНУ ПРОДАЖИ и скидку от нее всего 5 процентов!
В цифрах:
Гости - 80р / рекомендованная 100р = скидка 20 процентов - экономия 20р
Зарегистрированные - 76р / зачеркнутая цена 80р = скидка 5 процентов - экономия 4р
Нам то понятно, но для простого взгляда - гость экономит больше, чем зарегистрированный
Вот это поворот, даже не подозревал о такой засаде. Получается раздел товары со скидкой надо отключать на сайте, он бесполезен. Не ставить же цены руками. Каменный век.
Мало того что с самими промоакциями засада с функционалом, так ещё и это
Ну я так кардинально делать не стал. На сайте акции завожу только для корзины. А скидки у нас все в 1с ставятся, выгружаю из 1с своим скриптом цены и количество, поэтому на этапе выгрузки как хочу могу данные перекрутить и сделать так как мне надо
Просто ребятам надо одним прекрасным днем забить наконец-то на обратную совместимость, и перелопатить не то что код, а логику, которая до сих пор разрасталась навешиванием канделябров с разных сторон на древнюю основу, так что теперь это какой-то китайский квартал, в котором хрен знает куда кривая вывезет )) Тем более что от изменено логики база то не изменится (товары-покупатели-заказы). Только отдельные данные причесать и по новой акции создать
Умения вот на старом сайте, который как раз сейчас хочу сменить в пользу карта, скидки каталога считаются не на лету, а кнопкой пересчитать в админке. Грубо говоря я задаю в промоакциями значение скидок и товары, нажимаю кнопку перечитать цены, пара секунд и каталог пересчитан php скриптом. Все. И никаких тормозов сайта из-за пересчетов цен на лету.
В CS-Cart можно было бы реализовать, чтобы не цены пересчитывались, а пакетно каким-то модулем все товары со скидочными акциями помещались в какую-то скрытую категорию, которую потом выводить как товары со скидками. Динамически “на лету” это делать при каждой загрузке страниц сайта - это действительно через чур, так как надо проанализировать все товары во всех промоакциях и лучше не нужно товар добавлять несколько раз в такую категорию, если какой-то товар есть в нескольких акциях.
Хотя для разных групп покупателей может быть разным набор товаров со скидками. Получается, что нужно делать несколько скрытых категорий для разных групп покупателей. И еще скидка может зависеть от количества баллов пользователя и от других параметров. Слишком много получается вариантов того, что выводить в качестве товаров со скидками тому или иному покупателю.
Возможно ли хотя бы выводить блок с товарами промо-акции? Не список промо-акций, а уже их содержимое. У существующего блока Товары я не вижу такого варианта контента. Тогда на одной странице можно было бы вывести несколько таких блоков.
У товара есть вторая цена, называемая базовая (без всех скидок). Т.е. она остается всегда при товаре, а другая цена - основная (для покупателя) она уже пересчитывется от базовой, исходя из действующих акций каталога. Пересчет идет не на лету в каталоге, а по кнопке php скриптом админки. Дело нескольких секунд даже при большом каталоге. В результате и акции отображены любые и в любом количестве и нагрузки постоянной они не генерируют. Чтобы вернуть или изменить цену для покупателя достаточно изменить или удалить акцию и нажать кнопку пересчитать. Все.
И нужно как минимум предусмотреть опцию у каждой акции - как она влияет на цену. Первый вариант - считается от базовой цены, второй вариан считается от цены в зависимости от заданного порядка (как сейчас реализовано). Итоговая цена выбирается как наименьшая из всех полученных при расчете.
У меня такой задачи не стояло, но реализвать думаю можно если подумать. Например сделать несколько полей и базовой и основной цены и привязать их к определенной группе пользователей в админке. А дальше использовать эту привязку в логику скрипта расчета. Это уже дело программистов как оптимально сделать. Я свой старый сайт сам пилил и исходил только из того что мне надо ,и группы пользователей мне не были нужны для разных цен