Андрей Николаев

Вы просто не внимательно почитали документацию по продукту.
Если покопаться в документации (я привожу пример из блога, но в документации это тоже есть), то можно увидеть, что скидки применяются последовательно по матрице применения. Сначала отрабатывают ВСЕ скидки минимального приоритета, то есть по П(риоритету) и С(оритровке): П1С1, П1С2, П1С10, а затем уже П2С1, П2С4.... Таким образом П1С2 будет выполнена раньше П2С1.

Таким образом порядок правил у Вас такой:
10% на бренды ААА и БББ, новую коллекцию если не отработало идем дальше
50% на бренд ССС, новую коллекцию если не отработало идем дальше
30% на всю новую коллекцию

Для того чтобы диагностировать эту ситуацию нужно:
1) Скриншоты условий скидок (как они прописаны в правилах корзины 1 и 2 вкладки)
2) Данные по 3м товарам: к какой категории они относятся (и вообще все параметры которые задействованы в п.1)

Эм... а что у Вас за жесть со скобками происходит?

Это не нормально

=if ({=Variable:TODAY{{=datediff({=Variable:DATE1}, {=System:DATE}, '%d' ) }}} <4, 'true')

Для корректной работы создайте 2 переменных:

1) Количество дней (тип "Число"), которое будет хранить разницу между двумя числами
2) Условие (тип "Да/Нет"), которое будет хранить соответствие условий количества дней

Лучше разделить эти переменные, так как в случае усложнения процесса количество дней и условие может ветвится.

В блоке изменение переменных можно прописать соответствующие значения
Для получения разницы:
=datediff({=Template:DATA1}, {=System:Now}, '%d')

Для сравнения
=if({=Variable:diffDate}<4, 'Y', 'N')

Надеюсь меня тут поругают и ответят как надо было побороть эту проблему.

Конечно поругают: вы ведь делаете кривой велосипед, вместо того чтобы взять и использовать штатную CUser::ChangePassword (ее описание в API).

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

Изучить документацию по Приложениям24 и начать их создавать :)

Возможно в меня сейчас что-нибудь прилетит, но мы используем Битрикс24 (собственно его же и внедряем).
Сделка прекрасно разбиваемся по направлениям:
- Проект
- Сопровождение
- Домены
- Лицензии

Для разработчиков используем Redmine, а для тех.поддержки Okdesk.

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

- Домены
То же, что и с лицензией, за исключением того что там нет согласования, а из документов только счет/акт

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

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

Все внутренние коммуникации, евенты и т.п. берет на себя битрикс24. Учет рабочего времение (формальный, т.е. не сколько отработал, а работал ли вообще).
Рядовые сотрудники получают задачи в Redmine / Okdesk, а портал у них для общей информации по компании.

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

P.S. Jira кусается по цене сильно

Ну так вы же фильтруете по IBLOCK_ID, что мешает фильтровать по коду раздела или по его ID?

$select = [
	"UF_HEADH1"
	
];

$sort = [
	"SORT" => "ASC"
];

$filter = [
	/* @var int ID инфоблока */
	'IBLOCK_ID' => 1,

	/* @var string Символьный код раздела */
	'CODE' => 'SECTION_CODE',

	/* @var int ID раздела */
	'ID' => 123,
];

$rsResult = CIBlockSection::GetList(
	$sort,
	$filter,
	false,
	$select
);
while($arResult = $rsResult->GetNext())
{
	echo $arResult['UF_HEADH1'];
}

Как сделать так, чтобы после удаления лида при повторном обращении клиента через эту же открытую линию вновь создавался новый лид?

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

Как создать сделку с клиентом, с которым идет общение в открытой линии, когда при попытке перейти в CRM лид не обнаруживается? При этом я не могу создать новый лид и внести в него id vk, так как в открытой линии не виден id vk клиента.

Для уже удаленного, кроме как через API в коробочной версии никак.
Для облака - вообще никак.

Все зависит от того какая именно редакция битрикса.
Например в Битрикс24 есть модуль Интранет, внутри которого (в настройках) есть "ссылки на внешние программы" для индексации содержимого.
За pdf отвечает следующая комманда:
pdftotext "#FILE_PATH#" -enc UTF-8 -nopgbrk -
где #FILE_PATH# - это полный путь к файлу, который нужно проиндексировать.

В теории для Управления сайтом можно написать обработчик создания/редактирования элемента инфоблока, куда заливаете файлы и дописывать в SEARCH_CONTENT / поисковый индекс содержимое файла.

На основе ответа от битрикса, а так же темы на форуме битрикса, небольшой фрагмент кода для отписки:

use \Bitrix\Main\Loader;
use \Bitrix\Sender;

/**
 * @var string Email пользователя
 */
$email = 'test@efusion.ru';

/**
 * @var string Список идентификаторов рассылок для отписки 
 */
$unSubscribeList = [
    3
];

try
{
    if ( !Loader::IncludeModule('sender') )
    {
        throw new \Exception("Sender module not installed");
    }

    if ( empty($unSubscribeList) )
    {
        throw new \Exception("Empty unSubscribeList param");
    }

    $contactId = Sender\ContactTable::addIfNotExist([
        'EMAIL' => $email
    ]);

    if ( !$contactId )
    {
        throw new \Exception("Contact by email not found and has error when creating");
    }

    $contact = new Sender\Entity\Contact($contactId);

    $data = $contact->getData();

    foreach ($data['SUB_LIST'] as $subscriptionId)
    {
        if ( in_array($subscriptionId, $unSubscribeList) )
        {
            $contact->unsubscribe($subscriptionId);
        }
    }

}
catch( \Exception $e )
{
    var_dump( $e->getMesage() );
}

Что касается вопроса "в лоб": почему бы не использовать агрегирующую функцию SUM для вычисления общего количества и группировку по PRODUCT_ID?

Что касается формальной стороны: это не лучший вариант, ведь у вас может быть 2 товара отпущенных по разной цене. Т.е. товар 3022 отпущенный по 130 рублей в количестве 2х штук и еще 1 шт. товара 3022 по 100 рублей (например при покупк 2х скидка на третью вещь 30 рублей).

В \CIBlockPropertyTools::CODE_BLOG_COMMENTS_COUNT хранится название свойства элемента в котором хранится число комментариев к нему. Т.е. выполняете обычный getList с указанием этого свойства (PROPERTY_*) и выводите на страницу

откуда тянуться данные по задачам?

Вы имеете ввиду API? Где они лежат в базе?

В каком файле компонента эта происходит?

Весь рендеринг детальной вьюхи находится в компоненте bitrix:calendar.view.slider

На данный момент (2018 год) в Битрикс24 существует модуль "Облачные хранилища", который позволяет передавать загружаемые файлы на поддерживаемые хранилища.
То есть, с точки зрения пользователя ничего не изменится - они будут пользоваться битриксом так же как и раньше, но все файлы будут храниться в подключенном облачном хранилище.

На 2018 год поддерживаются следующие сервисы:
- Amazon Simple Storage Service
- Google Storage
- OpenStack Object Storage
- Rackspace Cloud Files
- Clodo.ru
- Selectel
- HotBox

Мы в компании (20 человек, 10 активно работают с файлами) используем вариант с Selectel и за 2 года 80+ ГБ (хранение+трафик) съело около 3-4 тысяч рублей.