Редакция Интернет магазин + CRM.

При создание компании в CRM, в реквизитах можно использовать поиск по ИНН и заполнение автоматически реквизитов компании. У нас Интернет магазин + CRM, карточка оформления заказа настраивается на стороне CRM, поэтому прошу сделать возможность заполнение полей для клиента, когда он оформляет заказ в интернет-магазине с помощи этой же функции.  

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

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

Смотрю по вебвизору как клиенты пытаются оформить заказ с мобильного, тыкают на блоки доставки, оплаты но не могут сообразить что нужно нажать кнопку "далее" что бы он развернулся.

Поле выбора местоположения с мобильного нужно 2 раза нажимать на выбранный город, тоже не удобно.

И считаю самое главное сделать возможность по желанию добавлять "покупку в 1 клик" хотя бы на страницу оформления заказа, ну сколько лет уже все устанавливают сторонние модули которые работают день через день. Пора бы уже самим сделать. При оформлении заказа нужно что бы сперва клиент указал имя телефон почту, затем нажал кнопку далее, в этот момент сформировался заказ, а далее по мере заполнения данные подтягивались в заказ, так если клиент сорвётся у интернет магазина будет возможность позвонить ему или написать и узнать почему не удалось завершить заказ. У нас постоянно какие то проблемы со службами доставки, или бывают даже приколы что клиенты не могли вписать свою фамилию на русском и об этом не узнаешь пока кто то сам тебе не позвонит и не скажет что мы сливаем в трубу рекламный бюджет.      
 

Добрый день!

Предлагаю доработать страницу "оформления  заказа"? Сейчас страница жутко неудобна тем, что клиентам постоянно  приходится вспоминать свой почтовый индекс (обязательный для заполнения)  и несколько раз нажимать кнопку "далее", чтобы переместиться на другое  окно для выбора способа доставки и метода оплаты. Можно ведь все эти  блоки разместить на одной странице, чтобы все было перед глазами без  лишних действий.

Добрый, хочется уменьшить количество шагов оформления заказа

Сейчас нет возможности сделать переводы названий свойств, платежных систем и служб доставки, т.к. шаблон полностью на JS. Фактически мультиязычность в этом компоненте не реализована полностью. Техподдержка предлагает следующее:
"Надо создавать сущности на другом языке и разделять их по типам плательщиков."
Но это же абсурд.

В CMS:
Провёл эксперимент с стандартным шаблоном оформления заказа... ничего не понятно в 50%... (опрошено 20 человек - сотрудников компании)

Кнопку далее просто не замечают... кликают в заголовки разделов(например "Доставка"), а они не активны...

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

На шаге страницы Корзина по сути присутствует только функционал изменения количества и состава заказа (в некоторых готовых решениях это даже есть в плавающем мини окне корзины). Это лишний раздражающий шаг для покупателей. Эти кнопки изменения количества и удаления товара можно просто перенести на страницу оформления заказа и такое упрощение всего процесса!

Занимаясь разработкой сайтов зачастую приходится переносить очень интересные решения на БУС. И благодаря работе отдела маркетинга последнее время все чаще клиенты просят уйти от "кучи ненужного кода" и реализовать их логику не нарушая работы стандартных механизмов БУС'а. Это была преамбула, а сейчас будет немного эпик-фейлов.

При разработке выяснилось, что документация по созданию своих правил, условий и действий в Скидках и Правилах корзины просто отсутствует. Не беда - работаем по-старинке: ковыряем ядро. А дальше встает эпик-фейл: до момента создания заказа НЕЛЬЗЯ вытащить все примененные скидки.

То есть, что это означает по-факту:
1) Вы не можете сообщить клиенту: добавь этот товар к заказу и получишь подарок или возьми 2 получи скидку
2) Вы не можете интегрировать внешний механизм скидочных карт, потому что Вы не знаете какие правила корзины будут выполнены ДО момента их выполнения
3) Вы не можете произвести отладку системы, так как цена изменилась, но сигнализировать почему она изменилась Вы не можете. Т.е. выбрал новый тип доставки -> изменилась цена. Все понятно.
Добавил еще 1 товар и цена может измениться как в бОльшую сторону (например менеджер ошибся при заведении скидки и установил что за 2 товара Х - наценка 10%, тогда при покупке 2-х товаров по 100 рублей, клиент увидит не 200, а 220 и не узнает почему и будет жаловаться, а разработчик будет отлаживать данный механизм очень долго).
4) Нельзя проводить аналитику брошенных корзин - как узнать, что наличие акции Х в январе увеличивает показатель брошенных корзин на 5% ? Нет, можно понять если в январе только эта акция, а если их 10? А если 50? То есть нужно составлять полное исследование ВСЕХ брошенных корзин чтобы это понять.

Предложение звучит следующим образом:
1) Храните (или позвольте хранить) примененные правила корзины к конкретной корзине/неоформленному заказу. Можете считать из последнего заказа, можете "выбирать первый", если неизвестно.
2) Напишите документацию по расширению сценариев. Это очень нужно!

