Форум

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

1. Делать свою табличку вида
ELEMENT_ID
IBLOCK_ID
DATE_CLEAR
DATE_TYPE - опционально, хранит признак, это дата начала или окончания (для ускорения проверок при изменении элемента)

2. Вешать обработчики на события инфоблока (OnAfterIBlockElementAdd для добавления, OnIBlockElementUpdate для изменения, OnIBlockElementDelete для удаления)
В обработчиках проверять нужный IBLOCK_ID, документооборот (в общем случае)
При добавлении проверять заполненность ACTIVE_FROM, ACTIVE_TO. Все непустые - в табличку
При изменении - смотреть, пришли ли поля, если да - изменились ли. Все измененные обновлять (либо удалять, если у элемента убрали).
При удалении - удалять

Затем получать ближайшую дату для каждого инфоблока, писать в опции (для каждого инфоблока) либо еще в одну табличку.

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

Как-то так.

Судя по скринам - это публичка, модуль списков. При построении фильтра в нем используется сортировка по полю SORT. Алфавитная сортировка, увы, пока не реализована.

[QUOTE]Юрий Удовиченко написал:
Не получается так, что время окончания активности вообще не учитывается для сброса кеша?[/QUOTE]
На текущий момент - да.

Обновиться до iblock 18.6.700, значение параметра SHOW_ALL_WO_SECTION изменить на 'N'

Админка - Настройки - Настройки продукта - Модули

Версия iblock?

[QUOTE]Dymych Dim написал:
И как в таком фильтре можно что либо найти?)[/QUOTE]
Я не вижу по скринам - ни что это (грид элементов, список в публичке), ни типа свойства (привязка к элементам списка - это что? тип L или тип E)?

Сортировка абсолютно верная, т.к. идет сравнение строк. И дело здесь не Битриксе, а в БД. Для вашей задачи лучше сохранять номер в отдельное свойство (на обработчике события) и сортировать по свойству.

Алексей, нельзя же так утром в понедельник по лбу :cry:
1. Событие вызывается ДО сохранения заказа. Это означает, что вызов $order->save приводит к абсолютно непредсказуемым результатам. В обработчике его быть не должно, save и так будет вызван. Ваша задача - передать измененные данные.
2. [QUOTE]Алексей Волков написал:
$orderEnt = $event->getParameter("ENTITY");
           $arPayVals = $orderEnt->getFields()->getValues();
           
               $order = \Bitrix\Sale\Order::load($arPayVals['ORDER_ID']);[/QUOTE]
приводит к тому, что вы получаете данные из базы, которые в общем случае уже могут отличаться, т.к. вы отслеживаете изменение только одной сущности.
3. Зачем вы дергаете обновление корзины (refreshData) и никак не пробрасываете результаты пересчета в заказа?

Правильный вариант (здесь нет проверки на ваши условия):[CODE]$payment = $event->getParameter('ENTITY');
if ($payment instanceof \Bitrix\Sale\PaymentBase)
{
  $order = $payment->getOrder();
 
  $discount = $order->getDiscount();
  $discount->setApplyResult(array('DISCOUNT_LIST' => array('ТЕКУЩИЙ_ИД_СКИДКИ' => 'N'))); // скидка, которую необходимо отменить. для нескольких скидок - несколько записей
  $res = $discount->calculate();
  if ($res->isSuccess())
  {
    if (($discountData = $res->getData()) && !empty($discountData) && is_array($discountData))
    {
        $r = $order->applyDiscount($discountData);
    }
  }
}
[/CODE]ТЕКУЩИЙ_ИД_СКИДКИ берется не из b_sale_discount, а из b_sale_order_discount. Привязка к заказу этой таблицы - b_sale_order_rules