1

Тема: Давно мы не общались у нас на форуме.

Уважаемые пользователи, разработчики!

Давно мы не получали обратную связь!
Расскажите как у вас дела? Как поменялись ваши продажи после COVID?
Что на ваш взгляд в ближайшее время будет наиболее востребовано в online продажах?

Повысить оценку Понизить оценку

2

Re: Давно мы не общались у нас на форуме.

Добрый день.
С продажами нормально.
Весь упор на маркетинг смещается с ростом online-продаж.
А по этой причине формирование скидок и их вариабельность немаловажны.
"Правила для корзины" этого в полной мере не закрывают.
Хотелось бы возможности формирования правил для каталога. С привязками к категориям, брендам, характеристикам.

Повысить оценку Понизить оценку

3

Re: Давно мы не общались у нас на форуме.

Андрей, принял информацию, спасибо!

Повысить оценку Понизить оценку

Re: Давно мы не общались у нас на форуме.

Уже сам хотел тему создавать)
Увеличилось число заявок на разработку новых интернет-магазинов, на создание новых модулей для магазинов на техподдержке.
Многие клиенты с головой ушли в онлайн, так как оффлайн в некоторых местах еще и не открыт.

5

Re: Давно мы не общались у нас на форуме.

Продажи с карантином сначала немного упали,стало существенно больше заказов с онлайна.
Очень не хватает на сайте возможности добавлять акции,к примеру при покупке 3-х шт-4 в подарок.
Так же очень сильно не хватает различных интеграций
В данный момент точно не хватает корректной работы со службами доставки (СДЭК)
выдает ошибку расчета стоимости доставки

4 Ошибка при указании параметров 0 места

Так же лично мне не очень хватает синхронизации с МойСклад-она работает,но хотелось бы полной синхронизации.
К примеру описание товара в МойСклад заливается в RS в Краткое описание
Вес не приходит
А так все ок,ждем развития системы и особенно новых модулей.
Сделайте больше модулей.Думаю если поставить им цену по 500 рублей,с возможностью самостоятельной доработки,я бы брал)

Повысить оценку Понизить оценку

6

Re: Давно мы не общались у нас на форуме.

Daniel пишет:

В данный момент точно не хватает корректной работы со службами доставки (СДЭК)
выдает ошибку расчета стоимости доставки

4 Ошибка при указании параметров 0 места

Интеграция со СДЭК работает отлично, не надо тут smile
Смотрите логи

Re: Давно мы не общались у нас на форуме.

Что то у меня расчет СДЕК  тормозит. Почта быстро считает

8

Re: Давно мы не общались у нас на форуме.

Daniel пишет:

К примеру описание товара в МойСклад заливается в RS в Краткое описание

Это в ближайшем обновлении будет починено добавлением опции в настройках модуля Обмен данными.
Почему-то Мой склад описание передает в реквизите "Полное наименование", что весьма и весьма необычно.

Повысить оценку Понизить оценку

9

Re: Давно мы не общались у нас на форуме.

Хорошо бы выпустить модуль для вывода таблицы размеров одежды. Мне нравится реализация на алиэкспресс.

Повысить оценку Понизить оценку

10

Re: Давно мы не общались у нас на форуме.

Вот я кстати хотел бы немного рассказать о незрелости технологий пока еще для динамического ценообразования.

Когда речь идет о ценах, всегда нужно помнить, что у цен бывает:

1. отображение
2. сортировка по цене по возрастанию (в списках)
3. фильтрация по цене (в списках)

Как вы понимаете сортировка и фильтрация должна оперировать полным набором данных, то есть если мы заходим в категорию, где 5000 товаров, то программа должна посмотреть на все 5000 товаров и выстроить их по возрастанию цены и вернуть в итоге только,например, первые 20 - что соответствует одной странице данных.

На случай, если кто-то из читателей не знает, то пагинация нужна исключительно с технической точки зрения, чтобы не нагружать память backend'а, браузера клиента объемом HTML, сеть гигантским объемом передаваемых данных. Пагинация - это необходимость.

