Спасибо, приятно слышать. Да, в поиск на списке товаров вернулась возможность выбрать категорию из дерева. Но и возможность найти категорию вводом не пропала.
А фильтры ещё и быстрее должны стать, когда в категории много товаров и вариантов характеристик. Подробности тоже в новости будут.
[*] Статусы заказа: В статусы заказа добавлен новый параметр «Считать заказ оплаченным». Только заказ с этим параметром будет рассматриваться в статистике как оплаченный заказ.
Этот параметр ставится глобально к статусу, или локально привязывается к заказу (один статус у разных заказов может иметь различное значение этого параметра)? Если глобально - то не имеет смысла, так как придется иметь всех статусов по два, на варианты с предоплатой и с постоплатой. Если значение привязывается к заказу - то круто. Правда тогда значение должно наследоваться в рамках заказа при смене статуса… Что снова приводит нас к мысли, что второй статус был бы наверное все же проще.
Хотя я понимаю, что определяющее в этом пункте - слово “статистика” (наверное не ошибусь, если скажу, что пользуются ей единицы?), а не “работа с заказами”
Я бы завел новую сущность - документы оплаты. Чтобы статусы были статусами, при этом была возможность посмотреть сколько денег упало по заказу, сколько осталось, создалась возможность брать частичные предоплаты и интегрировать с учетными системами. А то статус - ерунда. После оплаты ведь заказ легко может статусы менять еще долго, причем на совершенно идентичные, как предоплаченные, так и не оплаченные. Например, после оформления заказа он может быть в статусе Производство, Комплектация, Доставляется независимо от того, оплачен заказ уже, или будет оплачен по факту доставки. А сейчас выходит что оплаченный заказ и трогать то нельзя чтобы не утратить информацию об оплате, хотя это не логично.
вот я и хочу понять, что в итоге изменилось в ядре, может я и зря доработки какие-то заказывал не дождавшись
тут видимо нужно реализовывать как вариант у способа оплаты, ставить чекбоке считать оплаченный, а у статуса радиогруппа.
Оплата: Оплачен, Учитывать способ оплаты, Не оплачен
Как результат Выполнен - оплачен, Доставляется, если способ оплаты предоплата, будет оплачен, если оплата при получение будет не оплачен.
Если пойти дальше, то хорошо бы еще и зависимости можно было прописать, например:
Разделить статусы на группы: Магазин, Доставка, Покупатель
Предоплата:
пока не оплачен - можно менять статусы в пределах группы Магазин, но смена статуса на любой из двух других групп невозможен, пока не будет проставлен статус оплаты.
Оплата при получении:
Возможно любое изменение статусов. Здесь очень приятный бонус пометки оплаты. Сейчас мы используем два статуса: Вручен покупателю и Выполнен - например сейчас мы Выполнен ставим, когда получим деньги за заказ, а это может случиться и не очень скоро.
Еще есть и вариант возврата, который тоже надо учитывать, когда оплату надо возвращать (Оплата возвращена) и использовать статусы Возвращается и Вернулся.
Связывать статус с оплатой вообще не логично, это ошибочная связь, костыль. Статус к оплате вообще имеет очень опосредованное отношение. Да и оплачен… а сколько оплачено, что оплачено? А если заказ случайно изменили и не заметили? Тут просто неправильная реализация. Да и даже у способов оплаты. Вот на первый взгляд кажется что способы оплаты сохраняют какие-то данные о транзакции. А по факту нет - это просто текстовое поле, разное у разных способов оплаты. И разные модули платежные совсем по-разному сохраняют информацию о платежных реквизитах покупателя, оплате, в произвольном формате, который невозможно использовать. И довольно обидное следствие - невозможность корректно ввести частичную предоплату.
Типов оплаты только в чеке может быть несколько: аванс (неизвестен заранее состав заказа), предоплата, предоплата 100%, кредит, полный расчёт…
Связать можно, но как раз наоборот, для каждого СПОСОБА оплаты, назначить доступные СТАТУСЫ оплаты, и СХЕМУ возможного изменения статусов ДОСТАВКИ в зависимости от назначенного статуса ОПЛАТЫ (у которых тоже есть своя схема последовательного изменения)
Ну да, это было бы как раз правильно.
А если способ оплаты На расчётный счёт, отгружать заказ можно с оплатой типа Аванс и Предоплата и Кредит, то будет 3 разных статуса Отгружено Полный расчёт, Отгружено Предоплата и Отгружено В кредит? И так для каждого способа оплаты
Как не работала синхронизация с 1С УТ 10.3 так и не работает(нет подключения к серверу)
Ну, это во-первых странно, а во-вторых вы очень быстро обнаружите что новые статусы не создаются, потому как в CS-Cart их число из коробки ограничено числом ниже минимума, а часть букв уже из коробки зарезервированы.
Так я и не пользуюсь. Просто хочу сказать, что, видимо, статус оплаты должен быть отдельно, т.к. слишком много комбинаций и разная специфика у разных магазинов.
Это потом невозможно интегрировать с другими системами. Мы же не в вакууме существуем. Потому статус статусом, но он не должен быть единственным признаком оплаты, должны быть фактические документы, где написано что и в каком количестве, откуда оплачено. Такое есть и в CRM и в 1С(и других системах учета). А статус… ну вот есть, например, оплата, а потом изменился состав заказа, что делать? Нужны прямые данные, а не опосредованные.
Были бы нормальные интеграции… За деньги, кто же спорит. Но - работающие. Тогда бы магазин мог бы быть просто передающей станцией от покупателя в crm. И это было бы правильно, ведь работать с покупателем надо централизовано, в одной системе, а точек соприкосновения с покупателем может быть много. Но, интеграций у нас нет, и приходится крутиться, создавая из карта монстра
А как их нормальные сделаешь, если общей логики нет, как следствие все пользуются костылями с статусами, как следствие не создать универсальный модуль - у всех какие-то “особенности” бизнеса, а по факту следствия натягивания совы на глобус. Сложность интеграций от того и высокая что из-за отсутствия логичных и понятных общих механизмов приходится мудрить какие-то уникальные костыли. И потому нет стандартных.
[!] Модули: Почта России: Города: Отсутствовал почтовый индекс населенного пункта Совхоз имени Ленина, Московская область. Исправлено.
Повеселило ))) У вас там по индексам не соответствие процентов на 10-20, оценить сложно то имея но за 1000 заказов выявил 12 случаев. При обращении в хелп деск обещали все актуализировать ))) Да, вижу, добавили совхоз имени ленина ))))