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

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

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

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

Впрочем есть такое решение: https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=3439 Но тем не менее, может быть кому-то нужно упростить этот процесс. Поэтому пускай идея будет. К тому же поле, созданное по указанному выше способу  не будет выведено для редактирования в административной части.

Сейчас настройкой "служб доставки" инет-магазина можно установить три варианта стоимости доставки заказа:

1. доставка бесплатно;
   
2. некая единая фиксированная стоимость доставки (или фиксированная ступенчато диапазонами в зависимости от значений свойств заказа);
   
3. точная стоимости доставки рассчитанная по параметрам заказа (вес, габариты), на основе таблиц тарифов или используя API перевозчика.
   

Но бóльшая часть моих клиентов - малый бизнес, они:

• не ведут в 1С в карточках товара вес и габариты, которые можно использовать для автоматического точного расчета стоимости доставки с помощью таблиц или API;
  
• фиксированную усредненную сумму не хотят (в основном, из-за большого разбега стоимости доставки для ассортимента);
  

Не знаю как в России, а в Украине очень распространенный вид отправки инет-магазинами - "по тарифам перевозчика, за счет получателя".
Т.е. инет-магазин просто отправляет заказ выбранной клиентом службой доставки, а уже покупатель сам рассчитывается с перевозчиком при получении товара по его тарифам.
Покупатель сам ориентируется в стоимости доставки в свой город, может иметь свои собственные скидки у конкретной службы доставки и т.п.

И вот у меня каждый раз стоит задача - как этот вид доставки отобразить при оформлении заказа. Если создать службу доставки с названием "Оплата при получении по тарифам перевозчика" с ценой доставки 0 руб (по другому CMS не позволяет) – мы получаем скандалы от клиентов "а у вас там было написано 0 руб."

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

----
Т.е. нужны четыре варианта типов "служб доставки":

1) доставка бесплатно;
2) фиксированная стоимость доставки
3) точный расчет стоимости доставки по тарифам/API.
4) кастомная "служба доставки" без обязательного отображения цены (напр.: "По тарифам перевозчика, за счет получателя")

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

Замечательная функция, но хотелось бы видеть её не только для настраиваемых служб доставки, но и для автоматических.

Сейчас штатный функционал позволяет объединять доставки в группы. Кроме наглядности функционал такого решения практически пустой. Нужна более глубокая доработка. Например: курьерская доставка по МСК и Подмосковью. Стоимость доставки заказа по МСК зависит от веса, а если это замкадье, так ещё и от расстояния. А вот теперь представьте СКОЛЬКО необходимо составить служб доставок, чтобы курьерка работала по всем правилам компании.. Фактически один такой простой с виду сервис  требует около 20-ти доставок. Эту проблему можно было бы решить в рамках одного модуля специализированной службы доставки (как почта или емс), но такой службы до сих пор нет..

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

Все знают, что есть автоматизированные службы доставки, а есть настраиваемые. После рефакторинга служб доставок в 16-й версии (ау, когда всё выползет из беты???) все свалили в кучу, что где-то даже логично. Если автоматизированными всё понятно, то вот с настройкой настраиваемых не всё гладко. В них ну очень не хватает комиссии за объявленную ценность заказа.
Пожелание - добавьте комиссию за объявленную ценность, чтобы можно было рассчитывать стоимость доставки более корректно.

Размещаем стандартный компонент и шаблон оформления заказа с корзиной bitrix:sale.basket.order/.default

Есть два ручных способа доставки - Самовывоз и Курьерская доставка.
По ним нет никаких ограничений на показ (ни по местоположениям, ни по способам оплаты ни по чему либо другому).

Но при открытии страницы оформления заказа пока не ввели местоположение ничего не показывается в способах доставки.

Нужно чтобы такие службы доставки сразу были видны.

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

Раз решили переделать настраивамые службы доставки, то пусть у них будут символьные коды.

