" Дизайн: Макеты: Для главной страницы, а также страниц товара и категории добавлена возможность перемещать блоки на витрине." а что это?
Как-то чрезмерно лаконично описали. Настолько, что вообще не понятно что же сделали. Вы имейте в виду, мы же во время ваших внутренних разговоров и обсуждений вас не слышали, мы не знаем что вы подразумеваете под этими тезисами.
Перейти на витрину → Войти как администратор → В “Нижней панели” выбрать режим Редактировать структуру. На Главной, Странице товара и Категории можно будет перемещать блоки, как на странице Оформления заказа.
[*] Фильтры: Теперь на витрине удобнее выбрать сразу несколько критериев фильтрации товаров.
Оооо… Ура! Ура!
[!] Товары: Характеристики: Если при переименовании варианта характеристики его новое имя совпадало с одним из существующих, то все данные варианта удалялись. Исправлено.
ничего себе! 2 года назад про этот баг писал)
[*] Товары: В боковую панель поиска был добавлена возможность найти категорию или вводом её названия, или через дерево категорий.
Спасибо! Надеюсь это вернули исчезнувшую кнопочку.
@ab.developer.inj, спасибо за обратную связь. Исправим оба замечания перед финальным релизом (заодно внесём изменения, которые появятся в 4.12.1 между бетой и релизом).
@albinoz, @fevzi, @redrikshukhart, к сожалению, чейнжлог не подходит для того, чтобы детально описать всё. Поэтому там мы пишем кратко, а к релизу готовим новость с самыми важными изменениями и их снимками. Одна новость выходит на 8-10 страниц Google-документа, а всего новостей 4 (для русского и международного CS-Cart и Multi-Vendor). Опубликуем их к выходу финальной версии 4.12.1.
Спасибо, приятно слышать. Да, в поиск на списке товаров вернулась возможность выбрать категорию из дерева. Но и возможность найти категорию вводом не пропала.
А фильтры ещё и быстрее должны стать, когда в категории много товаров и вариантов характеристик. Подробности тоже в новости будут.
[*] Статусы заказа: В статусы заказа добавлен новый параметр «Считать заказ оплаченным». Только заказ с этим параметром будет рассматриваться в статистике как оплаченный заказ.
Этот параметр ставится глобально к статусу, или локально привязывается к заказу (один статус у разных заказов может иметь различное значение этого параметра)? Если глобально - то не имеет смысла, так как придется иметь всех статусов по два, на варианты с предоплатой и с постоплатой. Если значение привязывается к заказу - то круто. Правда тогда значение должно наследоваться в рамках заказа при смене статуса… Что снова приводит нас к мысли, что второй статус был бы наверное все же проще.
Хотя я понимаю, что определяющее в этом пункте - слово “статистика” (наверное не ошибусь, если скажу, что пользуются ей единицы?), а не “работа с заказами”
Я бы завел новую сущность - документы оплаты. Чтобы статусы были статусами, при этом была возможность посмотреть сколько денег упало по заказу, сколько осталось, создалась возможность брать частичные предоплаты и интегрировать с учетными системами. А то статус - ерунда. После оплаты ведь заказ легко может статусы менять еще долго, причем на совершенно идентичные, как предоплаченные, так и не оплаченные. Например, после оформления заказа он может быть в статусе Производство, Комплектация, Доставляется независимо от того, оплачен заказ уже, или будет оплачен по факту доставки. А сейчас выходит что оплаченный заказ и трогать то нельзя чтобы не утратить информацию об оплате, хотя это не логично.
тут видимо нужно реализовывать как вариант у способа оплаты, ставить чекбоке считать оплаченный, а у статуса радиогруппа.
Оплата: Оплачен, Учитывать способ оплаты, Не оплачен
Как результат Выполнен - оплачен, Доставляется, если способ оплаты предоплата, будет оплачен, если оплата при получение будет не оплачен.
Если пойти дальше, то хорошо бы еще и зависимости можно было прописать, например:
Разделить статусы на группы: Магазин, Доставка, Покупатель
Предоплата:
пока не оплачен - можно менять статусы в пределах группы Магазин, но смена статуса на любой из двух других групп невозможен, пока не будет проставлен статус оплаты.
Оплата при получении:
Возможно любое изменение статусов. Здесь очень приятный бонус пометки оплаты. Сейчас мы используем два статуса: Вручен покупателю и Выполнен - например сейчас мы Выполнен ставим, когда получим деньги за заказ, а это может случиться и не очень скоро.
Еще есть и вариант возврата, который тоже надо учитывать, когда оплату надо возвращать (Оплата возвращена) и использовать статусы Возвращается и Вернулся.
Связывать статус с оплатой вообще не логично, это ошибочная связь, костыль. Статус к оплате вообще имеет очень опосредованное отношение. Да и оплачен… а сколько оплачено, что оплачено? А если заказ случайно изменили и не заметили? Тут просто неправильная реализация. Да и даже у способов оплаты. Вот на первый взгляд кажется что способы оплаты сохраняют какие-то данные о транзакции. А по факту нет - это просто текстовое поле, разное у разных способов оплаты. И разные модули платежные совсем по-разному сохраняют информацию о платежных реквизитах покупателя, оплате, в произвольном формате, который невозможно использовать. И довольно обидное следствие - невозможность корректно ввести частичную предоплату.
Связать можно, но как раз наоборот, для каждого СПОСОБА оплаты, назначить доступные СТАТУСЫ оплаты, и СХЕМУ возможного изменения статусов ДОСТАВКИ в зависимости от назначенного статуса ОПЛАТЫ (у которых тоже есть своя схема последовательного изменения)
А если способ оплаты На расчётный счёт, отгружать заказ можно с оплатой типа Аванс и Предоплата и Кредит, то будет 3 разных статуса Отгружено Полный расчёт, Отгружено Предоплата и Отгружено В кредит? И так для каждого способа оплаты