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

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

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

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

Привет!

Была задача прикрутить на сайт сторонние службы доставки, например Boxberry, Pickpoint и тд.

При создании нового обработчика службы доставки в битриксе, столкнулся с проблемой, что нельзя при выполнении кода динамически выводить в оформлении заказа (order.ajax) ни профили ни склады. Т.е. получается что все профили и склады должны быть заранее определены и соответственно настроены в службе доставки. А как быть если данные получаем по API от сторонних служб и данные необходимо постоянно актуализировать, т.к. например в той же службе доставки Pickpoint пункты самовывоза закрываются и открываются новые каждый день.

Писал в тп, ответ:
Через это понятно так и сделал пока, но хочется по стандартам битрикса!!!

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

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

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

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

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

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

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

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

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

Сейчас (sale 17.6.6) компонента просто не показывает неподходящие по ограничениям и условию совместимости (isCompatible) методы доставки. Во многих случаях это очень удобно, т.к. упрощает жизнь покупателю.

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

В общем, владелец магазина хочет "рекламировать" методы доставки, но сейчас ни компонента, ни API этого не позволяют.

\Bitrix\Sale\Delivery\Services\Manager::getRestrictedObjectsList - выдает только подходящие службы
\Bitrix\Sale\Delivery\Services\Base::isCompatible - только "да" (подходит для данной отгрузки) или нет, без комментариев

При текущей реализации API и компоненты приходится делать свои службы доставки (а можно было просто указать в админке название/описание ограничения и его бы показали на странице) и свои компоненты.

Добавлено: По ситуации я подал обращение в поддержку 1796491 "Как предполагалось получать данные о том, почему именно служба доставки не совместима с отгрузкой?". По нему была создана заявка в разработку 71592 "дать возможность проталкивать свое описание в компонент оформления заказа".

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

*Я как добавлю новые идеи (пункт 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-шник остался, но он теперь ни о чем не говорит...  

В настраиваемых службах доставки не хватает:
- возможности указать одну и ту же службу доставки для нескольких сайтов;
- возможности копирования в списке служб.