Неудобно в коде писать $delivery_id === 92 для проверки, что это "Почта россии". Я не против ID, но с символьным кодом в шаблоне было бы проще.

Сейчас собственный обработчик службы доставки подключается только в том случае, если лежит по пути "/bitrix/php_interface/include/sale_delivery/", хотелось бы хранить его в "/local/php_interface/include/sale_delivery/".

Добрый день!

Опишу типовую ситуацию.
Оптово-розничный магазин. Для оптовиков доступна бесплатная доставка курьером по Москве. Для розничных - пока только самовывоз, но будет свой платный курьер.

Заведена службы доставки "Доставка курьером по Москве". Ограничений нет.
Вопрос: как не выводить эту службу для физ. лиц, если ограничения есть только по Местоположению и по привязке к платежной системе.

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

В связи с обращением нашего сотрудника в техническую поддержку Битрикс и ответом специалиста: "Если говорить про компонент sale.ajax.delivery.calculator, то он работает только вкупе с компонентом оформления заказа sale.order.ajax. Отдельно его работа никогда не тестировалась и не заявлялась",

ПРЕДЛАГАЮ:

сделать отдельный сервис "Калькулятор доставки",

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

Особенно Калькулятор доставки актуален, когда существует собственная служба доставки.

Большая просьба, даже рекомендация, нет даже я бы сказал крик!
Вы планируете выпускать 14 релиз без модуля службы доставки национального почтового оператора Украины - Укрпочты , а только включаете модуль службы доставки для компании Нова Пошта. Это тоже самое что удалить в стандартной поставке Почту России. Ребята из Нова Пошта - хорошие ребята, ничего против них не имею, но большинство почтовых отправлений осуществляется именно Укрпочта. Прошу не подведите и сделайте долгожданный модуль в 14 релизе. Готов, если в это есть необходимость, как партнер, поспособствовать в наведении контактов в администрации Укрпочта

Сейчас у автоматических служб доставки есть приоритет перед ручными. То есть, например, на сайте заведена ручная служба "Доставка курьером" и автоматическая доставка PickPoint (или Почта России). При заходе на страницу заказа у юзера по умолчанию будет выбрана именно автоматическая (PickPoint), а желательно, чтобы была выбрана ручная служба доставки!

Автоматические службы доставки - это чаще всего экзотические варианты. Доставка в регионы и пр. Этими доставками редко пользуются. И работают они криво...

Например если доставка почтой наложенным платежём я должен иметь возможность отметить например в множественном селекте что "Наличные курьеру" покупателю не предлагать. Ещё примеры?

"Самовывоз со склада в Москве" - "наличные курьеру"
почтой (как угодно) - "наличные курьеру"
электронная доставка  - "наличные курьеру", "сбербанк итп"
"бесплатная доставка для предварительного тестирования (ну или как то так)"  - "оплата вебманями идр мгновенные методы".

Соответствующие компоненты (sale.order.full итп) будет несложно подогнать под данные настройки даже на уровне шаблонов.

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

Почему лучше явным образом указывать НЕсовместимые способы оплаты, а не с совместимые - чисто для удобства и наглядности. имхо гораздо сильнее бросаются в глаза вещи несочетающиеся чем гармоничные (эффект красной тряпки). кроме того несовместимых  вариантов теоретически должно быть меньше.
Хотя с другой стороны если в компоненте прописать что надо использовать ТОЛЬКО совместимые то меньше вероятность что покупатель воспользуется некой новой платёжной системой для которой забыли прописать несовместимые способы доставки.

Зачем вообще вся эта хрень нужна - затем что если вы не  дадите юзеру при заказе воспользоваться каким нибудь способом оплаты юзер просто обломится и ничего страшного не случится, а вот если вы дадите юзеру воспользоваться несовместимым способом оплаты (особенно электронные платежи и особенно(!!!) кредитки) - то тогда больше обломитесь вы потому что рефунды штука неприятная обоим сторонам.