Суть в следующем: при оформлении заказа модуль доставки рассчитывает срок доставки, согласно данным перевозчика (контрольный срок). Но эта цифра не отражает реальные сроки доставки, т.к. заказ нужно ещё собрать и передать в службу доставки. Помимо этого, зачастую к информации о сроках доставки идёт примечание, вида, "не учитывая день приёма груза". Ещё и день передачи заказа получателю в этот срок может не входить.

В случае с посылками Почты России, когда срок доставки составляет 2-3 недели, это не так критично.
Но с курьерскими службами, которые дают срок 1-2 дня, реальный срок от оплаты до получения посылки может легко превратится в 4-5. А это уже чувствительней.

ПРЕДЛАГАЮ в штатные службы доставки добавить параметр "Увеличить срок доставки на (дн.)", чтобы при оформлении заказа покупателю отображался не тот срок, который даёт перевозчик, а увеличенный на это значение, включающий в себя время сбора заказа и время передачи его в доставку. Т.е. максимально приближенный к реальному.

PS: В первую очередь предлагаю этот функционал реализовать для штатного модуля СДЭК.

Коллеги!

Пожалуйста, исправьте явные недоработки в стандартном шаблоне bitrix:sale.order.ajax (по состоянию на 01.06.2016):

• Нельзя редактировать состав заказа, хотя всё в интерфейсе указывает на такую возможность (пользователю предлагается его "Изменить", но нажатие данной ссылки ничего толком не дает)
• Некорректная, сбивающая пользователя с толку, работа поля "Скидка" в правой плавающей части итоговой информации по заказу. Пример: мы настроили скидку на доставку при заказе от 10000 руб. Если заказ меньше 10000 руб., то доставка стоит 1000 руб. Получилось: "Товаров на 10000 руб. (зачеркнуто, например, 15000 руб. - "старая цена"), Скидка: 1000 руб., Доставка: 0 руб., Итого: 10000 руб.". Абсолютный бред.
• Подключение бутстрапа, который переопределяет некоторые базовые стили шаблона. Например, цвет ссылок при наведении курсора, дизайн цепочки навигации, если она названа классом breadcrumb...
  

Столкнулся с проблемой и возник вопрос: Почему при таких наворотах и возможностях всей платформы, шаблоны печатных форм необходимо писать вручную, так ещё и с такими "плясками с бубном"?!

Что проще "прикрутить" тот же встроенный HTML-редактор, с возможностью добавления в печатную форму ЛЮБОГО свойства товара или заказа?

У кого-то заказчик хочет, чтобы в форме присутствовал артикул, у кого-то цвет или метро доставки!

И если свойства заказа кодом добавляются легко, то свойства или характеристики товара - это просто "сизифов труд"!

Такой замечательный инструмент, позволяющий осуществлять подготовку документов клиенту БЕЗ 1С давно вами заброшен и не развивается!

Уважаемые разработчики обратите внимание на этот момент, поскольку даже существующие варианты - это "костыли", а не грамотное решение.

С 16 версии sale.basket.order.ajax не поддерживается, поэтому придётся переписывать на sale.order.ajax, а купона в нём нет. И как сказали в саппорте, в планах такого нет.
Делать 2 страницы для оформления не айс, поэтому очень хочется иметь функционал купона.

Здравия всем!

Появилась одна задачка, c которой техподдержка отправили сюда:)

Итак, пользователю на сайте начисляются какие-то скидки за участие в каких-то акциях (тут все ок), а также, за использование определенных служб оплаты начисляется наценка. Так вот, в заказе эти все суммы и скидки и заказы - сливаются воедино и нам отдается уже сумма с учетом скидок.

Задача: вывести пользователю отдельно наценку и отдельно скидку. И вот тут получается ступор: а ведь имеем одну общую сумму, в которой уже учтена разность между наценкой и скидкой.
Выходит, что отдельно показать пользователю, что ему начислили наценку за использование такой-то службы оплаты мы никак не можем:(

Предлагаю в заказ вытягивать полный список скидок (и наценок), которые были применены к заказу, а разработчик уже сам решит, в каком виде это все выводить - как разницу скидок, или отдельными суммами...

Хотя бы ID-шники скидок. Суммы уж как-нибудь сами просчитаем (хотя если это будет тоже из коробки - будем рады:) )

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

Дано:
Интернет-магазин, обмен товарами, заказами с 1С через XML (стандартно). Создан десяток свойств заказа (типичные свойства - телефон, почта, ФИО, адрес и т.п.)

Проблема:
Очень редко в выгрузке заказов наблюдаются заказы без свойств. Такой проблемный заказ - 1 на 2000 заказов. Расследование показало, что этот XML формируется в ту же секунду, что и оформление заказа.

В ТП Битрикса задан вопрос (тикет 710508 ):
Ответ сотрудника ТП:
Безобразие. В 1С могут улететь заказы без свойств.

Идея:
Защитить транзакциями оформление заказа или добавить некий булевый признак к заказу "годный к выгрузке" и выставлять его только после оформления заказа, прикрепления товаров и всех свойств.