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