Рейтинг: 1.6288  
На голосовании
Предложил Пинчук Евгений 14.04.2017 02:00:14

Возможность увеличивать рассчитанный срок доставки

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

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

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

PS: В первую очередь предлагаю этот функционал реализовать для штатного модуля СДЭК.
Рейтинг: 1.9679  
Внедрено
Предложил Дмитрий Минаев 01.04.2015 21:54:12

Выбор доступных местоположений для Автоматизированной службы доставки

Привязка местоположений доступна для неавтоматизированных служб доставки, а что с Автоматизированные службы доставки?
Например: если мне не надо показывать Автоматизированную службы доставки Почту России для Москвы и МО, или не надо показывать Автоматизированную службы доставки моей курьерской компании в каком либо регионе?
Рейтинг: 1.9609  
Новая
Предложил Покровский Дмитрий 03.02.2015 12:25:29

Функционал работы с автоматизированными службами доставки

*Я как добавлю новые идеи (пункт 3,4 особенно сильно хочется донести до разработчиков Битрикс!), так и повторю уже существующие идеи вот эти:
- http://idea.1c-bitrix.ru/service-delivery-default/
- http://idea.1c-bitrix.ru/delivery-of-default/
- http://idea.1c-bitrix.ru/a-total-sorting-of-deliveries/
У них стоит статус "выполнено", но по факту они не выполнены.

1. Нужна сплошная сортировка - чтобы как настраиваемые службы доставки, так и профили автоматизированных служб имели сплошную сортировку.
Сейчас приходится пересортировывать их в шаблоне, меняя логику вывода, но это не удобно.
Пример - есть настраиваемая служба "собственный курьер, самовывоз из магазина + автоматизированная с двумя профилями: курьерская служба, самовывоз из ПВЗ" - соответственно надо вывести сначала собств.курьер, потом курьерская служба, потом самовывоз из магазина, потом самовывоз из ПВЗ.

2. Как бы я в шаблоне не пересортировывал службы и профили - все равно по умолчанию ставится выбранной первая из автоматизированных служб. Это дико не удобно и поменять это кроме модификации компонента sale.order.ajax нельзя.

2.1 Для разных местоположений хочется ставить разную службу доставки "по умолчанию"

3. Это уже для разработчиков модулей и автоматизированных сл.доставки - мы делали модули для служб доставок IML, Мультишип и т.д.
По логике Битрикс, в функции Compability нам надо отфильтровать какие профили подходят под наше местоположение, а в Calculate рассчитать уже по конкретной корзине стоимость для каждого профиля.

ОДНАКО, если мы работаем со сторонним API мы делаем только один запрос - кидаем службе доставки состав корзины, габариты, вес, местоположение и т.д. и получаем список вариантов доставки с ценами.

То есть для одного и того же местоположения в зависимости от параметров корзины могут быть доступны разные профили доставки. Приходится все делать в Compability - и слать запрос и расчитывать стоимость. При этом функция Calculateстановится бесполезной. Однако параметры корзины приходят только в Calculate, а в Compability нам приходится чесать затылок левой пяткой, чтобы вручную получить все параметры корзины. Это очень обидно, учитывая, что в следующей же функции они есть по умолчанию, но в Calculate они уже не актуальны.

4. Выбирая профиль доставки человеку может потребоваться выбрать доп.данные - например в профиле "ПВЗ" надо выбрать дополнительно пункт самовывоза.

а) Кнопку ПВЗ просто так не поставишь - приходится либо извращаться JS-кой, либо модифицировать шаблон. Нужен параметр, позволяющий профилю автоматизированной службы задать кусок HTML-я с собственной формой для собственных действий.

б) После выбора ПВЗ самый большой геморой - куда его сохранить? Сделать отдельное свойство заказа, ловить его JS-кой в форме оформления заказа.... Или создавать собственные инпуты и ловить их значение на событие оформления заказа. В общем тоже костыль.
Нужно дать возможность сохранить собственные данные в выбранном профиле доставки, как это делает битрикс, когда выдает форму выбора ПВЗ по складам. То есть для собственных нужд Битркис это сделал, а для нужд автоматизированной службы доставки такой возможности нет...

5. И последнее - давайте писать в параметры заказа не просто ID выбранной доставки, а еще и ее название (как в корзину вы добавляете не просто id товара, а дубль всей информации). Вот например модуль Мультишип вместе с самим агрегатором прекратили свое существование. Модуль умер вместе с API и люди были вынуждены его удалить - одновременно с этим во всех заказах потерялась информация о том, какой службой доставки и профилем был отправлен заказа. Да, id-шник остался, но он теперь ни о чем не говорит...