Сейчас п.2, п.3. делает на своей стороне БД, так как RS только оперирует колонками цен. У юзера может быть установлена заранее подготовленная скидочная колонка цен. Это обеспечивает работоспособность всех функций и скорость работы.

Мы считаем, что в любом магазине должно быть ограниченное число колонок цен и оно НЕ должно быть равно числу пользователей. Магазины не понимают, что когда у них станет 2000 или 5000 или 10 000 клиентов вести индивидуальный порядок расчетов - невозможно. Крупные магазины всегда стандартизируют понятия Колонка цен 1 .... Колонка цен 10, вспомните Юлмарт. И все клиенты работают именно по какой-то колонке цен, а не имеют все разные пляшущие цены.

Для более гибкой политики - существует бонусная система и (внимание!) - бонусная система - это то, что в корзине или в карточке товара (как подсказка), а не в списках товаров в категории цены сразу с учетом ваших бонусов. Это очень важно!
Слой расчета бонусных скидок он чисто косметический и выполняется поверх уже отобранных из БД товаров. Соответственно скидки не могут учитываться во время фильтрации и сортировки.

-----------------------------------

Теперь о незрелости технической. К сожалению, реализовать динамическое ценообразование возможно (в наше время), только если вешать обработчики цен на стороне PHP, а соответственно сортировку и фильтрацию нужно будет также обеспечивать силами PHP, ну и самое главное, из БД в этом случае нужно получать не одну страницу товаров, а ПОЛНЫЙ набор данных.

Все это приведет к тому, что сайт будет катастрофически сильно тормозить.

Динамическое ценообразование предполагает, что колонка цен в БД - динамическая и она зависит от текущего юзера, от его прежних заказов, от категории продукции и возможно еще очень много от чего. В итоге нужно дождаться таких технологий, чтобы в БД в качестве колонки можно было объявить целую программу (callback), которая должна выполняться максимально быстро, чтобы не пострадало время выборки.

Пока удобной технологии для этого мы еще не нашли, поэтому мы разделяем понятия:

1. Типы цен - это то, что работает быстро, поддерживает сортировку и фильтрацию.
2. Скидки, бонусные программы - это то, что клиент увидит в корзине. Скидки могут быть сколь угодно сложные.

---------

Решил написать этот пост, так как мы стали получать много заявок, на тему "хотим, чтобы клиенты сразу везде и повсюду видели все цены с учетом своих скидок", но так, к сожалению, пока невозможно с обычным Mysql.

Повысить оценку Понизить оценку

11 Отредактировано Ярослав (13.07.2020 22:41:54)

Re: Давно мы не общались у нас на форуме.

Как раз пришлось реализовывать индивидуальные цены для товаров.
40 колонок цен со скидками  на товары уже существовали на базе стандартного справочника цен (причем есть товары, где скидка не должна превышать определенный процент).
Но захотели создавать цены в разрезе брендов, категорий и отдельных товаров. При этом настройку делают на стороне 1с.
Уговорить  реализовать скидками в корзине не получилось.
В итоге сделал модуль с отдельной таблицей индивидуальных цен (товар-пользователь-цена). При расчете цены товара сначала выборка делается из этой таблицы. В таблицу заливаю данный из csv файла с помощью LOAD INFILE, поэтому проблем с синхронизацией нет. Файл формируется на стороне 1с сразу с рассчитанными ценами для клиента. Попадают только товары, затронутые скидкой. Обычно из около 300-500 для клиента.
Все это касается только отображения цены.

12

Re: Давно мы не общались у нас на форуме.

Ярослав пишет:

Как раз пришлось реализовывать индивидуальные цены для товаров.
40 колонок цен со скидками  на товары уже существовали на базе стандартного справочника цен (причем есть товары, где скидка не должна превышать определенный процент).
Но захотели создавать цены в разрезе брендов, категорий и отдельных товаров. При этом настройку делают на стороне 1с.
Уговорить  реализовать скидками в корзине не получилось.
В итоге сделал модуль с отдельной таблицей индивидуальных цен (товар-пользователь-цена). При расчете цены товара сначала выборка делается из этой таблицы. В таблицу заливаю данный из csv файла с помощью LOAD INFILE, поэтому проблем с синхронизацией нет. Файл формируется на стороне 1с сразу с рассчитанными ценами для клиента. Попадают только товары, затронутые скидкой. Обычно из около 300-500 для клиента.
Все это касается только отображения цены.

