АБ свое решение тормознули. Возможно ждать придется долго. А с CS-Coding действительно непонятно. Ощущение, что контора загнулась. Но по сути решение то уже было реализовано.
Чтобы СМС работало нужно подключаться к смс шлюзу. Из коробки такого не ждите, т.к. в каждой стране свои да и не слышал я о новых подобных модулях в ближайших планах. Поэтому завязывать чекаут на регистрации по телефону - значит не у всех будет возможность отправить смс с информированием о заказе и прочего, в том числе подтверждение регистрации и сброс пароля.
P.S. В Украине я уже подвязывал информирование о появлении в наличии по смс через АВ модуль. Но там нет смс шлюза для России. Можно сделать и восстановление пароля, и временный пароль и много чего. Но это не будет стандартным решением, потому как модуль смс шлюза сторонний, а значит из коробки его не сделают.
Чем больше думаю о регистрации по телефону, тем яснее становится, что вы правы. Но иметь надежное, рабочее, регулярно обновляемое решение все таки хочется. Сейчас вариант только один, ждем Алексов еще. Да и вообще, тема про чекаут была, а начались хотелки всякие)
ну такой модуль можно купить за денежки и от самих разработчиков цскарт. похоже в коробку это не включают, потому что это никому не нужно.
Считаю так:
чтобы прийти к хорошему результату, надо рисовать наглядную блок схему UI со всеми вытекающими…
Для этого нужен сервис который позволяет это делать.
А то мы тут долго будем топтаться на месте…
Смски дело хорошее.
Вы их используете? Какого агрегатора? Дело в том что прежде чем интегрировать это надо понимать что агрегатор которого мы заинтегрируем лучший с разных точек зрения.
Да использую https://turbosms.ua/price.html для информирования покупателя о том что заказ создан, а также при формировании документов отгрузки Новой почты клиенту автоматически высылается номер его посылки в смс Также в ручном режиме рассылаю реквизиты для оплаты на карту по шаблону. Делал рекламную рассылку по собранной базе номеров. Большинство сервисов работают и в России и Европе. Есть еще https://letsads.com/ его использует маркетплейс prom.ua
Уже проблема, потому что сервис украинский, а львиная доля пользователей из России. Таким образом будем минимум две интеграции. В общем пока ничего сказать не могу, будем копать, сейчас пока изучаем этот вопрос.
https://letsads.com/ есть в Москве и и в Украине оплату принимает российскими и украинскими способами оплаты
1 лайк
Я считаю, что привязываться к конкретному оператору неправильно. Необходимо создать mini-API событий, переменных, чтобы можно было настраивать шаблоны, а уже партнеры разработают модули интеграций с необходимыми сервисами.
4 лайка
Это было бы вообще идеально, чтобы была так сказать розетка к которой любой партнер мог создать вилку, я не знаю просто насколько это реализуемо, если это реально, то это хорошо для начала можно сделать пару наиболее востребованных сервисов, а партнеры потом бы добавляли необходимые.
1 лайк
Именно, тоже уже сколько раз писал, что такие вещи надо реализовывать как интерфейс пользователя + класс-коннектор, наследованием от которого модули интегррации уже и работают
Мы обычно стараемся заинтегрировать один из самых популярных, чтобы
- в коробке было хоть какое то решение
- на примере проверить что ядро которое мы пишем реально можно использовать для послудющих интеграций.
все правильно, и никто не против, речь о схеме интеграции сторонних сервисов:
- модуль интеграции (коих может быть несколько) которые обращаются к
- модулю-коннектору (да, то же самое мини апи), набор функций, перекрывающих возможные действия по взаимодействию с интегрируемыми сервисами. Функции мини апи - вот они уже взаимодействуют с
- ядром.
Данная схема позволяет сколько угодно менять схемотехнику ядра (3) и взаимодействие с ним(2), совершено не требуя в догонку срочно адаптировать модули интеграции (1)
-
Оформление заказа по моему мнению должно начинаться с адреса доставки с автозаполеннием.
Это однозначно приятно и радостно.
Прмиер полей/кнопок:
[ввести адрес - текстовое поле]
[выбрать пункт самовывоза с показом карты/списка адресов ] и где то в этом месте отобразить [войти в личный кабинет].
Отсюда надо плясать и делать всю остальную зависимую логику способов доставки. -
Реализовать зависимости способов доставки от адреса доставки.
Не надо клиенту отображать лишний раз бесполезные способы доставки.
Это если бы Президенту показали бы адрес доставки и способы доставки, а потом с оговоркой “в ручном режиме” начали бы чиркать на бумажке и говорить, что этот способ доставки лишний, этот тоже итд итп…
к сожалению разработчики не думают над автозаполнением из коробки (или я не прав?), программисты любят печатать все руками.
1 лайк
Так лучше 
То есть покупатель заполнит адрес, потом выберет самовывоз и адрес пропадет? Или нужно листать и проверять, что есть самовывоз? Это плохое решение, ставить блок адреса первым. Первым должны идти город и способы доставки
3 лайка
Все верно пишете, самый крайний вариант - спросить сначала ФИО + email или телефон. Остальные поля после выбора способа доставки.
4 лайка
Так ведь и надо сначала предлоижть клиенту варианты… а потом скрывать все что нужно.
Я показал вариант, когда клиенту будет доставка по адресу.
В начале должно быть 3 кнопки(как хотите называйте) с вариантами:
[доставка - текстовое поле]
[самовывоз с показом карты/списка адресов ] и где то в этом месте отобразить
[войти в личный кабинет].
Надо понимать какие поля нужны для доставки, а какие для самовывоза.
Может было бы неплохо иметь конструктор полей?