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

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

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

В корзину можно добавить товар, которого нету на складе (под заказ):
https://www.screencast.com/t/qBAlrhTzia5

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

С текущими настройками служб оплаты товар можно оплатить в момент заказа любыми доступными способами, например:
яндекс.касса, счет на оплату и т.д.
Скриншот:
https://www.screencast.com/t/WqzZUHtt

При этом в списке ограничений в службах оплаты на заданные условия (чтобы можно было оплатить только товары в наличии) - отсутствуют.
Скриншот:
https://www.screencast.com/t/pMyEeu3NWYx

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

Голосуем за добавление дополнительных требуемых ограничений в службы оплаты.

Сейчас нет возможности настраивать региональный маркетинг (скидки, наценки, подарки)


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

Очень этого не хватает, т.к. иногда нужно использовать доставку или оплату с ограничением "везде кроме региона/города" но приходится выбирать только обратным методом...

p.s. знаю про кастомизированные ограничения, но считаю этот тип ограничений достойным коробки...))

Предлагаю ввести функционал, ограничивающий постановку задач на конкретного юзера/отдел, или чтобы юзер/отдел мог принимать только задачи, которые поставлены на него посредством бизнес-процесса.  

В файле
/bitrix/modules/sale/admin/delivery_ajax.php

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

Проверку нужно изменить на такую:В этом случае наследование будет работать корректно и можно будет изменять типовые ограничения

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

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

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

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

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

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

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

Предлагаю установить лимит на размер прикрепляемых пользователями файлов.

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

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

Уважаемые разработчики!

Предлагаю вам рассмотреть идею, лежащую на поверхности: возможность добавления опции системного ограничения работы e-mail трекера (как при его подключении, так и к уже подключенному - для любых ящиков, доменов и поддоменов), автоматически ограничивающего фоновую подгрузку только тех входящих и исходящих писем, которые связаны (как в открытой/скрытой копии, так и прямо указаны) с e-mail клиента в CRM (лид, контакт, сделка и т.п.).

Эта, казалось бы, банальная доработка снимет все(!) вопросы по настройке, сортировке, раскладыванию пользователем по папочкам писем в своём почтовом клиенте (рабочей электронной почте), так как в CRM будут подгружаться только нужные письма. Очень много компания продолжают работать в первую очередт с e-mail и нужно дать возможность им сохранение такой возможности, удобно не теряя при этом (и не заводя руками) информацию в CRM. Конечно же, нужно не забывать, что у лида/сделки/контакта может быть несколько e-mail и нужно вести (подгружать) ветки общения по каждому из них.

Дополнительный важный момент: если по какой-то причине (политике безопасности и т..п.) контрагента (ряд нештатных сотрудников, работающих с порталом Б24, могут иметь несколько других направлений работы и захотят дать доступ CRM к своей почте, но строго его ограничить) мы не можем напрямую иметь полный доступ почте нештатного сотрудника Б24 (логин и пароль открывает доступ ко всем письмам), нужно предоставить возможность "узкой" входной настройки интеграции e-mail трекера контрагента с CRM, поставив явное входное ограничение сбора только переписки по лидам/контактам/сделкам, что может снять возражения по политике безопасности контрагента, опасающейся предоставления доступа ко всей его почте.

Надеюсь, написал достаточно подробно.

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

ИЛИ:
Сделать возможность отслеживать закрыта ли задача или нет.

ИЛИ:
Вообще, разрешить действию "Параллельное ожидание действия" использовать и запрос дополнительной информации. Если действие не выполнено, то пошло по второй ветке.

https://yadi.sk/i/117XrS0ukfiTT