Роман Грицук

При отгрузке проверяется наличие только тех товаров, для которых включен количественный учёт. Его можно выключить в настройках модуля Интернет Магазин или для каждого товара в отдельности на вкладке Каталог в самом товаре. О каком чеке идёт речь?

ProductTable::update должен возвращать объект класса Result. Посмотрите что в нём

$updateResult = \Bitrix\Catalog\ProductTable::update(19612, Array('RATIO' => 2)); 

print_r($updateResult);

Отдельного метода для обновления не нашел. Можно обновить так:

BX.Sale.BasketComponent.fillTotalBlocks();
for(itemId in BX.Sale.BasketComponent.items){
	if(BX.Sale.BasketComponent.items.hasOwnProperty(itemId)){
		BX.Sale.BasketComponent.redrawBasketItemNode(itemId);
	}
}

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

Чтобы убрать рекурсию в событии:
- в начале обработчика объявите глобальную переменную (или статическую в классе). и проверяйте ее наличие.

global $isOnSaleBasketSavedHandler; 
$isOnSaleBasketSavedHandler = true;
if(!$isOnSaleBasketSavedHandler){
     //Ваш код
}

- дальше проверяете эту переменную
<?

Такого метода нет. Стандартные компоненты выбирают цену на товары за несколько запросов. Посмотрите код компонента catalog.section на то как сделано там.

UF_ROLE и UF_PROFILE это не поля \Bitrix\Main\UserTable. Скорее всего вам должна была высветиться ошибка с сообщением об этом.

Несколько я вижу это не стандартное почтовое событие , а что то самописное. Скорее всего кавычка там где генерируется событие. Ищите место где вызывается CEvent::Send ( или Bitrix\Main\Mail\Event::send ).

При большом количестве разделов (30к+), Bitrix начинает вставлять палки в колеса как разработчику, так и пользователю, который будет работать с такими ИБ.
- Списки элементов ИБ будут безбожно тормозить в интерфейсе. На каждом хите будет добавляться фильтр по разделу.
- Редактировать их становится очень затруднительно, опять же из за долгой загрузки интерфейса и большого времени изменения.

Всё это из за того что разделы это NESTED SETS деревья. При добавлении/удалении раздела происходит вычисление LEFT_MARGIN и RIGHT_MARGIN для каждого раздела во всем инфоблоке.

Для добавления и обновления (CIBlockSection::Add, CIBlockSection::Update) есть параметр метода $bResort, который позволяет отключить этот перерасчёт в момент их выполнения.
Только после этого ОБЯЗАТЕЛЬНО надо выполнять CIBlockSection::Resort.

Это можно использовать при большом количестве операций Update и Add. Сначала выполняете все операции Update и Add с $bResort=false, а после них CIBlockSection::Resort

НО!! К сожалению, такой параметр для CIBlockSection::Delete не доступен. И вот тут начинается жесть.
Каждый вызов CIBlockSection::Delete, это:

• пересчет границ NESTED SETS,
  
• CIblockElement::GetList (поиск вложенных элементов)
  
• CIblockElement::Delete (если в разделе были элементы),
  
• Запрос к таблице которая хранит множественные привязки элемента к разделам (поиск значений и их удаление)
  
• CIBlockSection::GetList (поиск вложенных разделов)
  
• CIBlockSection::Delete (удаление вложенных разделов)
  
• Переиндексирование поиска
  
• Запросы к UF_* полям раздела (поиск значений и их удаление)
  
• При заполненных SEO полях, запросы к таблицам которые их хранят (поиск значений и их удаление)
  
• При расширенном управлении правами это еще запросы к таблицам которые хранят эти настройки (поиск значений и их удаление)
  

и это скорее всего не полный список, а только то что могу назвать по памяти....

Нельзя быстро удалить разделы стандартным API без написания своих запросов к БД которые проделают всё что описано выше. В идеале надо взять код стандартного CIBlockSection::Delete, внимательно его изучить и написать свой метод который будет с помощью прямых запросов делать тоже самое, но оптимально.

Если же вопрос стоит в том чтобы удалить эти разделы за ЛЮБОЕ количество времени, тогда можно написать страничку с пошаговым удалением разделов, через ajax запросы. Причем надо учитывать, что вначале разделы будут удаляться ОЧЕНЬ медленно и ajax запрос может отвалиться по таймауту, поэтому надо будет за один шаг удалять пару разделов. А ближе к границе в 10к разделов, за один шаг можно будет удалять уже большее количество.

Вот тут очень хорошо всё описали https://www.intervolga.ru/blog/projects/bitrix-mul...

OnBeforeIBlockElementUpdate

В событии:
1) Проверяете принадлежность текущего пользователя к крупе Контент Редакторы. Можно с помощью CSite::InGroup
2) Если да, то по ID Элемента в $arParams события, делаете запрос CIBlockElement::GetByID.
3) Сравниваете CREATED_BY из запроса и глобальный $USER->GetID();
4) Если они не совпадают:

$APPLICATION->throwException("Элемент может генерировать только создатель");
return false;

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

Если чисто случайно Вы не успели в 30 дневный срок сделать сайт и лицензия закончилась, то, вроде, еще 2 недели будет висеть сообщение о скорой блокировке. А уже потом сайт перестанет работать.

Если и этих двух недель не хватило можно продлить демо лицензию. Как это сделать - легко гуглиться "Продление демо битрикс"

1) Если у Вас битрикс в редакции Бизнес, то не надо изобретать велосипед. Такая страница уже есть в админке. Магазин -> Покупатели -> Корзины.

2) Если всё же это редакция малый бизнес или надо вывести всё это в публичке тогда:
Список покупателей:

$users = \Bitrix\Sale\Internals\BasketTable::getList([
    "select" => [
        "USER_ID" => "FUSER.USER.ID",
        "USER_EMAIL" => "FUSER.USER.EMAIL",
    ],
    "filter" => [
        "!FUSER.USER_ID" => NULL,
        "ORDER_ID" => NULL,
    ],
    "group" => [
        "FUSER.USER.ID",
        "FUSER.USER.EMAIL"
    ]
])->fetchAll();

ВАЖНОЕ уточнение. В этом запросе не будут выведены корзины не авторизованных пользователей, потому что с ними всё равно ни чего не сделать полезного. Если всё же эти корзины нужны, тогда запрос будет выглядеть так:

$users = \Bitrix\Sale\Internals\BasketTable::getList([
    "select" => [
        "FUSER_ID",
        "USER_ID" => "FUSER.USER.ID",
        "USER_EMAIL" => "FUSER.USER.EMAIL",
    ],
    "filter" => [
        "ORDER_ID" => NULL,
    ],
    "group" => [
        "FUSER_ID",
        "FUSER.USER.ID",
        "FUSER.USER.EMAIL"
    ]
])->fetchAll();

Корзины покупателя:

$fuserId = 44514;//ID покупателя !!!!!  НЕ пользователя
$basket = \Bitrix\Sale\Internals\BasketTable::getList([
    "select" => [
        "*"
    ],
    "filter" => [
        "FUSER_ID" => $fuserId,
        "ORDER_ID" => NULL,
    ],
])->fetchAll();

1) Почитайте про sql инъекции. Пример
2) Я бы на вашем месте избегал использования для запросов $DB->Query. Вместо этого лучше использовать D7 ORM . Описываете таблицу классом, а потом используете выборки данный через getList или Query, если нужен специфичный запрос.

Ну и как уже сказали, надо проверять что то более конкретное. Из вашего описания, вообще не понятно, что вы пытаетесь сделать.