Попробуйте версию 4.12.1 до официального выхода


#46

А если у вас еще и мультивитринная установка, то, чтобы удалить заказ нужно, помимо того, что выйти в список заказов, перейти из под конкретной витрины во “все витрины”, иначе никак ))

И еще радует в мултивитринной установке: что бы “войти как пользователь” под конкретной витриной, нужно сначала выйти во “все витрины”, опять найти этого пользователя и только потом уже появляется соответствующая менюшка. Зайти от имени пользователя из под витрины в которой он зарегистрирован - не - это через чур просто для CS-Cart


#47

Ок добавим.
Предвижу что в 4.12 будет баг: “зачем добавили это, я живой заказ по ошибке удалил. Зачем вообще из магазина удалять заказы?”)
Подтверждение “Вы действительно хотите удалить заказ” тоже будет.


#48

Не помню по какой причине нет удаления заказа из под витрины, разберемся.
По пользователю тоже изучу. Постараемся добавить в 4.12


#49

Нет, я вас забаню насовсем, после еще одного сообщения подобного предыдущему. Критику здесь много кто пишет. Но есть полезная критика, есть бесполезная. У вас вторая. На форуме такое не нужно.


#50

Ой, раз вы здесь 4.11.5 функция fn_get_notification_rules может решат и это?


#51

@imac Есть проблемка - при большом количестве товаров в продаже страница админки с товарами прогружается очень долго из-за того что первоначальный запрос обрабатывает все товары в таблице products(а не выбирает первые 20/50/100 и т.п.). Было бы неплохо поправить, а то неприятно когда страница админки грузится по 30-40 секунд. Уменьшить число товаров невозможно, их число будет только расти. Там выходит очень сложный запрос и в отличии от большинства мест, где удалось решить проблемы с большим числом товаров в таблице(MVP, Общие товары продавцов, фактически товаров порядка 25000, ну а т.к. есть вендоры, то в таблице products уже товаров 2,5 миллиона, хотя вендоров еще только 100), тут что-то вообще не понятно как подступиться корректно. Было бы хорошо это в целом поправить - у кого много товаров будет в целом работать, у кого не много - просто быстро и комфортно.

Еще было бы очень хорошо создать сущность - документы оплаты. Чтобы было видно что и на какую сумму оплачено, а что нет. Это бы сделало возможным частичную предоплату контролируемую, реализацию корректную модуля кассовых чеков(сущность частичная предоплата). И, вероятно, удалось бы избежать вот такого Заказ в статусе "Отложен" вместо "Оплачен" Ну и с интеграциями было бы проще - статус всего заказа всё-таки не отражает реального положения дел по оплате и доставке. Статус заказа - одно(может меняться), оплата - другое, доставка - третье. Хорошо бы их разделить. Исходя из состояния доставки, оплаты можно вывести статус заказа. А вот из статуса заказа получать сразу всё пытаться - не очень.


#52

тут вопрос сортировки. Чтобы вывести отсортированный список, надо получить все товары, отсортировать по полю, а затем вычленить кусок нужного размера с требуемым смещением. Если исключить из запроса ORDER BY - тогда да, станет проще. Возможно что было бы хорошо для таких случаев ввести настройку “выводить списки в админке по умолчанию без сортировки”


#53

Особо не поможет, если уберем сортировку, так как группировка все равно останется, а это и есть выборка всех продуктов.
Суть в том что мы проверяем товары по категориям, как минимум.


#54

Касательно быстродействия списка продуктов. Может сделать возможность выбирать сохраненный поиск по умолчанию? Это может быть поиск тех же Recently Updated. Т.е. вы создаете фильтр который находит небольшое количество товаров, делаете его избранным. И при каждом переходе не список товаров отображается он, а не все товаров по умолчанию.

Как считаете, поможет это?


#55

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

image


#56

Я на этот случай если по артикулу - ищу с любой страницы сразу по быстрому поиску, а если какой-то сохраненный поиск - сохраняю ссылку на поиск в быстрое меню - так обходится без предварительной загрузки общего списка


#57

Попробовал, совсем задумалось. Наверное, пытается искать по всем полям.


#58

А вот именно по недавно обновленным - не помогает, я попробовал - тоже долго, нужно что-то другое.


#59

@imac не знаю поднималась ли это тема на форуме, но на дев.демо актуально, клиенты вечно жалуются мне.
Есть товар допустим Шампунь для Рыжих, у него объем 500 и 1000. Они как вариация в одном товаре, по этому название товара Шампунь для Рыжих.
На складе вот сейчас 500, ну нет 1000, но возможно будет. По этому в характеристиках цепляется 500, что в итоге, на сайте нет опознавательных знаков объема, только в характеристиках.
Клиенты идут в вариации, добавляют еще одну вариацию в придуманным объемом, а после удаляют, то есть выполняют ряд лишних движений. Все ради того, чтобы в карточки товара появилась кнопочка с надписью Объем: 500
Логично же если у товара заполнена характеристика вариации внутри товара, она должна отображаться в карточки, разве нет?
Почему создается и удаляется доп вариант, а не оставляется та же 1000, ну просто потому-то зачем забивать базу магазина, может этот товар никогда и не появится.


#60

Я не совсем понял в чем проблема. Возможно вам поможет настройка которая меняет главную вариацию, если у текущей главной количество становится ноль:

Как автоматически менять вариацию по умолчанию при вариациях как один товар
В настройках модуля убедиться что включена галка

Допустим у нас есть шампунь, у которого два варианта объема (500мл и 1000мл) и выглядит это вот так:


Я могу поменять главную характеристику, ту что будет отображаться по умолчанию просто убрав количество у текущей 500мл - например ставлю 0, и не забыть вернуть статус Active для 1000мл. И вот что получится:

Как удалить вариации, без удаления варианта у характеристики
Если же вы хотите поменять количество вариаций в принципе, то это можно сделать тут:


Просто удаляете вариациию 1000мл до тех пор пока она не появится.


#61

в вашем варианте все окей, у клиентов так же, я же привел пример
Шампунь, бывает 1000 и 500, но на складе 500 сейчас есть
Создаем товар ШАМПУНЬ и зайдя в характеристики ставим там 500 мл и сохраняем, получаем вот https://dev.demo.cs-cart.ru/stores/33ceb58bd510d606/electronics/game-consoles/consoles/microsoft/shampun-muzhskoy/

Но у товара нет указание какой объем, цвет или еще, что там может быть в вариации
Они хотят вот так
https://dev.demo.cs-cart.ru/stores/33ceb58bd510d606/electronics/game-consoles/consoles/microsoft/shampun-zhenskiy/
для этого приходиться провернуть манипуляцию практически как у вас на скриншотах, чтобы на выходе осталась лишь главная вариации.

Зачем это нужно, ну как минимум название Шампунь Мужской 500мл не всем нравится и они хотя просто Шампунь Мужской, объем же нужно указать, характеристики не удобно, в описание то же самое, такая вот кнопка подходит идеально для отображения объема или еще каких-то параметров, с таким моментом я столкнулся именно с клиентами в сегменте косметики и парфюмерии.
Что я пытаюсь донести, когда создается товар и у него указывается значение для характеристики которая является Вариации как один товар, было бы хорошо (опциональная настройка модуля), чтобы при сохранении такого товара, автоматом создавалась вариация.

P.s. изменять вариацию по умолчанию, вам нужно это чутка пофиксить там должен быть не только товар в наличии по умолчанию, но и самый дешевый, и после в хук прайса добавить буквально 30 знаков, чтобы на витринах возникла от ХХХХХ рублей. для товаров у которых есть “Вариации как один товар”, такие запросы видел в других темах, если тут нет.


#62

Может быть 50 или 100 новых (последних загруженных в каталог).


#63

По видимому z3r0 имеет ввиду то, что на карточке товара не создается текстовая метка (хотя внешний вид назначен) для характеристики “500мл” у товара “Шампунь”, если он импортирован в единственном числе, но при этом заранее известно, что этот Артикул один из вариаций товара, который на данный момент времени в наличии, а другие поступят позже.

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

Допустим вендор продает футболки от какого-то поставщика, который в свою очередь добывает их у разных производителей и ежедневно сливает в один прайс. К примеру в прайсе 100 товаров и у 90 товаров по 2 вариации, а у 10 их нет. По существу у этих 10 товаров тоже могли бы быть вариации, но на момент генерации прайса их не было в наличии, по этому в файл попало только то, что было по факту. Файл импортируется, и соответственно 10 товаров создаются как один главный товар без намека на вариации. Далее происходит следующее. На другой день свежий файл и снова импорт, но теперь в файле появились недостающие вариации этих самых десяти футболок, которые также создаются как отдельный товар. Таким образом мы получаем 10+10 товаров несоединенных в вариации. Они перемешались с другими товарами, по этому предстоит их отыскать и каждый вариант сложить в вариацию. Однако, кроме этих 10-ти описанных выше футболок в новом прайсе появились новые товары среди которых часть с вариациями. а другая без. И так каждый день по кругу.

Пример со ста футболками – цветочки, а если товаров сотни и из разных категорий, а если таких вендоров с такими прайсами десятки. Одним словом – мама не горюй. :rofl: Мне кажется товары без вариации так же как и вариативные должны иметь текстовые метки, если оные назначены соответствующей характеристике. Хотя бы опционально, может быть кому-то не нужно, а другому без этого каторга.


#64

Да этот сценарий более понятный. В том что описывал z3r0 на мой взгляд логичнее создавать обычную опцию. Я разберусь почему мы так сделали.


#65

Если в 1С УТ включен учёт в разрезе характеристик, то они задаются у каждого Вида Номенклатуры (например, Футболки или Верхняя одежда). Или не задаются, но тогда зачем включать.

Есть список возможных для этого Вида Номенклатуры характеристик. Он общий для товаров этого ВН или общий с другими ВН. Например, список характеристик Размер = 104, 110, 116, 122 может быть у всех футболок или у всех футболок, джемперов и рубашек вместе, как настроить.

Но если характеристика настроена у Вида номенклатуры, то теперь все входящие в неё товары - с характеристиками, пусть и в наличии есть только единственный размер. Такие товары нельзя приходовать без характеристики, проводить операции с ними.

К тому же при обмене через CommerceML в файле offers0_1.xml явно указывается тег <ХарактеристикаТовара>. Если он есть, то характеристика должна безусловно создаваться у товара в ЦС-Карте.