Очень здорово, что вы не побоялись ввязаться в эту крайне непростую задачу.
Насколько я понимаю, вы добавляете join вашей таблицы во время выборки товаров, чтобы перекрыть цены из xcost?

Мы детально проектировали вариант с таблицей комплектация товара-пользователь-тип цен-цена-дополнительный уникализатор, но мы сошлись на том, что этот вариант можно реализовать только с очень большими оговорками (грубо говоря только в конкретном случае, игнорируя многие возможные кейсы применения), что нам как разработчикам движка не подходит.

Мы еще думали сделать дополнительный уникализатор, чтобы можно было вообще сделать самые невероятные вещи с помощью сторонних модулей, например, каждый нечетный день для какой-то группы клиентов давать скидки на какие-то группы товаров. В данном случае флаг нечетного дня был бы доп. унификатором.

Одна из проблем - это был объем такой таблицы, если на сайте 10 000 товаров, 1000 пользователей и 2 типа цен, то это уже 20 млн. записей. JOIN такой таблицы даже с индексами будет довольно дорогой по ресурсам. И это я привел очень скромные параметры - 10k товаров и все с одной комплектацией и без доп.унификаторов.

Второй из важнейших проблем такой схемы - обновление данных. Допустим, пользователь перешел какой-то порог и ему вдруг нужно все цены пересчитать (он достиг нового уровня скидок), а если в магазине много товаров - не совсем понятно в какой момент это делать, так как это занимает длительное время? Если в момент наступления события (достижения нового уровня скидок), то клиент может не дождаться, когда у него оформится заказ, например. Если по крону, то какое-то время цены на сайте будут неактуальны.

Вариант как у вас - что источник новых цен - всегда 1С частично снимает эту проблему, но делает цены какое-то время неактуальными на сайте для пользователя, хотя возможно это очень небольшое время.

Повысить оценку Понизить оценку

13

Re: Давно мы не общались у нас на форуме.

Ярослав пишет:

Но захотели создавать цены в разрезе брендов, категорий и отдельных товаров. При этом настройку делают на стороне 1с.
Уговорить  реализовать скидками в корзине не получилось.
В итоге сделал модуль с отдельной таблицей индивидуальных цен (товар-пользователь-цена).

По-хорошему, если есть 1С, то подобные манипуляции целиком выполняются на стороне 1С, а сайт это ведь всего лишь фронтэнд к 1С, он ничего не считает. Получает разные типы цен и выполняет условия отображения конкретной цены.

14

Re: Давно мы не общались у нас на форуме.

Вот только на 1с может себе позволить подвиснуть на пару десятков секунд при пересчете скидки в заказе, а на сайте такое не получится.

Насколько я понимаю, вы добавляете join вашей таблицы во время выборки товаров, чтобы перекрыть цены из xcost?

Да вот нет, к сожалению, более костыльный вариант сделал.
Подробнее про это можете рассказать?

15

Re: Давно мы не общались у нас на форуме.

в Catalog\Controller\Front\ListProducts в методе init есть событие init.api.catalog-front-listproducts

В обработчике у вас есть переменная, ссылающаяся на этот контроллер ListProducts

Вы можете перехватить объект запроса на выборку товаров:

в handlers.inc.php вашего кастомного модуля:

public static function initApiCatalogFrontListProducts($controller) {
    $request = $controller->api->queryObj();
    //Тут можно делать что угодно с запросом, например добавить JOIN и уточнить секцию SELECT
}

Повысить оценку Понизить оценку

16

Re: Давно мы не общались у нас на форуме.

Здравствуйте, Всем.
Из вышенаписанного напрашивается вывод, что скидочных правил для каталога из коробки не видать...?
Как же это побеждено в других системах? Prestashop, Cs-Cart?

Повысить оценку Понизить оценку