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

" Дизайн: Макеты: Для главной страницы, а также страниц товара и категории добавлена возможность перемещать блоки на витрине." а что это?

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

Тоже хотелось бы подробнее про этот пункт, ну и другие тоже

Подробнее...
  1. При выборе Страна переходит фокус в поле Штат.
  2. При выборе Штата переходит фокус в поле Город.
  3. При выборе города по Enter не происходит Place order.
  4. Выбрать штат и перейти на выбор города можно, нажав Enter.
  5. Работает стандартное поведение открытия выпадающего списка select у Штата нажатием кнопки [↑] или [↓], если поле находится в фокусе.
  6. Если вдруг не будет поля Штата, то при выборе Страны будет фокус на поле Город.
  7. При автодополнении города сделал активным первый пункт. Теперь при автодополнении города и нажатии Enter не происходит Place order.
  8. Сделал заметнее активный пункт в автодополнении.
  9. Починил выбор города из шапки на странице оформления заказа (нужно включить отображение шапки).
  10. Если autocomplete поле пустое, то при нажатии Enter возвращается предыдущее значение.
  11. Если autocomplete поле не изменялось, то ничего не происходит (кроме потери фокуса поля). Действительно только для случая, когда страна не менялась.
  12. Если города нет в autocomplete списке и список закрыт, то происходит обновление города “как есть”.
  13. Если autocomplete поле пустое, но при этом возможно автодополнение, то при нажатии Enter появляется список городов.
6 лайков

Перейти на витрину → Войти как администратор → В “Нижней панели” выбрать режим Редактировать структуру. На Главной, Странице товара и Категории можно будет перемещать блоки, как на странице Оформления заказа.

4 лайка

[*] Фильтры: Теперь на витрине удобнее выбрать сразу несколько критериев фильтрации товаров.
Оооо… Ура! Ура!

[!] Товары: Характеристики: Если при переименовании варианта характеристики его новое имя совпадало с одним из существующих, то все данные варианта удалялись. Исправлено.
ничего себе! 2 года назад про этот баг писал)

[*] Товары: В боковую панель поиска был добавлена возможность найти категорию или вводом её названия, или через дерево категорий.
Спасибо! Надеюсь это вернули исчезнувшую кнопочку.

Прям таки порадовали…

1 лайк

@ab.developer.inj, спасибо за обратную связь. Исправим оба замечания перед финальным релизом (заодно внесём изменения, которые появятся в 4.12.1 между бетой и релизом).

@albinoz, @fevzi, @redrikshukhart, к сожалению, чейнжлог не подходит для того, чтобы детально описать всё. Поэтому там мы пишем кратко, а к релизу готовим новость с самыми важными изменениями и их снимками. Одна новость выходит на 8-10 страниц Google-документа, а всего новостей 4 (для русского и международного CS-Cart и Multi-Vendor). Опубликуем их к выходу финальной версии 4.12.1.

@bobrovantig

Речь про Импорт файлов к товару в рамках улучшенного импорта. Вроде у вас в магазине он есть благодаря модулю от eComLabs.

Ну и мы учли момент, который вы указали в комментарии.

2 лайка

Спасибо, приятно слышать. Да, в поиск на списке товаров вернулась возможность выбрать категорию из дерева. Но и возможность найти категорию вводом не пропала.

А фильтры ещё и быстрее должны стать, когда в категории много товаров и вариантов характеристик. Подробности тоже в новости будут.

2 лайка

[*] Статусы заказа: В статусы заказа добавлен новый параметр «Считать заказ оплаченным». Только заказ с этим параметром будет рассматриваться в статистике как оплаченный заказ.

Этот параметр ставится глобально к статусу, или локально привязывается к заказу (один статус у разных заказов может иметь различное значение этого параметра)? Если глобально - то не имеет смысла, так как придется иметь всех статусов по два, на варианты с предоплатой и с постоплатой. Если значение привязывается к заказу - то круто. Правда тогда значение должно наследоваться в рамках заказа при смене статуса… Что снова приводит нас к мысли, что второй статус был бы наверное все же проще.
Хотя я понимаю, что определяющее в этом пункте - слово “статистика” (наверное не ошибусь, если скажу, что пользуются ей единицы?), а не “работа с заказами”

Я бы завел новую сущность - документы оплаты. Чтобы статусы были статусами, при этом была возможность посмотреть сколько денег упало по заказу, сколько осталось, создалась возможность брать частичные предоплаты и интегрировать с учетными системами. А то статус - ерунда. После оплаты ведь заказ легко может статусы менять еще долго, причем на совершенно идентичные, как предоплаченные, так и не оплаченные. Например, после оформления заказа он может быть в статусе Производство, Комплектация, Доставляется независимо от того, оплачен заказ уже, или будет оплачен по факту доставки. А сейчас выходит что оплаченный заказ и трогать то нельзя чтобы не утратить информацию об оплате, хотя это не логично.

4 лайка

вот я и хочу понять, что в итоге изменилось в ядре, может я и зря доработки какие-то заказывал не дождавшись

Это поправили? При обновлении товара добавляется только одно значение характеристики

@ikoshkin а это проверяли 4.11.5 функция fn_get_notification_rules

тут видимо нужно реализовывать как вариант у способа оплаты, ставить чекбоке считать оплаченный, а у статуса радиогруппа.
Оплата: Оплачен, Учитывать способ оплаты, Не оплачен

Как результат Выполнен - оплачен, Доставляется, если способ оплаты предоплата, будет оплачен, если оплата при получение будет не оплачен.

Если пойти дальше, то хорошо бы еще и зависимости можно было прописать, например:
Разделить статусы на группы: Магазин, Доставка, Покупатель
Предоплата:
пока не оплачен - можно менять статусы в пределах группы Магазин, но смена статуса на любой из двух других групп невозможен, пока не будет проставлен статус оплаты.
Оплата при получении:
Возможно любое изменение статусов. Здесь очень приятный бонус пометки оплаты. Сейчас мы используем два статуса: Вручен покупателю и Выполнен - например сейчас мы Выполнен ставим, когда получим деньги за заказ, а это может случиться и не очень скоро.
Еще есть и вариант возврата, который тоже надо учитывать, когда оплату надо возвращать (Оплата возвращена) и использовать статусы Возвращается и Вернулся.

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

2 лайка

Типов оплаты только в чеке может быть несколько: аванс (неизвестен заранее состав заказа), предоплата, предоплата 100%, кредит, полный расчёт…

Связать можно, но как раз наоборот, для каждого СПОСОБА оплаты, назначить доступные СТАТУСЫ оплаты, и СХЕМУ возможного изменения статусов ДОСТАВКИ в зависимости от назначенного статуса ОПЛАТЫ (у которых тоже есть своя схема последовательного изменения)

2 лайка

Ну да, это было бы как раз правильно.

А если способ оплаты На расчётный счёт, отгружать заказ можно с оплатой типа Аванс и Предоплата и Кредит, то будет 3 разных статуса Отгружено Полный расчёт, Отгружено Предоплата и Отгружено В кредит? И так для каждого способа оплаты

Как не работала синхронизация с 1С УТ 10.3 так и не работает(нет подключения к серверу)